Как правильно мыслить, чтобы писать CSS

Как правильно мыслить, чтобы писать CSS

От автора: о да, CSS. Не проходит и недели, чтобы на эту тему не разгорались жаркие онлайн-дискуссии. Это слишком сложно. Это слишком просто. Это непредсказуемо. Это устарело. Питер Гриффин борется со слепыми точками GIF.

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

Вам, вероятно, в принципе нужно мышление для кодирования в целом, но декларативный характер CSS делает его особенно сложным для понимания, особенно если вы думаете об этом с точки зрения «традиционного» языка программирования.

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

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

К большинству людей, которые пишут CSS профессионально, нужное мышление приходит через некоторое время. У многих разработчиков наступает тот «Wow!» момент, когда вещи наконец начинают проясняться. Речь идет не только о знании всех технических деталей, но и об общем смысле идей, лежащих в основе языка.

Я попытался перечислить некоторые из них здесь.

Все — это прямоугольники

Это кажется очевидным, учитывая, что блочная модель, вероятно, является одной из первых вещей, которые люди узнают о 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; /* для чего? */
}

Всякий раз, когда вы обнаруживаете, что нажимаете клавишу со стрелкой в инструментах разработчика, изменяете значение в пикселях, чтобы что-то подходило — это, вероятно, волшебное число. Это редко является решением проблемы в CSS, потому что это ограничивает стили очень специфическим вариантом использования. Если ограничения изменятся, это число будет отключено.

Вместо этого подумайте, чего вы на самом деле хотите достичь в этой ситуации. Выравнивание? Соотношение сторон? Распределение равного количества пространства? Для всего этого есть гибкие решения. В большинстве случаев лучше определить правило для намерения, чем жестко кодировать вычисленное решение для него.

Контекст является ключевым

Для многих концепций макета крайне важно понимать взаимосвязь между элементами и их контейнером. Большинство компонентов являются наборами родительских и дочерних узлов. Стили, примененные к родителю, могут влиять на потомков, что может заставить их игнорировать другие правила. Flexbox, Grid и position:absolute являются распространенными источниками таких ошибок.

Если вы сомневаетесь в том, что конкретный элемент может вести себя не так, как вы хотели бы, посмотрите на контекст, в котором он находится. Скорее всего, что-то в его происхождении влияет на него.

Контент изменяется

Всегда помните, что то, что вы видите, — это только одно состояние пользовательского интерфейса в большом спектре. Вместо того, чтобы стилизовать объект на экране, попробуйте создать «план» компонента. Затем убедитесь, что все, что вы вводите в него, не нарушит ваш стиль.

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

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

Найдите шаблоны и используйте их повторно

Когда вы решаете превратить макет дизайна в код, часто бывает полезно провести инвентаризацию различных шаблонов, включенных ранее. Проанализируйте каждый блок и запишите любую концепцию, которая встречается чаще, чем один раз. Это может быть что-то маленькое, например, стиль текста, или большое, например, определенный макет.

Что можно абстрагировать? Что уникального? Думая о деталях в дизайне как об отдельных вещах, их легче понимать, и это помогает разграничить компоненты.

Используйте последовательные имена

Важная вещь в программировании в целом — это правильные имена. В CSS это помогает придерживаться конвенции. Схемы именования, такие как BEM или SMACSS, могут быть очень полезны; но даже если вы не используете их, придерживайтесь определенной терминологии.

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ

Все эти вещи были важны для меня, но ваш личный опыт относительно того, что важнее всего, может отличаться. Был ли у вас еще один «Wow» момент, который помог вам лучше понять CSS? Дайте мне знать!

Источник: https://mxb.dev

Редакция: Команда webformyself.