Стиль мышления CSS
Ах да, CSS. Едва ли неделя проходит без того, чтобы это не стало темой жаркой онлайн-дискуссии. Это слишком тяжело. Это слишком просто. Это непредсказуемо. Она устарела.
Я не знаю, почему CSS вызывает у разработчиков столько разных эмоций, но я догадываюсь, почему иногда это может показаться нелогичным или разочаровывающим: вам нужно определенное мышление, чтобы написать хороший CSS.
Теперь вам, вероятно, нужно мышление для кодирования в целом, но декларативный характер CSS делает его особенно сложным для понимания, особенно если вы думаете об этом с точки зрения «традиционного» языка программирования.
Другие языки программирования часто работают в контролируемых средах, таких как серверы. Они ожидают, что определенные условия всегда выполняются, и поэтому их можно понимать как конкретные инструкции относительно того, как должна выполняться программа.
CSS, с другой стороны, работает в таком месте, которое никогда не может полностью контролироваться, поэтому он должен быть гибким по умолчанию. Это меньше о «программировании внешнего вида» и больше о переводе дизайна в набор правил, которые сообщают о намерениях, стоящих за ним. Оставьте достаточно места, и браузер сделает всю тяжелую работу за вас.
Для большинства людей, которые пишут CSS профессионально, мышление приходит через некоторое время. У многих разработчиков наступил тот «ага!» Момент, когда вещи наконец начинают щелкать. Речь идет не только о знании всех технических деталей, но и об общем смысле идей, лежащих в основе языка.
Я попытался перечислить некоторые из них здесь.
Все это прямоугольник
Это кажется очевидным, учитывая, что блочная модель, вероятно, является одной из первых вещей, которые люди узнают о CSS. Но изображение каждого элемента DOM в виде рамки имеет решающее значение для понимания того, почему вещи располагаются так, как они делают. Это встроенный или блочный уровень? Это гибкий элемент? Как он будет расти / уменьшаться / оборачиваться в разных контекстах?
Откройте ваши devtools и наведите курсор на элементы, чтобы увидеть поля, которые они рисуют, или используйте стиль, например, outline: 2px dotted hotpink для визуализации его скрытых границ.
Каскад - твой друг
Каскад - страшная концепция, я знаю. Скажите «Каскад» три раза перед зеркалом, и где-нибудь какой-то несвязанный стиль сломается.
Хотя есть законные причины избегать каскада, это не значит, что все плохо. На самом деле, при правильном использовании это может сделать вашу жизнь намного проще.
Важная часть состоит в том, чтобы знать, какие стили принадлежат глобальной области видимости, а какие лучше ограничить компонентом. Это также помогает узнать значения по умолчанию, которые передаются, чтобы избежать объявления ненужных правил.
Столько, сколько нужно, как можно меньше
Цель написать минимальное количество правил, необходимых для достижения дизайна. Чем меньше свойств, тем меньше наследование, меньше ограничений и меньше проблем с переопределениями в дальнейшем. Подумайте о том, что должен делать ваш селектор, а затем попытайтесь выразить это. Нет смысла объявлять width: 100% элементу, который уже является блок. Нет необходимости устанавливать, position: relative если вам не нужен новый контекст стека.
Избегайте ненужных стилей и избегайте непредвиденных последствий.
Shorthands имеют длинные эффекты
Некоторые функции CSS могут быть написаны в сокращенной записи. Это позволяет объявлять кучу связанных свойств вместе. Хотя это удобно, имейте в виду, что при использовании сокращения также будет объявлено значение по умолчанию для каждого свойства, которое вы не указали явно. Запись background: white; эффективно приведет к тому, что все эти свойства будут установлены:
background-color: white; background-image: none; background-position: 0% 0%; background-size: auto auto; background-repeat: repeat; background-origin: padding-box; background-clip: border-box; background-attachment: scroll;
Лучше быть явным. Если вы хотите изменить цвет фона, используйте background-color.
Всегда будь гибким
CSS имеет дело с большим количеством неизвестных переменных: размер экрана, динамический контент, возможности устройства - список можно продолжить. Если ваши стили слишком узкие или ограничительные, скорее всего, одна из этих переменных собьет вас с толку. Вот почему ключевым аспектом написания хорошего CSS является использование его гибкости.
Ваша цель - написать набор инструкций, достаточно подробных, чтобы описать, чего вы хотите достичь, и в то же время достаточно гибких, чтобы браузер сам мог понять, как это сделать. Вот почему обычно лучше избегать «магических чисел» .
Магические числа являются случайными жесткими значениями. Что-то вроде:
.thing {
width: 218px; /* why? */
}Всякий раз, когда вы обнаруживаете, что нажимаете клавишу со стрелкой в ваших devtools, изменяете значение в пикселях, чтобы что-то подходило - это, вероятно, магическое число. Это редко решение проблемы CSS, потому что они ограничивают стили очень специфическим вариантом использования. Если ограничения изменятся, это число будет отключено.
Вместо этого подумайте, чего вы на самом деле хотите достичь в этой ситуации. Выравнивание? Соотношение сторон? Распределение равного количества пространства? Все они имеют гибкие решения. В большинстве случаев лучше определить правило для намерения, чем жестко кодировать вычисленное решение для него.
Контекст является ключевым
Для многих концепций макета крайне важно понимать взаимосвязь между элементами и их контейнером. Большинство компонентов являются наборами родительских и дочерних узлов. Стили, примененные к родителю, могут влиять на потомков, что может заставить их игнорировать другие правила. Flexbox, Grid и position:absolute являются распространенными источниками таких ошибок.
Если вы сомневаетесь в том, что конкретный элемент ведет себя не так, как вы хотели бы, посмотрите на контекст, в котором он находится. Скорее всего, что-то в его происхождении влияет на него.
Содержание изменится
Всегда помните, что то, что вы видите - это только одно состояние пользовательского интерфейса в большем спектре. Вместо того, чтобы стилизовать объект на экране, попробуйте создать «план» компонента. Затем убедитесь, что все, что вы бросаете в него, не нарушит ваш стиль.
Строки могут быть длиннее, чем предполагалось, или содержать специальные символы, изображения могут отсутствовать или иметь странные размеры. Дисплеи могут быть очень узкими или очень широкими. Это все состояния, которые вы должны ожидать.
Ошибка номер один, которую допускают как дизайнеры, так и разработчики, заключается в предположении, что в статическом макете вещи всегда будут выглядеть так же, как в статическом макете. Я могу заверить вас, они не будут.
Найти шаблоны и использовать их повторно
Когда вы решаете превратить макет дизайна в код, часто бывает полезно провести инвентаризацию различных шаблонов, включенных в первую очередь. Проанализируйте каждый экран и запишите любую концепцию, которая встречается чаще, чем один раз. Это может быть что-то маленькое, например, типографский стиль, или большое, например, определенный макет.
Что можно абстрагировать? Что уникального? Думая о деталях в дизайне как об отдельных вещах, их легче разрабатывать, и помогает разграничить компоненты.
Используйте последовательные имена
Удивительно большая часть программирования в целом приходит с хорошими именами для селекторов. В CSS это помогает придерживаться соглашения. Схемы именования, такие как BEM или SMACSS, могут быть очень полезны; но даже если вы не используете их, придерживайтесь определенного нименования.
