Прошлое влияет на настоящее: подход Бегина к CSS

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

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

Истоки CSS

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

В отличие от динамичной и интерактивной природы современного Интернета, Веб начинался как сравнительно простое средство: то есть средство для публикации документов. Это намерение было четко заявлено на первом в истории веб-сайте, автором которого был Тим Бернерс-Ли:

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

1. CSS - это язык для создания таблиц стилей для HTML-документов.
2. CSS поощряет независимость разметки от таблиц стилей, тем самым сохраняя точность и структуру контента, позволяя при этом применять повторно используемые стили.
   
3. Каскад таблиц стилей CSS — то есть правила оформления, объявленные пользовательским агентом, могут быть отменены стилями, объявленными автором документа, которые сами по себе могут быть отменены конечным пользователем.
   

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

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

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

Итак, давайте проясним это четко: CSS, каким бы изменяющим правила игры он ни был, не был создан как API для создания приложений или компонентов — он был разработан как средство для оформления статических документов, созданных в HTML. Документы и приложения (и компоненты), однако, представляют собой совершенно разные контексты для проектирования. Между тем, природа стандартизированного Web как одной из (возможно, наиболее) обратно совместимых программных платформ, в свою очередь, означала, что история происхождения CSS всегда была неизбежной. В отличие от многих современных технологических стеков, превращение CSS в API для стилизации приложений никогда не сводилось бы к простой отправке критического изменения и предоставлению конечным пользователям возможности разобраться с последствиями. Поскольку Веб превратился в платформу не только для документов, но и для разнонаправленного потока информации, CSS как его пользовательский слой должен был постепенно развиваться вместе с ним.

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

С зерном и вопреки ему

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

Возможно, наиболее важной методологией CSS, появившейся во время перехода Интернета к веб-сайтам, похожим на приложения, был Object Oriented CSS (OOCSS), разработанный Николь Салливан в 2009 году. Ставшая легендарной статья Николь ‘Медиа-объект экономит сотни строк кода" представляет собой фундаментальное переосмысление состава наборов правил CSS и их взаимосвязи с HTML-контентом. Вместо того, чтобы писать стили CSS вокруг определенного содержимого HTML или основывать стили на расположении содержимого в DOM, OOCSS отдала приоритет написанию повторно используемых правил стиля на основе шаблонов проектирования (в случае медиа-объекта: ‘медиа-элемент фиксированного размера (например, изображение или видео) наряду с другим контентом переменного размера (например, текст)’). Будучи, возможно, первым примером методологии CSS, систематически основанной на языке визуальных шаблонов, OOCSS также стал важным шагом на пути к более модульному, многоразовому подходу к написанию CSS.

По мере того как таблицы стилей становились ответственностью все более крупных команд, глобальный охват и специфика CSS часто противоречили динамике команды. Коллизии стилей становились все более распространенными, когда изменения, внесенные одним разработчиком, непреднамеренно влияли на стили в других местах веб-сайта. Как гласит старая шутка: два CSS-свойства заходят в бар; барный стул в совершенно другом баре падает. По мере того как эти проблемы и число людей, сталкивающихся с ними, множились, появлялись и новые методологии CSS, особенно те, которые были сосредоточены на архитектуре таблиц стилей. Вскоре у нас появились SMACSS, SUIT CSS, BEM, ITCSS и многое другое. За это время также появились надмножества CSS сторонних производителей, такие как Sass и LESS, которые предоставили авторам таблиц стилей доступ к функциям сценариев, таким как переменные и циклы.

Степень, в которой суперсеты CSS способствовали или препятствовали прогрессу стилизации в Интернете, является дискуссионной. Sass, например, следует отдать должное за введение переменных в CSS, что, в свою очередь, вдохновило CSS на создание собственных пользовательских свойств (которые улучшили реализацию Sass несколькими способами). В то же время, однако, мы считаем, что такие методы, как вложение, миксины, циклы и расширения, введенные Sass и LESS, были менее полезными. Эти методы привели к тому, что в браузер был отправлен чрезмерно раздутый и сложный CSS. Чтобы добавить оскорбление к травме, из-за неотъемлемых различий между авторским кодом и сгенерированным кодом, CSS, написанный в этих супернаборах, стало намного сложнее отлаживать (задача, которая из-за увеличения сложности становилась все более необходимой).

