Перейти от Cee-Ess-Ess к Cee-Ess-YES!

Я ненавижу CSS.

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

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

Шок. Трепет. Ужас от легкой до умеренной. Как это произошло во имя компонентов ручной сборки?

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

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

1. Классы для стилей.

Теги предназначены для семантики, идентификаторы - для ссылок.

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

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

Если вы пишете свой HTML (или, давайте будем правдой, свой JSX, потому что кто-то даже пишет HTML в наши дни) правильно, у вас, вероятно, нет тонны <div /> в вашей кодовой базе - зачем использовать старый добрый <div>, когда вы может иметь <article>, или <form>, или <nav>, или _6 _? (Или <main>? Вы ведь не забываете добавлять правильные ориентиры к просмотрам страниц, верно?) И может возникнуть соблазн стилизовать эти элементы, особенно если вы подумайте: «Эй, мы, наверное, хотим, чтобы все наши меню были единообразными, не так ли?»

Но написание хорошего семантического HTML означает, что вы выбираете элементы в зависимости от их функции на вашей странице и значения их содержания, не в зависимости от того, как вы хотите, чтобы они выглядели. <h1> - это самый важный элемент контекста в вашем представлении, а не «текст, который вы хотите быть большим и стилизованным шрифтом для вывесок». И хотя часто эти две проблемы будут сливаться вместе, иногда они расходятся, и если вы написали свои стили на этом <h1>, на этом этапе у вас есть два варианта:

  1. Вы можете написать несколько дополнительных правил CSS, чтобы иметь <h1 class="special-not-big-h1"> (или, что еще хуже, <h1 id="special-not-big-h1">, что действительно вызовет некоторую душевную боль в будущем), добавив сложности и снизив читаемость вашей кодовой базы. (Что, если вы сделаете это один раз, не будет такой проблемой, но мы все знаем, как быстро начинают складываться эти маленькие хитрости и особые случаи, не так ли?)
  2. Вы можете решить не использовать <h1> для важного содержания этого представления и, таким образом, оставить людей, использующих программы чтения с экрана или другие вспомогательные технологии, в неведении относительно иерархии вашей страницы. И это действительно отстой.

Принимая во внимание, что если вы не заставили свои <h1> выполнять двойную функцию в качестве семантических элементов и стилизаторов, все, что вам нужно сделать, это не добавлять этот конкретный класс в особый случай элемент. Не правда ли, проще? И чище?

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

2. BEM заблокирует изменение ваших элементов, чтобы они не были сертифицированным мусором (парадигма CTF в CSS).

БЭМ означает «Блок, Элемент, Модификатор» и представляет собой набор соглашений об именах, которые помогают организовать ваш CSS. Существует довольно много систем соглашений об именах, и нет единой, которая была бы наилучшим вариантом для всех обстоятельств и проектов - как и в случае с системой CSS в целом, более важно иметь одну, чем какую-либо конкретную. Но БЭМ довольно удобен, и я думаю, что это отличное место для начала для широкого круга приложений (отчасти потому, что он хорошо известен, поэтому его не составит труда объяснить новым разработчикам, которые присоединятся к вашему проекту в будущем), поэтому давайте поговорим о том, что это такое и почему это здорово.

БЭМ разделяет наши правила CSS на три категории, которые дают логику того, как визуальный стиль применяется к вашему HTML. Вместо того, чтобы рассматривать каждое визуальное требование как отдельную задачу, БЭМ побуждает вас продумать всю структуру вашего представления и соответствующим образом разбить стили. Где бы вы ни хранили свой CSS, все ваши правила должны быть сгруппированы в эти три раздела (организованные иерархически или в алфавитном порядке, в зависимости от того, что имеет смысл для вашей команды).

  1. Блоки. Блоки - это отдельные объекты в вашем коде, которые несут смысл сами по себе. Хорошими примерами являются заголовки, поля ввода, меню, флажки и т. Д. Блок - это что-то, что, по сути, содержит все свои собственные правила без какой-либо зависимости или ссылки на родительские элементы. Классы для блоков определены без подчеркиваний и дефисов и с использованием верблюжьего регистра для разделения разных слов, например: .button, .mainNav, .orderedList. (Часто вы увидите БЭМ, где один дефис используется для разделения слов в блоках, поскольку это более распространенное соглашение CSS за пределами БЭМ, но я лично считаю, что это вызывает визуальную путаницу с именованием элементов и модификаторов и добавляет на вероятность опечаток).
  2. Элементы: элементы являются составными частями блоков, и их имена должны быть семантически привязаны к их родительскому блоку. Они не работают как отдельные части - мы говорим о таких вещах, как навигационные ссылки, элементы списка или вводимые подписи. Элементы именуются в соответствии с их родительским блоком, за которым следует их собственное описательное имя, разделенное двумя символами подчеркивания: .mainNav__link, .orderedList__item, .checkbox__caption.
  3. Модификаторы. Модификаторы - это флаги, которые могут размещаться на блоках или элементах, чтобы изменять внешний вид или поведение конкретного элемента (часто это ваши особые случаи, когда цвет, размер или размещение должны обрабатываться по-разному. ). Имена модификаторов заключаются в добавлении двух дефисов и описательного имени после блока или элемента: .button--danger, .orderedList__item--last, .list--collapsed и так далее. В модификаторах я также сгруппирую правила стилей для псевдоклассов, поскольку это, по сути, то, чем они являются.

