Стиль мышления CSS
Перевод статьи «The CSS Mindset» Макса Бёка.
Ах да, CSS. Едва ли хоть одна неделя проходит без жарких онлайн-дискуссий. Он слишком простой. Он слишком сложный. Он непредсказуемый. Он устаревший. Питер-Гиффин-борется-с-жалюзи.gif.
Я не знаю, почему CSS вызывает такое разнообразие эмоций у разработчиков. Но я догадываюсь, почему иногда эта технология кажется нелогичной, почему вы чувствуете разочарование: вам нужно мыслить определённым образом, чтобы писать хороший CSS-код.
Безусловно, для написания любого кода требуется определённый образ мышления. Но декларативный характер CSS делает его особенно трудным для осознания. Особенно если вы размышляете в категориях «традиционных» языков программирования.
Другие языки программирования обычно работают в контролируемой среде, например, на серверах. Ожидается, что определённые условия будут всегда выполнены. Поэтому есть понимание, что нужно для корректной работы программы.
CSS, с другой стороны, работает в тех средах, которые никогда невозможно контролировать до конца. Поэтому он изначально должен быть гибким. CSS — это в меньшей степени о «программировании внешнего вида» и в большей степени о преобразовании дизайна в набор правил, за которыми кроется желаемое и адекватное поведение. Оставьте достаточно места и браузер сделает всю тяжёлую работу за вас.
Для большинства людей, кто профессионально пишет CSS, такой образ мышления со временем стал привычным. У многих разработчиков случается момент «АГА!», когда всё наконец складывается в единую картину. И речь тут скорее не о безупречном знании технических особенностей, а больше об общем смысле идей языка.
Я попытался описать некоторые из них ниже.
Всё — прямоугольник
Это кажется очевидным. Учитывая, что блочная модель, обычно, первое, что люди узнают о CSS. Но умение представлять себе каждый DOM элемент в виде коробки важно для понимания раскладки. Это строчный или блочный уровень? Это флекс-элемент? Как он будет расширяться, сужаться, переноситься в различных ситуациях?
Откройте «Инструменты разработчика» и наводите курсор на каждый элемент в разметке. Вы увидите, что на экране будут подсвечиваться прямоугольники. Или задайте в стилях outline: 2px dotted hotpink для визуализации границ.
Каскадность — ваш друг
Каскадность — пугающая концепция, я знаю. Произнесите «Каскад» трижды, стоя перед зеркалом и где-то сломается один стиль.
Хотя есть обоснованные причины избегать каскада, это не значит, что с ним всё плохо. По факту если использовать каскад правильно, то он сильно упростит вам жизнь.
Важно понимать, какие стили нужно задавать в глобальной области видимости, а какие стоит ограничить одним компонентом. Избежать объявления ненужных правил помогает знание наследуемых значений по умолчанию.
Столько, сколько нужно. И как можно меньше
Цель: написать как можно меньше правил, необходимых для отображения дизайна. Чем меньше свойств, тем меньше наследования, меньше ограничений и меньше проблем с переопределениями ниже по коду. Подумайте, что должен делать селектор, а затем опишите только это поведение. Нет никакого смысла прописывать width: 100% блочному элементу. Незачем писать position: relative если вам не нужен новый контекст для позиционирования.
Избегайте ненужных стилей и вы избежите непредвиденных последствий.
У краткости длинные последствия
Некоторые свойства в 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; /* почему? */
}Всякий раз, когда вы понимаете, что нажимаете клавишу со стрелкой в инспекторе, подгоняя пиксели — скорее всего, это магическое число. Такие числа редко являются решением проблемы, потому что они ограничивают стили очень конкретным сценарием использования. Если условия изменяться, то это число станет неактуальным.
Вместо этого подумайте, чего вы на самом деле хотите достичь в данной ситуации. Выравнивание? Соотношение сторон? Распределение с равными отступами? На каждую из этих задач есть гибкое решение. В большинстве случаев лучше определить общие правила поведения вместо того, чтобы захардкодить какое-то конкретное значение.
Контекст это ключ
Для многих концепций раскладки крайне важно понимать взаимосвязь между элементами и их контейнером. Большинство компонентов представляют из себя набор родительских и дочерних узлов. Стили, применяемые к родителю, могут влиять на потомков, что может заставить их игнорировать другие правила. Флексбоксы, гриды и position:absolute чаще всего становятся причиной подобных ошибок.
Когда какой-то из элементов ведёт себя не так, как вы ожидали, проверьте контекст, внутри которого находится элемент. Скорее всего на него влияют какие-то стили сверху.
Контент будет меняться
Всегда помните, что то, что вы видите — это только одно состояние интерфейса из сотен возможных. Вместо того, чтобы стилизовать нечто на экране, попробуйте создать схему компонента. Затем убедитесь, что любой контент, помещённый внутрь, не сломает ваши стили.
Строки могут быть длиннее, чем предполагалось, или содержать специальные символы. Изображения могут не загрузиться или быть не того размера.
Ошибка номер один, которую допускают и дизайнеры и разработчики заключается в предположении, что всё всегда будет выглядеть также как в статичном макете. Я вас уверяю, такого не будет.
Найдите паттерны и используйте их
Когда вы приступаете к переводу дизайна в код, бывает полезно сперва провести анализ макетов на предмет паттернов. Проанализируйте все экраны и выпишите любые концепции, которые встречаются больше одного раза. Это может быть что-то маленькое, вроде стиля текста, или большое, например, целый кусок страницы.
Что может быть абстрактным? Что должно быть уникальным? Думать об отдельных элементах дизайна полезно, поскольку это помогает определить границы компонентов и выявить повторяющиеся шаблоны.
Используйте понятные имена
Даже удивительно, какую большую часть в программировании занимает придумывание хороших имён. В CSS с этим может помочь одна из методологий. Такие схемы именования, как БЭМ и SMACSS крайне полезны. Но даже если вы не используете одну из многочисленных методологий, придерживайтесь определённого соглашением набора слов.
👉 Дисклеймер
Все эти вещи были важны для моего понимания CSS. Но ваш личный опыт относительно того, что действительно важно, может отличаться от моего. Были ли у вас другие «АГА!» моменты, которые привели к более глубокому пониманию этого языка? Дайте мне знать!
Перевод Алёны Батицкой, редактура Вадима Макеева.