Аналогичным образом, и несмотря на самые благие намерения, некоторые методологии CSS можно считать более полезными, чем другие. Например, давайте возьмем формат набора правил, предложенный подобными BEM, где классы создаются с использованием многогранных блоков объявлений, привязанных к контекстно-зависимым именам классов. Здесь важна часть "с учетом контекста" — конструкция BEM "Блок, элемент, модификатор" объявляет, что классы должны быть названы на основе иерархии, производной как от разметки, так и от состояния. Эта стратегия вводит зависимость между структурой разметки страницы и ее стилями, чего сам CSS пытался избежать.

BEM — не единственная методология, использующая такой формат набора правил - многие другие методологии полагаются на контекст разметки (или контекст содержимого) для информирования о построении классов. Однако в этом и заключается проблема: хотя можно сказать, что этот подход способствует приятной эргономике разработчика, результаты по своей сути хрупки (из-за тесной связи между разметкой и стилями). Кроме того, приоритет номенклатуры селекторов над фактическими стилями, применяемыми к этим селекторам, часто приводит к тому, что таблицы стилей переполняются повторяющимися объявлениями свойств — см., например, эти стили с веб-сайта Financial Times:

.o-ads--label-left .o-ads__inner:before {
  content: "▼ Advertisement ▼";
  display: block;
  font-size: 14px;
  text-align: "left";
}
.o-ads--label-right .o-ads__inner:before {
  content: "▼ Advertisement ▼";
  display: block;
  font-size: 14px;
  text-align: "right";
}
.o-ads--label-center .o-ads__inner:before {
  content: "▼ Advertisement ▼";
  display: block;
  font-size: 14px;
  text-align: "center";
}
.o-ads--label-with-borders {
  font-size: 14px;
  text-align: "left";
}

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

Атомизация CSS

В течение многих лет семантическая природа HTML приводила многих к утверждению, что CSS также должен быть написан "семантически". Однако эта тесная связь между семантикой HTML и селекторами CSS, несмотря на то, что она рекомендована даже W3C в качестве наилучшей практики, в действительности не имеет под собой основы. Семантика содержимого в HTML выражается посредством использования значимых элементов, таких как h1, nav, footer, ul и т.д., а также способа структурирования этих элементов для создания дерева документа. Между тем CSS, будучи языком представления, не имеет понятия о семантике контента; машина не может получить информацию о содержимом HTML из таблицы стилей. Николас Галлахер в статье, которую до сих пор считаю основополагающей, довольно четко изложил это в 2012 году:

В отсутствие мандата на описание конкретных узлов контента или онтологических связей между ними, авторы CSS были вольны рассматривать другие подходы к разработке CSS — и к началу 2010-х многие делали именно это. Первая статья, которую, насколько помнится, была прочитана, в которой говорилось о происходящем фундаментальном сдвиге, была написана в 2013 году Тьерри Кобленцем и соответствующим образом озаглавлена "Оспаривание лучших практик CSS". В основе статьи Кобленца был хорошо аргументированный обзор того, как так называемые "лучшие практики" в CSS в то время часто приводили к многократному переписыванию как CSS, так и HTML всякий раз, когда изменялись требования пользовательского интерфейса (что вряд ли когда-либо случается, верно?), Что приводило к постоянно растущему "добавлению только" таблицы стилей, которые со временем становятся все более хрупкими. Его предложение, отработанное на практике во время его работы в Yahoo!, было простым, но для многих в то время почти еретическим:

Этот Lego-подобный подход к CSS, возможно, восходит к OOCSS Николь Салливан (и, можно утверждать, к ранним "служебным" классам, таким как .clearfix), но то, что предлагали Кобленц и другие — обычно называемый "атомарным CSS" — довело этот подход до логической крайности.

Чтобы проиллюстрировать кардинальную разницу в подходах, рассмотрим следующие две реализации медиа-объекта (для простоты реализованные с помощью flexbox):

<!-- ‘Best practices’ media object -->
<style>
  .media {
    display: flex;
  }

  .media-img {
    flex-shrink: 0;
    padding-right: 8px;
    width: 128px;
    height: 128px;
  }

  .media-content {
    flex-grow: 1;
  }
</style>
<div class='media'>
  <img class='media-img' src='…' alt='…' />
  <div class='media-content'>
    Here’s a traditional media object.
  </div>
</div>

<!-- ‘Atomic’ media object -->
<style>
  .flex { display: flex; }
  .flex-shrink0 { flex-shrink: 0; }
  .flex-grow1 { flex-grow: 1; }
  .padding-right2: { padding-right: 8px; }
  .width6 { width: 128px; }
  .height6 { height: 128px; }
</style>
<div class='flex'>
  <img class='flex-shrink0 padding-right2 width6 height6' src='…' alt='…' />
  <div class='flex-grow1'>
    Here’s an atomic media object.
  </div>
