Все говорят о «подсказках» и «профессиональных советах» по написанию замечательного CSS.

Это хорошо, но, возможно, увидев, как выглядит плохой CSS, вы получите другую точку зрения. Черт, это может даже принести вам пользу!

Позвольте мне рассказать вам, как писать очень плохой CSS.

Готовы?

Примечание: даже если вы клянетесь CSS-in-JS и не любите ванильный CSS, мы все согласны с тем: мы все равно должны знать некоторые CSS…

Итак, независимо от того, пишете ли вы CSS или какой-то супернабор, например SASS, или просто CSS-in-JS, вам все равно будет полезно знать, как выглядит плохой CSS.

Здесь так легко поскользнуться, что вы не слишком быстро заметите.

Мы все это знаем. Ты так умен, что все остальные близко не подходят. Несмотря на то, что CSS не является самым выразительным из языков, вы можете делать предположения об особенностях браузера, исправлять их и предполагать, что вы поймете, что сделали через несколько недель.

Как разумно, а?

Отложите свою гордость и лишите себя и других товарищей по команде стресса.

Если вы используете не очень очевидную технику, или исправили какую-нибудь капризу браузера, или вообще что-то, что вы считаете недостаточно внятным, напишите этот комментарий! Это не больно.

Страна складных селекторов

Да! Вы только что выучили CSS и чувствуете себя на вершине мира. Итак, пора показать мышцы селектора.

Плохой ход.

Выбрав слишком много селекторов CSS, вы, возможно, успешно сделали свой CSS чрезвычайно непригодным для поддержки. Теперь он сильно зависит от структуры HTML вашего приложения.

Если структура разметки изменится незначительно, вам также нужно переработать свой CSS. Не самый простой из рабочих процессов.

Просто добавьте класс к элементу и продлевайте жизнь!

Даже в сценариях, когда вам нужно квалифицировать селекторы с несколькими классами, всегда отдавайте предпочтение простоте.

Просто – это хорошо, почти всегда!

Производительность? Откажитесь от этого!

Итак, я понял. Вам просто безразлично о производительности. Ясно, что вам безразлично к бизнесу. Если бы вы это сделали, вы бы не раздражали своих пользователей своими ужасающими неработающими селекторами.

Но подождите…

Я понимаю, что компьютеры растут быстрее, а браузеры продолжают оптимизироваться. Несмотря на это, всегда следует отдавать предпочтение простым селекторам, а понимание того, как браузер проходит через DOM, чтобы найти ваш селектор, все еще важно!

Скорее всего, вы читаете свои селекторы слева направо.

Однако браузер согласовывает селекторы справа налево, поэтому он может удалять не совпадающие элементы как можно скорее.

Если бы вы это знали, то, вероятно, были бы более снисходительны к браузерам. Они заслуживают вашей любви.

Рассматривая приведенный выше графический пример, браузер будет соответствовать всем элементам. bodyа также проверить, являются ли они потомками

body * {  ... } 

. <boНо почему? Практически каждый видимый элемент в идеале является потомком

dy> элемент. Это просто ненужная неэффективная проверка.

Мне плохо называть вещи, потому я даже не беспокоюсь.

В информатике есть только 2 тяжелых вещи. Назвать вещи и…

Да, я думаю, вы уже где-то это слышали. Имя вещи может быть сложным, но это не означает, что вы не должны думать о них или задумываться полностью.

.u {  font-size: 60rem;}

Я сомневаюсь, что есть какая-то ситуация, когда имеет смысл использовать отдельные буквы как имена классов.

.former-black-now-red-paragraph {  color: red;}

А как насчет специфических имен классов?

Они тоже не приносят пользы.

Хотя может показаться, что название имеет определенное содержание, вы скорее всего нарушили значительную часть возможности повторного использования класса. Что, кстати, основная причина проведения занятий. red Теперь, если вы хотите стилизовать обычный

абзац, предыдущее название настолько конкретно, что не имеет смысла.

Используйте содержательные названия, но не переусердствуйте.

хммм… Если возможно, избегайте чрезмерно модульных классов

Занятия отличные, и всем они нравятся. Но, как и все остальное, слишком многое, как правило, плохая идея.

Вы видите, если группа классов будет в основном использоваться вместе, просто сгруппируйте их в один класс.

Когда вы решили сгруппировать эти классы, может быть субъективно. Если вы создаете какую-нибудь атомарную библиотеку, вы можете стремиться к этому.

Если вы пишете обширную программу, вам, скорее всего, лучше сгруппировать классы содержательным образом, а не иметь кучу классов на одном элементе.

Если возможно, избегайте излишне модульных классов.

Я пурист CSS. Я не делаю SASS, LESS и так далее.

Ты пурист CSS, я пурист CSS, мы оба пуриста. Давайте избавиться от этого.

Теперь, к ядру спора.

Бесспорно, есть случаи, когда просто писать ванильный CSS – это здорово! Например, если я не использую решение CSS-in-JS для своих проектов React, я могу решить пойти по чистому CSS. Это не больно.

Однако, если вы пишете обширную программу с большим количеством обычных CSS, я думаю, что внедрение препроцессора CSS сделает вашу разработку более интересной и будет способствовать созданию более удобной кодовой базы CSS.

Опять же я не говорю, что используйте препроцессоры каждый раз. Я говорю, что не закрывайте этот вариант. Это могло бы спасти вас! У вас много Важно

N6QGbrfgLCAKgecAbfzrNyCfMxjXtcebzvHm

Я ненавижу CSS. Это просто никогда не работает. Итак, что поправить? !important Иметь тонну

всюду, когда мне нужно переопределить какие-либо декларации. Ха-ха! !important Хотя это звучит как достойный план для вашего ленивых, чрезмерное использование

правило приведет только к крайне непригодному для обслуживания документу CSS. !importantВ следующий раз нужно будет использовать

убедитесь, что вы этого не делаете, потому что вам лень исправлять свои каскадные проблемы.

CSS не так уж плох. Принять это.

Хотите написать лучший CSS?

Семь секретов CSS, о которых вы не знали