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

OOCSS

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

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

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

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

OOCSS

Принципы OOCSS

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

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

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

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

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

#button {
width: 200px;
height: 50px;
padding: 10px;
border: solid 1px #ccc;
background: linear-gradient(#ccc, #222);
box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}
 
#box {
width: 400px;
overflow: hidden;
border: solid 1px #ccc;
background: linear-gradient(#ccc, #222);
box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}
	 
#widget {
width: 500px;
min-height: 200px;
overflow: auto;
border: solid 1px #ccc;
background: linear-gradient(#ccc, #222);
box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}

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

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

.button {
width: 200px;
height: 50px;
}
	 
.box {
width: 400px;
overflow: hidden;
}
 
.widget {
width: 500px;
min-height: 200px;
overflow: auto;
}
 
.skin {
border: solid 1px #ccc;
background: linear-gradient(#ccc, #222);
box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}

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

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

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

#sidebar h3 {
font-family: Arial, Helvetica, sans-serif;
font-size: .8em;
line-height: 1;
color: #777;
text-shadow: rgba(0, 0, 0, .3) 3px 3px 6px;
}

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

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

#sidebar h3, #footer h3 {
font-family: Arial, Helvetica, sans-serif;
font-size: 2em;
line-height: 1;
color: #777;
text-shadow: rgba(0, 0, 0, .3) 3px 3px 6px;
}
 
#footer h3 {
font-size: 1.5em;
text-shadow: rgba(0, 0, 0, .3) 2px 2px 4px;
}

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

#sidebar h3 {
font-family: Arial, Helvetica, sans-serif;
font-size: 2em;
line-height: 1;
color: #777;
text-shadow: rgba(0, 0, 0, .3) 3px 3px 6px;
}
 
/* other styles here.... */
 
#footer h3 {
font-family: Arial, Helvetica, sans-serif;
font-size: 1.5em;
line-height: 1;
color: #777;
text-shadow: rgba(0, 0, 0, .3) 2px 2px 4px;
}

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

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

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

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

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

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

.header-inside {
width: 980px;
height: 260px;
padding: 20px;
margin: 0 auto;
position: relative;
overflow: hidden;
}

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

.globalwidth {
width: 980px;
margin: 0 auto;
position: relative;
padding-left: 20px;
padding-right: 20px;
overflow: hidden;
}
	 
.header-inside {
padding-top: 20px;
padding-bottom: 20px;
height: 260px;
}

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

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

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

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

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

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

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

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

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

<header>
<div class="header-inside globalwidth">
</div>
</header>
 
<div class="main globalwidth">
</div>
 
<footer>
<div class="footer-inside globalwidth">
</div>
1</footer>

Кто-то может счесть, что этот вид стилевых разграничений создает помехи 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

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

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

Учебник по основам CSS для начинающих

Прямо сейчас изучи CSS с нуля!

Смотреть курс

Метки:

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