</div>

Обратите внимание, как каждый класс в атомной версии сопоставляется только с одним свойством и значением CSS. На самом деле, если бы мы не включили второй блок <style>, у вас не возникло бы проблем с определением эффекта каждого класса только по разметке! Это отличительная черта атомарного CSS — эффект класса обычно очевиден только из его названия, в то время как специфика имени класса, такого как media, более неоднозначна.

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

Однако у нетривиального круга веб-разработчиков явно был интерес к такому подходу: в 2014 году были выпущены Tachyons Адама Морса и Basscss Брента Джексона, первые два фреймворка, которые полностью использовали atomic CSS. Эти фреймворки сыграли важную роль в написании чертежей для методологии atomic CSS и перевернули статус—кво с ног на голову - и действительно, сдвиг был настолько монументальным, что в течение нескольких лет фреймворки CSS, ориентированные на полезность, начали превращаться в многомиллионный бизнес.

Атомизация CSS официально началась.

Atomic CSS: успехи и предполагаемые неудачи

Чтобы понять успех atomic CSS (даже если этот успех остается предметом дискуссий в некоторых кругах), мы должны сначала изучить его принципы и цели, которые эти принципы стремятся достичь. Многие из этих принципов заимствованы из функционального программирования, отсюда и альтернативное название "функциональный CSS". Дополнительным источником вдохновения послужила философия Unix.

Наиболее фундаментальными принципами атомарного CSS являются:

1. Классы должны иметь единую цель. Классы должны делать что-то одно, и они должны делать это хорошо. Это делает каждый класс более многоразовым. Класс, который применяет поле, и только поле, более пригоден для повторного использования, чем класс, который применяет и поле, и цвет текста.
2. Эффект класса должен быть самоочевидным. В эффекте использования класса не должно быть никакой тайны — ясность всегда должна превосходить сообразительность. Эффект класса с именем flex, который устанавливает свойству display значение flex, самоочевиден. Эффект класса с именем media, который может устанавливать любое количество значений свойств, неоднозначен.
   
3. Классы должны быть составными. Сложные стили должны достигаться путем объединения нескольких классов одного назначения вместе, а не путем написания новых, сложных и менее часто используемых классов.
   
4. Классы должны быть неизменяемыми и не иметь побочных эффектов. Например, класс underline должен всегда применять только стиль подчеркивания. Он никогда не должен не применять подчеркивание, или применять другой стиль, или изменять любое другое свойство любого другого элемента. Ни при каких обстоятельствах это не должно изменять эффект другого класса.
   

Важно отметить, что эти принципы не были разработаны сами по себе — каждый из них играет важную роль в создании эффективных, ремонтопригодных и надежных стилей:

• Классы одного назначения более многоразовы и составны, чем классы многоцелевого назначения. Таким образом, классы единого назначения обеспечивают большую гибкость, а также уменьшают размеры файлов CSS, как в начале новых проектов, так и на протяжении всего их жизненного цикла (поскольку требуется добавлять меньше стилей для обеспечения итераций и дополнений к пользовательскому интерфейсу).
• Классы с уникальными, самоочевидными эффектами снижают когнитивные издержки разработчиков; таким образом, результирующие системы стилей легче осваиваются, а это, в свою очередь, помогает командам фронтендов масштабировать свои усилия с учетом людей и времени.
  
• Классы, которые являются неизменяемыми и не имеют побочных эффектов, приводят к меньшему количеству ошибок, а там, где возникают ошибки, облегчается отладка и разрешение.
  

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

Однако существует много распространенных возражений против методологии atomic CSS. В целом, они, как правило, являются:

1. ’Это не семантическое’. Мы уже касались этого, но стоит повторить: семантика, доступность и ясность действительно имеют значение, но при всем уважении к Zeldman, в "именах визуальных классов" нет ничего изначально несемантичного, недоступного или неясного, и нет причин для сопоставления CSS с той же семантикой. как HTML.
2. ‘Это снова встроенные стили’. Нет. Встроенные стили определены в HTML; атомарные классы определены в таблице стилей. Встроенные стили не допускают медиа-запросов, псевдоэлементов или псевдоклассов; атомарные классы допускают. Встроенные стили имеют рейтинг специфичности 1-0-0-0, который может быть выше только на !important; атомарные классы имеют специфику 0-0-1-0, такую же, как у любого отдельного класса. Источником истины встроенного стиля является его собственный сингулярный вызов для данного элемента; источником истины атомарного класса является таблица стилей. Существует лексическое сходство между class='red' и style='color: red'; на этом сходство заканчивается.
   
