Как да напиша наистина ужасен CSS

Всички говорят за „съвети“ и „съвети“ за писане на страхотни CSS.

Това е добре, но може би виждането как изглежда лош CSS ще ви даде различна перспектива. По дяволите, може дори да ти донесе малко добро!

Нека ви преведа през пътешествие за това как да напиша наистина лош CSS.

Готов?

Забележка: дори ако се кълнете в CSS-in-JS и не обичате ванилови CSS, всички сме съгласни за нещо: всички ние все още трябва да знаем някои CSS ...

Така че, независимо дали пишете CSS или някакъв суперсет като SASS или просто CSS-в-JS, все пак ще се възползвате от това да знаете как точно изглежда лош CSS.

Кой пише коментари? Никой.

Без коментари? Действителен код написах преди време, но премахнах всички коментари

Толкова е лесно да се плъзнеш тук, че няма да забележиш много бързо

Всички го знаем. Ти си толкова умен, всички останали не се приближават. Въпреки че CSS не е най-изразителният от „езиците“, можете да правите предположения за странности в браузъра, да ги поправяте и да предполагате, че ще разберете какво сте направили няколко седмици по-надолу.

Колко умно, а?

Оставете гордостта си настрана и спасете себе си и други съотборници от стреса.

Ако използвате не толкова очевидна техника или сте коригирали някаква странност в браузъра или нещо, което смятате, че не е достатъчно изразително, напишете този коментар! Не боли

Земята на сложните селектори

Да! Току-що научихте CSS и се чувствате на върха на света. И така, време да покажете някои мускули на селектора.

Лош ход.

Правейки селекции с твърде много CSS селектори, може би сте направили успешно CSS изключително непостижим. Вече е силно зависима от структурата на HTML на приложението ви.

Ако структурата на маркировката се промени леко, трябва също да рефакторирате вашия CSS. Не е най-лесният от работните процеси.

Просто добавете клас към елемента и продължете с живота!

Дори в сценарии, в които трябва да квалифицирате селектори с няколко класа, винаги предпочитайте простотата.

Простият е добър, почти винаги!

Производителност? Изкопай това!

И така, разбирам. Просто не ти пука за представянето. Ясно не ти пука за бизнеса. Ако го направихте, няма да дразните потребителите си с ужасните си неефективни селектори.

Но почакай…

Разбрах, че компютрите пораснаха по-бързо и браузърите продължават да бъдат оптимизирани. Независимо, винаги трябва да се предпочитат прости селектори, а разбирането как браузърът обикаля DOM, за да намери вашия селектор, все още е нещо!

Вероятно е, четете селекторите си отляво надясно.

Браузърът обаче съответства на селекторите от дясно на ляво, така че може да елиминира елементи, които не съвпадат възможно най-бързо.

Ако знаехте това, вероятно бихте по-снизходителни към браузърите. Те заслужават вашата любов.

Като се има предвид горният пример, браузърът ще съответства на всички елементи (*) и също така ще провери дали те са потомци на тялото.

тяло * {
  ...
}

Но защо? Почти всеки видим елемент в идеалния случай е потомък на елемента . Това е просто ненужна неефективна проверка.

Смучам да назовавам нещата, така че дори не се притеснявам.

В компютърните науки има само 2 трудни неща. Именуване на нещата и ...

Да, мисля, че вече сте го чули някъде. Именуването на нещата може да е трудно, но това не означава, че не бива да им мислите или да се разминете напълно.

Съмнявам се, че има някаква ситуация, в която има смисъл да се използват единични букви като имена на класове.

.u {
  размер на шрифта: 60rem;
}

А какво ще кажете за супер специфичните имена на класове?

.former-black-now-red-абзац {
  цвят: червен;
}

Тези също не дават никаква полза.

Въпреки че може да изглежда, че името носи някакво значение, вероятно сте нарушили огромна част от повторната употреба на класа. Което, между другото, е основната причина за провеждането на часове.

Сега, ако искате да стилизирате обикновен червен абзац, предишното име е точно толкова конкретно, че няма да има смисъл.

Използвайте смислени имена, но просто не прекалявайте.

Чух, че класовете бяха страхотни. Прекалявайте с тях!

Хммм…. Когато е възможно, избягвайте над модулирани класове

Класовете са страхотни и всички ги обичат. Но както и при всичко останало, прекалено многото от нещо като цяло е лоша идея.

Виждате ли, че ако група класове най-вече ще се използват заедно, просто ги групирайте в един клас.

Когато решите да групирате тези класове е може би субективно. Ако изграждате някаква атомна библиотека, може да се стремите към това.

Ако пишете голямо приложение, вероятно е по-добре да групирате класове по смислен начин, за разлика от тона класове в един елемент.

Когато е възможно, избягвайте над модулирани класове.

Аз съм CSS пурист. Аз не правя SASS, LESS и т.н.

Вие сте CSS пурист, аз съм CSS пурист, и двамата сме пуристи. Нека го извадим от пътя

Сега, до костта на спора.

Определено има случаи на използване, когато само писането на ванилов CSS е чудесно! Например, ако не използвам CSS-в-JS решение за моите проекти React, бих могъл да реша да отида по чистия CSS маршрут. Не боли

Ако обаче пишете голямо приложение с тона ванилен CSS, летящ наоколо, обзалагам се, че въвеждането на препроцесор на CSS ще направи вашето развитие по-интересно и ще допринесе за по-поддържана CSS база данни.

Отново не казвам да използвам препроцесори всеки път. Казвам, не просто затваряйте тази опция. Може да ви спести!

Имате много важен стил там!

Мразя CSS. Просто никога не работи. И така, какво е поправката?

Имам много важно значение навсякъде, когато трябва да отменя всякакви декларации. Хаха!

Въпреки че това звучи като приличен план за вашия мързелив Аз, прекаленото използване на важното правило ще доведе само до грубо невъзможен CSS документ.

Следващия път, когато трябва да използвате! Важно, бъдете сигурни, че не го правите, защото сте твърде мързеливи, за да коригирате проблемите си с каскадата.

CSS не е толкова лошо Прегърнете го.

Искате ли да напишете по-добър CSS?

Създадох безплатно ръководство за CSS, за да получа вашите CSS умения пламващи веднага. Вземете безплатната електронна книга.

Седем CSS тайни, за които не сте знаели