Сначала мне было трудно по-настоящему увидеть полезность этой системы, пока я не взял существующий проект и не перенес его на BEM-соглашения. Следующий набор функций / представлений, который я построил, прошел намного более гладко, чем предыдущие, я был полностью поражен.

3. Доступность - отличное руководство по дизайну

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

Итак, если вы пытаетесь развить свою эстетику и просто не знаете, с чего начать, начните с размышлений о том, что визуально сделает ваше приложение пригодным для использования. И естественно, когда я говорю «пригодный для использования», я имею в виду, что его можно использовать как можно большему количеству людей, а не только трудоспособным в настоящее время (это то, что мы все имеем в виду, ПРАВИЛЬНО ВСЕМ?).

В разработке доступных приложений хорошо то, что по большей части они улучшают жизнь всех ваших пользователей, независимо от того, как они потребляют ваш контент. Если вы не уверены, как что-то должно выглядеть, подумайте о том, как оформить это так, чтобы это понравилось как можно большему количеству людей. Убедитесь, что высота вашей строки не менее 1,5 em, размер шрифта достаточно большой, контраст цвета составляет 4,5: 1 или выше, а длина строки ограничена, чтобы текст не превышал 80 символов в строке. И определенно не используйте один только цвет для передачи важной информации вашему пользователю (особенно, особенно красного и зеленого).

Настоящая доступность выходит за рамки этого эссе, но я призываю всех, кто пишет код, особенно код, который касается пользовательского интерфейса, больше узнавать о нем и активно выступать за удобный и доступный дизайн в своей команде. Deque предлагает феноменальную онлайн-учебную программу, доступную любому, у кого есть подключение к Интернету (и с полной стипендией для любого человека с ограниченными возможностями), а у Консорциума World Wide Web (W3C) есть контрольный список того, как соответствовать различным уровням доступности. стандарты для людей, у которых нет ресурсов для Deque, или которым просто нужно быстро проверить справочник. Даже когда у вас действительно есть дизайнер, работающий с вами на каждом этапе пути, он может не знать о доступном дизайне больше, чем вы, и голос человека, который знает, что происходит под капотом, может быть важным.

4. Единственный хороший стыд - это Shame.css

Хотел бы я быть достаточно умен, чтобы придумать фразу и концепцию Shame.css. Увы, я этого не сделал, поэтому я должен начать с упоминания и восхваления Гарри Робертса, буквального мастера CSS, который объясняет, что такое Shame.css и почему он так удобен здесь и здесь.

Но позвольте мне немного поговорить с вами о том, как и почему я использую его в своих проектах или тех, над которыми я работаю. Я бы солгал (и это тоже неубедительно), если бы сказал вам, что следовал всем изложенным здесь принципам безупречно и последовательно в 100% случаев. Иногда вам просто нужно миллион раз повозиться с тем, как выглядит заголовок, и вы не хотите добавлять новый класс ко всем заголовкам. Иногда вам нужно что-то исправить сейчас-сейчас- СЕЙЧАС, и чистый код должен уступить место функциональности. Иногда бывает, что в пятницу после обеда вы слишком устали, чтобы думать правильно. Какой бы ни была причина, иногда вы делаете это легким путем, а не правильным.

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

Enter, Shame.css: когда вы пишете какой-нибудь хакерский и грубый CSS, владейте им. Поместите его в отдельный специальный файл CSS (или просто как четвертый раздел вместе с /* blocks */, /* elements */ и /* modifiers */ - тоже есть /* FIX THIS SHIT ASAP */ часть). Теперь ваш код работает, но вы предприняли шаги для обеспечения этого будущего - вы не столкнетесь с беспорядком из плохих стилей, с которыми придется иметь дело в будущем.

Ключ с Shame.css (для записи, в моем собственном коде я обычно называю его «to-fix.css» или «hacks.css», просто чтобы быть менее негативным и виноватым в it), заключается в том, что теперь часть вашего рабочего процесса должна возвращаться к этому файлу и фактически исправлять любые CSS-грехи, которые вы совершили во имя спокойной жизни. В идеале вы должны сразу приступить к этому в следующий раз, когда у вас будет плохой момент, но поскольку это может быть трудно естественным образом, мне нравится официально планировать время для этого не реже, чем раз в неделю. Утро понедельника может быть прекрасным временем для этого - это действительно хороший способ расслабиться на неделе с некоторыми не слишком тяжелыми, добродетельными победами, которые не требуют принятия тонких решений.

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

Как всегда, я хочу услышать все о том, в чем, по вашему мнению, я ошибаюсь, что, по вашему мнению, я упустил, и как вы могли бы сделать это лучше. Как вы стали меньше ненавидеть CSS? Как вы начали писать лучше?