3. ‘Наложение такого количества классов на элементы выглядит некрасиво, их трудно читать’. По общему признанию, <section class='max-width-post-layout m-auto pt5 pr3 pb3 pl3'/> не читается как поэзия (и да, этот фрагмент взят с этой самой страницы на момент написания этой статьи). Тем не менее, что доставляет удовольствие, так это возможность быстрого повторения этой композиции — от логического источника этой композиции (разметки), будь то в браузере или моем редакторе, — чтобы исследовать различные комбинаторные пространства в рамках системы проектирования. Повторение таким образом просто не может быть сопоставлено при использовании других методологий.
   
4. ‘Это так не DRY.’. Это правда, атомарный CSS может привести к повторяющимся объявлениям различных правил стиля, но мы в значительной степени предпочитаем повторяющиеся объявления повторяющимся определениям (которые, по опыту, гораздо сложнее поддерживать). Кроме того, помните, что каждый раз, когда вы повторяете имя класса, это еще одно дополнение, которое вам не нужно было вносить в свою таблицу стилей! В конечном счете, это вопрос выбора того, какого рода повторение вы хотите, а не вопрос полного избегания повторения.
   
5. ‘Атомарный CSS противоречит современному компонентному моделированию’. ‘Мышление в React" - одна из тех статей, которая изменила представление о веб-разработке, когда она была опубликована, и нельзя отрицать, что создание интерфейсов в Интернете стало процессом, ориентированным на компоненты. Однако важно различать процесс мышления в компонентах и процесс стилизации компонентов. Концептуальная абстракция не требует эквивалентной материальной абстракции, и факт существования компонента не требует специального класса CSS.
   
6. ‘Это все еще не решает проблему глобального масштаба или одноразовых стилей’. Это не так, и на самом деле atomic CSS не предназначен для этого. Для ограниченных или одноразовых стилей абсолютно необходим другой подход.
   

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

Делаем на заказ

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

• CSS в JS. Очевидный претендент в этом списке. Мы сами много лет использовали CSS в JS и должны сказать, что эргономика разработчика довольно впечатляющая, как и возможность использовать как повторяющиеся, так и индивидуальные стили с ограниченной областью видимости (особенно при использовании библиотек, таких как Styled System или Theme UI). К сожалению, отличной эргономики разработчика и масштабирования недостаточно. CSS в JS может значительно увеличить вес пакетов на стороне клиента, а также увеличить сложность настройки (особенно когда речь идет о рендеринге на стороне сервера). Некоторые решения также могут привязать вас к определенным фреймворкам интерфейса, ограничивая переносимость ваших стилей. Появляются некоторые решения для решения этих проблем (например, экстракт ванили), но, в конце концов, признаем, что начинаем уставать от изучения абстракций CSS — есть так много более ценных вещей, которые могли бы делать со своим временем. Это не обязательно популярное мнение, но мы думаем, что CSS на самом деле довольно удивителен сам по себе.
• CSS-модули. Название может указывать на то, что CSS-модули являются частью спецификации CSS, но это не так. Модули CSS позволяют авторам извлекать стили из файла vanilla .css в файл JavaScript, содержащий разметку; во время сборки эти извлеченные стили затем восстанавливаются как стили с локальной областью действия, где бы они ни использовались. Это, по-видимому, предлагает некоторые преимущества CSS в JS, но без эргономики совместного размещения стилей, контента и поведения внутри данного компонента.
  
• Теневой DOM. Shadow DOM — это спецификация веб-стандартов, которая предназначена для обеспечения инкапсуляции контента, стилей и поведения, но в ней есть ряд труднопроизносимых предостережений. Во-первых, корни Shadow DOM должны быть инициализированы в JavaScript (хотя декларативный Shadow DOM должен решить эту проблему в будущем). Кроме того, инкапсуляция стиля работает не совсем так, как вы думаете, и это может вызвать некоторые головные боли. Я верю, что Shadow DOM обещает многое, но для многих случаев использования это может обернуться большими проблемами, чем того стоит.
  

К счастью, существует убедительное решение для работы с областью видимости и одноразовыми стилями в виде пользовательских элементов HTML, которые являются частью спецификации веб-компонентов наряду с Shadow DOM и HTML-шаблонами. Возможно, предвзято, но думается, что лучший способ работать с пользовательскими элементами прямо сейчас - это Enhance (хотя, честно говоря, я получил пик популярности Enhance перед тем, как присоединиться к Begin в 2022 году, и в то время был полон такого же энтузиазма).

Использование Enhance для создания пользовательских элементов в виде однофайловых компонентов (SFC) имеет ряд огромных преимуществ:

1. Пользовательские элементы расширяются на сервере, обеспечивая высокую производительность и отличную основу для постепенного улучшения на клиенте.
2. С локальной областью действия можно создать одноразовые стили, просто включив блок <style> в ваш SFC. Когда ваш компонент будет развернут на сервере, эти блоки стилей будут помещены в заголовок документа, а все селекторы этого блока стилей будут привязаны к вашему пользовательскому элементу. Это позволяет инкапсулировать одноразовые стили и привязывать их к компоненту, в котором они созданы, без необходимости прикасаться к теневому DOM. Стили с ограниченной областью действия, написанные в рамках SFC, также являются отличным местом для использования таких стратегий, как внутренний дизайн, которые могут счастливо сосуществовать с глобальной системой атомарных классов.
   
3. Если вам не нужно писать поведение на стороне клиента, вам никогда не придется взаимодействовать с классами JavaScript или реестром пользовательских элементов. Это особенно удобно для инженеров (или дизайнеров), которые могут преуспеть в HTML и CSS, но не имеют опыта работы с JavaScript. Хотя SFC создаются как функции JavaScript, основная часть созданного кода написана на HTML и CSS, как показано ниже:
   

// my-button.mjs
export default function MyButton({ html }) {
  return html`
    <style>
      /* One off styles applied only to button elements rendered by MyButton. */
      /* Any button outside this component will not be affected. */
      button {
        appearance: none;
        box-shadow: 0 2px 4px rgba(0,0,0,0.1);
      }
    </style>
    <!-- Atomic classes used for repeating styles -->
    <button class='p1 radius-pill cursor-pointer'>
      <slot></slot>
    </button>
  `
}

// index.html
<my-button>Click Me!</my-button>

Конечно, не обязательно использовать Enhance, чтобы получить преимущества от использования пользовательских элементов. Будучи стандартом веб—платформы, вы могли бы создать вышеупомянутый компонент и стили с областью действия без использования Enhance - это просто потребовало бы написания большего количества шаблонов (хотя рендеринг сервера было бы сложнее реализовать с нуля). Однако личный опыт показывает, что текущая реализация пользовательских элементов (и веб-компонентов в целом) оставляет желать лучшего, поскольку на нее повлияли войны фреймворков JavaScript прошлых лет. Возможно, когда-нибудь у нас будет более ориентированная на HTML спецификация для веб-компонентов (на что намекают такие спецификации, как Declarative Shadow DOM), но сейчас мы находим абстракции, предоставляемые Enhance, невероятно полезными и приятными в использовании.

Enhance также поставляется с готовой системой atomic CSS, которую можно легко настроить для интеграции с системами дизайна или руководящими принципами бренда. Таким образом, Enhance представляет собой комплексное решение для создания стилей, которое предлагает все преимущества атомарного CSS, а также позволяет легко создавать одноразовые стили с локальной областью видимости для каждого компонента. (Возможно, вы также поняли, что, поскольку стили SFC создаются в файле JavaScript, эти блоки стилей также могут использовать некоторые возможности CSS в JS — такие как использование переменных или функций JS — без необходимости беспокоиться авторам о производительности на стороне клиента. Хотя еще не обнаружили особой необходимости в этом, такая возможность есть.)

Подводя итоги

В этой статье мы рассмотрели много вопросов — часть из них историческая, часть субъективная. Хотя мы использовали много слов, чтобы описать преимущества, с которыми мы и многие другие столкнулись при использовании atomic CSS по сравнению с другими методологиями, хотим заявить, что, как и во многих других веб-приложениях, ваш опыт может варьироваться. Технические методологии всех видов по своей сути привлекают одних людей и отталкивают других, и, как сказал Джереми Кит, "речь идет о подборе правильного инструмента с правильным мышлением".

С учетом сказанного, обнаружили, что на протяжении многих лет распространялось много дезинформации относительно atomic CSS, и мы думаем, что это помогло сформировать мышление, которое, возможно, удерживало многих веб-профессионалов от того, чтобы честно встряхнуть эту методологию. В качестве надежной основы для стилизации — особенно при настройке в соответствии с системой проектирования команды — atomic CSS трудно превзойти с точки зрения его производительности, гибкости и надежности в масштабах сложности и времени. В сочетании с жесткой стратегией работы с одноразовыми или ограниченными стилями (как в Enhance SFC), atomic CSS может выступать в качестве мощного API для оформления документов, приложений и компонентов, который будет служить отдельным лицам и командам (и, следовательно, конечным пользователям) в течение длительного времени.