Комментарии Facebook:

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

  1. Михаил

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

    • Lev

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

  2. Ирина

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

  3. OlegBon

    Спасибо!
    Интересный подход.

  4. Олег

    Да, мощная статья! Спасибо.
    Надо обязательно попробовать.

  5. romapad

    Спасибо, актуальная статья!
    Не очень понятно про медиа объекты, можно как-то подробнее раскрыть, что это такое?

    «Избегайте ID в качестве ловушек-прехватчиков стилей» — как это понять?

    Про использование !important хорошо наипсано, на то он и important чтоб его не совать в каждую строчку.

    «Применяйте сетки CSS» — а это о чем?

    Чувствую, что в России есть большая потребность в обучении создания красивого и удобного кода, в том числе и на css, так что спасибо вам, ребята!

  6. Rin

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

  7. Артем

    Уважаемый автор, вот Вам моё мнение:

    Заголовок — бред сивой кобылы, извините конечно. ООП — это не только повторное использование кода. Вы что с маркет гида пример берёте? — Чем дебильнее заголовок — тем больше посетителей?

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

    Про статью могу сказать только одно — ни о чём. Всё это давно уже используется вэб-разработчиками в виде фреймворков, взять тот же Blueprint. Да и вообще об этом уже писали здесь: getincss.ru/2011/12/16/2294 оцените качество своего рерайта :)

    ЗЫ:
    Честно говоря огорчили Вы. У вас в аудитории не только новички — которым можно скормить всё что угодно — имейте ввиду.

    • Виктор Рог

      Спасибо за Ваше мнение. Отвечу по пунктам.
      Статья — это перевод, если Вы не заметили;) По этому заголовок и сама статья — это не наш бред сивой кабылы — а «бред сивой кабылы» автора статьи. Так что причем тут маркет гид?
      Вы хоть отдаете себе отчет в том, что пишите?
      Свою аудиторию мы знаем. поверьте. Если Вам не нравится, то просто не читайте нас. Так будет удобнее всем. И Вам и нам.
      Статья данная НЕ рерайт. Я только что узнал, что есть и еще переводы данной статьи. Статью, размещенную на нашем блоге, перевел наш личный переводчик.
      Если огорчили, то уж как-то извиняйте нас, всем не угодишь.
      Может Вы подкинете пару идей для перевода?
      Только пишите в наш суппорт http://support.webformyself.com

      P.S. Еще раз благодарим Вас за Ваше мнение.
      P.P.S. Вы изначально понимали что это перевод?

      • Артем

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

        Но встаньте и Вы на моё место: я открываю почту и вижу письмо от вас с заголовком: «Введение в объектно-ориентированный CSS (OOCSS)» — для меня, отпетого ООП — щика, мир перевернулся! Я просто подумал, что проспал несколько лет, и вэб-технологии ушлёпали далеко вперёд… Естественно, что после прочтения статьи — я высказал своё возмущение…

        Ну, согласитесь, я знаю Ваша компетенция это позволит : ООП-CSS — это перебор. Конечно: «…Если Вам не нравится, то просто не читайте нас.» — самый лёгкий способ отмахнуться от назойливого таракана :) , но ради бога (и тех, трёх китов, на которых зиждется ООП) — замените хотя бы заголовок.

        ЗЫ
        То, что мой комментарий остался в стеке — показывает администрацию сайта с хорошей стороны. Они готовы принимать не только лестные отзывы, но и такие, как мой :)

        • Виктор Рог

          Да Ваш комментарий вполне адекватный и нормальный. Конструктивная критика — это очень здоров и полезно для нас.

          Меня огорчило другое — то, что Вы сразу решили что это рерайт.

          У нас свой личный переводчик. Мы даже и близко не занимаемся рерайтом;)

  8. Lika

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

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

    Может посоветуете программу в которой есть какие-нибудь шпаргалки, подсказки для удобства написания ООCSS? Я пока не смотрела Dreamweaver. Есть там что-нибудь похожее?

  9. Дмитрий

    Виктор, OOCSS — это конечно красиво и стильно. Только, OOCSS — это не что иное как наследование стилей. Конечно, когда имеешь дело с большой и понятной версткой — это имеет смысл. Но как быть, когда нужно предусмотреть несколько возможных вариантов? А когда материал находится только в разработке? А про интегрирование с JQUERY и про команду AddClass, я даже не говорю. Ведь там, требуется четкое написание каждого класса. Извините, но мне кажется, что со временем вы осознаете, что это не самая удачная статья вашей команды. Сожалею…

    • Виктор Рог

      Дмитрий, так никто и не спорит. Просто речь идет об восприятии. Ну зачем сразу все в штыки. Есть удачный, есть и не самый удачные. Это нормальный, что называется, рабочий процесс. Мы стараемся прислушиваться к Вашим мнениям. Быть может и не всегда получается. Но ведь для этого можно и нормально изъясниться, правда ведь?

  10. Eldar

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

  11. игорь гольдберг

    Профессионально написано. Благодарю!

  12. alex

    а яндексовский БЭМ и это OOCSS не одно и то же?

  13. Назия

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Я не робот.

Spam Protection by WP-SpamFree