Долгое время я не возражал против всех разговоров оокс. Когда термин впервые был придуман, я быстро просмотрел основы и ошибочно предположил, что он просто повторил то, что я делал годами. В последнее время методология набирает популярность ( читайте статью Николаса Галлахера для получения дополнительной информации), что требует более тщательного изучения того, что предлагалось. По сути, я потрясен тем, что я прочитал, и я надеюсь, что я не единственный.
По семантике
Конечно, концепция семантики HTML несколько расплывчата. Несмотря на то, что это была горячая тема в течение многих лет, на самом деле нет окончательного решения, поэтому существует так мало инструментов, чтобы в полной мере использовать семантический HTML-код. Некоторое время мы полагались на классы (микроформаты) для передачи семантики, html5 вводил микроданные в качестве встроенного заменителя, а сами элементы html имеют свое естественное семантическое значение. В наши дни микроданные позволяют нам определять дополнительную семантическую ценность, не связанную с простой природой контента, но привязанную к его контекстуальному значению (кто я и куда я принадлежу).
Микроданные могут использоваться для стилизации (хотя это слишком многословно), атрибуты данных могут использоваться в качестве триггеров JavaScript. Внезапно мы попадаем в ситуацию, когда классы теряют свою привлекательность, oocss хорошо использует свое внезапное отсутствие функции, чтобы захватить атрибут класса и использовать его для создания скинов. Вопрос, конечно, в том, хорошая ли это идея ( в долгосрочной перспективе ).
На OOCSS
Основная идея oocss — определить визуальные стили, связанные с одним именем класса, а затем применить этот класс ко всем элементам, которым нужен этот стиль. Это противоречит всему, чему мы научились за последние 10 лет, но это само по себе не должно быть причиной для отказа от этой техники. Однако это должно привести к появлению нескольких предупреждающих знаков, потому что, очевидно, мы не проповедовали семантическое использование имен классов только потому, что думали, что это было бы забавно (и в любом случае больше ничего не происходило).
«Oo» в oocss происходит от расширения и смешивания разных классов, довольно упрощенное представление о «oo», но оно, несомненно, помогло распространить слово. Хотя это явно сильная сторона, это также слабое место всей установки. Учтите следующее:
.class1 {... color:#000; ...}
.class2 {... color:#fff; ...}
Одна большая проблема с oocss, которая сразу возникает, заключается в том, что конфликты между различными оболочками встречаются гораздо чаще, чем написание обычной CSS. Поскольку нам разрешено смешивать и сопоставлять разные базовые классы, мы быстро оказываемся в ситуациях, когда свойства, определенные в классах с одинаковым весом, борются за доминирование.
Хотя CSS предоставляет механизм для исправления этого (последний класс в исходном коде CSS выигрывает), я считаю, что это является необходимой частью обработки ошибок CSS, а не хорошей практикой кодирования. Если кто-то реорганизует ваш css-файл, все обязательно сломается, что намекает на очень плохую структуру вашего css.
На внутренней реализации
Вероятно, хуже всего то, что oocss создает внутреннюю реализацию. В некоторых случаях (внутренняя разработка больших сайтов) это может быть не так уж плохо, но для других сайтов это означает, что html-код, который выдает cms, имеет очень слабую ссылку на логические компоненты, скорее он связан со стилями. Если есть разница в стиле между двумя компонентами, это означает, что компоненту нужен другой вывод html. Если раньше это было только проблемой css, то теперь мы распределяем обязанности между back-end, html и css.
Мало того, простые обновления скина также влияют на html, что означает больше возможностей для того, чтобы что-то пошло не так.
На OOHTML
Причина, по которой я сначала не обращал особого внимания на oocss, заключается в том, что я использовал похожие концепции, основанные только на шаблонах html, а не на шаблонах css. Определите базовые классы для различных (семантических) компонентов, а затем дополните их дополнительными классами для создания вариантов. Используйте только семантически обоснованные имена классов, а не имена, которые намекают на скины.
В долгосрочной перспективе это позволило бы нам (и на самом деле я говорю об ожидаемом будущем здесь) разработать однокомпонентные фреймворки, которые позаботятся обо всей серверной и html-работе. Создание сайта (с использованием whitelabel css для вашей платформы) может занять часы, а не дни, остальное — просто работа css. Пока вы делаете каждый элемент идентифицируемым (что не то же самое, что добавление имени класса в каждый элемент HTML), проблем не должно быть.
Но как насчет css вы говорите? Ну, у Николаса есть следующее, чтобы сказать:
Однако даже с помощью препроцессора я предпочитаю использовать шаблон с несколькими классами и добавлять классы модификаторов в HTML.
Приятно иметь предпочтения, но мне очень интересно узнать, почему он предпочитает путь oocss. Люди, которые раньше использовали меньше и sass, поймут, что oocss — это не более чем html-интенсивный способ добавления миксинов. Миксины могут делать почти то же самое, что и oocss, но вам не нужно убивать ваш HTML-код, чтобы получить желаемый результат.
Вывод
Винт oocss, да здравствует oohtml. Напишите свой HTML-код с учетом семантических компонентов и вариантов, используйте mixins, если хотите повторно использовать CSS-код. Это выгодно для внутренней реализации, поддерживает предсказуемость и чистоту вашего html и поддерживает разделение между содержанием и стилем. Приятно время от времени оспаривать существующие идеи, но это не значит, что результат того стоит. На данный момент oocss может показаться несколько привлекательным (поскольку миксины не являются частью официальной спецификации CSS), но в долгосрочной перспективе это еще одна из тех ложных лучших практик, которые принесут больше вреда, чем пользы. Давайте не попадем в эту ловушку снова.