Введение в объектно-ориентированный CSS (OOCSS)

OOCSS

От автора: Вы когда-нибудь слышали выражение (Билла Гейтса, 1996г., прим. переводчика) «контент – это король»? Будучи веб-разработчиком и, следовательно, занимаясь делом, часто связанным с созданием содержимого, наверняка слышали. Это – слишком частоупотребимое, но верное утверждение относительно того, что привлекает на сайт посетителей.

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

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

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

OOCSS

Принципы OOCSS

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

Отделение структуры от оболочки

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

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

До применения принципов OOCSS у вас может быть такой код CSS:

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

При помощи небольшого планирования и предусмотрительности можно выделить общие стили, чтобы CSS оказался таким:

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

Отделение контейнеров от содержимого

Второй принцип, описанный на странице wiki GitHub об OOCSS – это отделение контейнеров от их содержимого. Чтобы показать, почему это важно, возьмем следующий CSS:

Эти стили применятся к любым заголовкам третьего уровня, являющимся потомками элемента #sidebar. Но что, если нам нужно применить в точности те же стили к заголовкам третьего уровня нижнего колонтитула, за исключением другого размера шрифта и видоизмененной тени текста?

Тогда нам понадобится сделать нечто вроде этого:

Или могло бы получиться еще хуже:

Сейчас мы без необходимости дублируем стили, и, возможно, не понимаем этого (или нас это просто не волнует). OOCSS поощряет нас лучше продумать то, что есть общего между различными элементами, а затем отделить эти общие черты в модули или объекты, которые можно повторно использовать где угодно.

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

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

Реально существующий пример

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

У меня было что-то вроде этого, когда я стал назначать стили заголовку:

Некоторые из приведенных здесь стилей – исключительно для элемента .header-inside. Но остальные могут сформировать модуль, который можно повторно применять. Так что я могу выделить структурные стили в их собственный класс с возможностью нового использования. Вот результат:

Стили, принадлежащие к классу .globalwidth, охватывают следующее:

Фиксированную ширину

Центрирование с помощью margin: auto

Относительное позиционирование для создания позиционирующего контекста дочерних элементов

Левый и правый отступ в 20px

Переполнение, установленное на “hidden” для очищения потока

Теперь мы можем свободно применять эти стили к любым элементам, требующим тех же характеристик, просто добавляя к нужному элементу данный класс — и не написав ни единой дополнительной строки CSS.

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

После добавления к этим элементам стилей «globalwidth» разметка будет выглядеть примерно так:

Кто-то может счесть, что этот вид стилевых разграничений создает помехи HTML и идет вразрез с принципом отделения разметки от презентационных данных.

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

Медиаобъект

Один из пионеров движения OOCSS – Николь Салливан (Nicole Sullivan). Она создала повторно используемый модуль под названием медиаобъект, который, как она объясняет, способен сэкономить сотни строк кода.

Медиаобъект

Медиаобъект – отличный пример способностей OOCSS, так как может содержать медиаэлемент любого размера с контентом со своей правой стороны. Хотя многие стили, применимые к содержимому внутри него — и даже размер самого элемента — могут меняться, у медиаобъекта есть общие основные стили, помогающие избежать ненужных повторений.

Преимущества OOCSS

Я уже упоминал некоторые достоинства OOCSS. Тут я расскажу о них более детально.

Более быстрые вебсайты

Преимущества производительности OOCSS явно видны. Если в вашем CSS повторяется меньше стилей, это приведет к меньшему размеру файлов и, таким образом, к быстрой загрузке ресурсов.

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

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

Легко обслуживаемые таблицы стилей

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

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

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

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

Моменты, заслуживающие внимания

OOCSS породил в сообществе серьезное обсуждение, вызвав споры. Я попытаюсь здесь рассеять пару недоразумений.

Вы все еще можете применять ID

Если вы решите работать исключительно по методике OOCSS, то ваши стили будут в основном базироваться на классах CSS, и вы не сможете назначать стили элементам с применением селектора ID.

Из-за этого многие ошибочно заявляют, что OOCSS поощряет полностью отказаться от использования ID. Но это неверно.

Если более точно, то правило избегания ID звучит как: не применять ID в селекторах. Таким образом, полностью приемлемо использовать принципы OOCSS (и, так, избегать назначения стилей с помощью селектора ID) во время применения ID в своем HTML для перехватчиков JavaScript’а и идентификаторов фрагментов.

Конечно, может возникнуть ситуация, где у вас уже есть ID, примененный к элементу, который, как вы знаете, уникален для страницы. Так что можно сэкономить несколько байтов, избежав добавления к этому элементу класса, а назначив вместо того ему стили с помощью селектора ID. Но даже в этом случае гораздо безопаснее полагаться на класс, чтобы гарантировать, что в будущем вы не наткнетесь на проблему конфликта.

Работа с небольшими проектами

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

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

Некоторые рекомендации по реализации

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

А вот некоторые вещи, которые вам, возможно, понадобится начать делать, чтобы помочь вам вникнуть в способ мышления OOCSS:

Избегайте селектора-потомка (т.е. не используйте .sidebar h3)

Избегайте ID в качестве ловушек-прехватчиков стилей

Избегайте прикрепления классов к элементам в своей таблице стилей (т.е. не делайте div.header или h1.title)

За исключение некоторых редких случаев избегайте использования !important

Применяйте CSS Lint для проверки своего CSS (и знайте, что у него дополнительных опций и методов много до умопомрачения)

Применяйте сетки CSS

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

Заключение

Многие опасаются идеологии OOCSS из-за того, что она, как кажется, идет вразрез со многими изученными нами так называемыми «лучшими практиками». Но как только становятся понятны долговременные преимущества использования OOCSS, я уверен, многие разработчики станут ее приверженцами.

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

Автор: Louis Lazaris

Источник: //smashingmagazine.com

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

Метки:

Похожие статьи:

Комментарии Вконтакте:

Комментарии (18)