Примеры названия классов html

Как строить структуру CSS и называть классы

Правило: перед тем, как называть класс, сначала проверьте — повторяется ли или может повторяться данный элемент на странице. Если да — придумайте ему универсальное название класса. Универсальные классы более важны, чем привязанные к конкретному месту на странице.

Стандартные названия классов для разных элементов

• navbar — верхнее меню навигации, которое может включать в себя не только меню, но и логотип, а также часто кнопки и поле поиска.
• название-родительского-класса-item — элемент какого-то списка, например — перечень работ в портфолио. Обратите внимание, что он обязательно включает в себя название класса родительского тега (например — portfolio-list-item ).
• название-родительского-класса-link — ссылка в меню (например, menu-footer-link ).
• название-родительского-класса-description — если у вас под названием какого-то элемента (например, преимущества компании) есть краткое описание ( preference-description );
• название-элемента-list — перечень чего-то, например — постов из блога ( blog-post-list ).
• название-родительского-класса-title , название-родительского-класса-heading — названия, заголовки каких-то блоков. Их лучше оформлять тегом h (например — portfolio-item-title , our-team-item-heading );
• section-title — заголовок для секции (смыслового блока, выделенного как правило фоном, отличным от соседних смысловых блоков).
• btn , button — название класса для кнопки. Модификаторы (цвет, размер) пишутся через дефис (например, btn-large или button-selected )
• модификаторы — используются если вы видите два очень похожих элемента, например — у кнопок одинаковый шрифт, радиус закругления, и padding. Если две кнопки отличаются в дизайне только характеристиками одного свойства (например, цвета или padding), то логично не создавать два разных класса с повторяющимися наборами свойств, а сделать один класс btn и класс-модификатор, который добавляет кнопке дополнительные свойства или изменяет их (например btn-primary или btn-red ).
• Правило: название модификатора должно отвечать на на вопрос «Какое свойство он меняет?» или «Какая смысловая нагрузка элемента с этим модификатором?». Например, btn-large — большая кнопка, font-medium — средний шрифт, btn-success — кнопка успешного выполнения действия.

О чем еще стоит думать на будущее в контексте вертки

1. Что случится, если в данный элемент добавить еще немного текста? Предположим, на странице есть кнопка. И вы зафиксировали ей ширину (написали в CSS — width: 150px ). А если сайт будет на нескольких языках, не повлечет ли это за собой то, что добавив в кнопку еще текста — весь дизайн полетит к чертям? Потому в данном случае, например, лучше применять паддинги, а не фиксированную ширину, чтобы кнопка могла изменять размер и подстраиваться под содержимое.
2. Что случится, если в данный проект будет добавлена еще одна страница? Предположим, у нас есть одна страница — лендинг. И для удобства на тег body были повешены какие-то свойства — например фон и какие-то отступы. Что если заказчик скажет — добавь в этот проект еще одну страницу, отдельную, нам нужно там разместить информацию, чтобы было удобно давать ссылку именно на эту страницу? Вы создадите новый HTML файл, в котором тоже будет тег body . Для двух разных страниц часто подключают одну и ту же таблицу стилей, в результате чего может быть использован тот CSS файл, где для body прописан фон и другие специфические стили. Придется переделывать первую страницу, потому что, скорее всего, на второй странице такие стили нужны не будут. Соответственно, все стили лучше всего прописывать в классах, чтобы эти классы потом можн обыло использовать на любых страницах, к которым будет подключен данный файл стилей.
3. Понятны ли названия классов другому человеку? Быстро ли другой человек разберется в структуре проекта и поймет что за что отвечает и как тут что работает? Рано или поздно в проект нужно будет вносить изменения. И не факт, что это будет его создатель. Скорее всего, к этому делу будет подключен совсем другой разработчик. Или, возможно, ваш проект будет разрастаться, и у вас появится коллега. Ваша задача — максимально быстро ввести его в курс дела, чтобы он мог быстро приступить к работе. Чем более логично выстроена структура проекта и максимально понятно названы классы и написан сам код — тем быстрее он может это сделать. Или вы, например, через год захотите этот проект актуализировать. Вам самим придется потратить намного меньше времени на то, чтобы вспомнить как тут все устроено, если названия классов и структура были выбраны правильно.
4. Не много ли я дублировал кода, можно ли его оптимизировать? Если видно, что в нескольких местах одни и те же свойства дублируются, есть смысл создать для них общий класс или придумать другой способ, чтобы не повторяться в нескольких местах. Одно из главных правил программиста — don’t repeat yourself (принцип DRY).
5. Надо ли создавать класс на этом элементе? Буду ли я для него применять CSS свойства? Не нужно создавать классы для элементов, если у этих классов нет функционального назначения. Это только затрудняет ориентацию в проекте. Видишь класс — сразу кажется, что он был создан для стилизации данного элемента. Потом не находишь его в таблице стилей или в джаваскрипте — и сразу вопрос: «А смысл было его создавать?». Когда понадобится — тогда и создадим. Если же сразу прописывать массу классов, которые ничего не делают, это засоряет код и усложняет ориентацию в проекте.

results matching » «

No results matching » «

Источник

CSS GuideLines, часть 3. Именование классов

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

• Для чего используется класс;
• Где класс может быть использован;
• С какими другими классами связан этот класс.

Следует отметить, что сами по себе правила именования не дадут особой выгоды при написании CSS; но зато они весьма полезны при просмотре разметки.

Разделение дефисом

Все слова в названиях классов должны быть разделены дефисом:

CamelCase и знак подчеркивания не используются для классов, следующий пример неправилен:

БЭМ-подобное именование

Для более крупных взаимосвязанных частей интерфейса я использую БЭМ-подобное именование классов.

БЭМ, то есть Блок, Элемент, Модификатор, это методология, созданная разработчиками Яндекса. Несмотря на то, что БЭМ — это довольно крупная методология, в данный момент мы заинтересованы только в ее способе именования элементов. Причем, мое соглашение по именованию немного отличается от оригинального БЭМ’a: принципы одни и те же, но синтаксис разный.

• Блок: главный корневой элемент.
• Элемент: часть блока.
• Модификатор: вариант или модификация блока.

.person <> .person__head <> .person--tall <> 

В начале класса всегда ставится название блока, для обозначения элемента мы отделяем название блока от названия элемента двумя подчеркиваниями (__), а для обозначения модификатора используем два дефиса (—).

В примере выше мы можем видеть, что .person <> — это блок; у него нет предков. .person__head <> — это элемент, часть блока; наконец, .person—tall — это модификатор, разновидность блока .person <> .

Использование блоков

Блок должен быть логической, самостоятельной единицей. Продолжая наш пример с классом .person <> : мы не можем создать класс .room__person , потому что .room <> — это самостоятельная единица. В таком случае стоит разделять блоки:

.room <> .room__door <> .room--kitchen <> .person <> .person__head <> 

Если нам потребуется обозначить человека внутри комнаты, было бы правильнее использовать такой селектор — .room .person , который позволяет не городить кашу из кучи разных непонятных элементов и блоков.

Более реалистичный пример правильного использования блоков может выглядеть следующим образом:

.page <> .content <> .sub-content <> .footer <> .footer__copyright <> 

Каждая часть кода представляет свой собственный блок. Неправильный пример использования:

.page <> .page__content <> .page__sub-content <> .page__footer <> .page__copyright <> 

Важно уметь различать, где стоит применять БЭМ, а где нет. Как правило, я использую блоки для описания автономных частей пользовательского интерфейса.

Множество слоев

Если бы мы добавили к нашему блоку .person <> еще один элемент, скажем, .person__eye , то нам не нужно было бы при именовании элемента делать шаг назад, добавляя названия предыдущих элементов, вплоть до корневого элемента. То есть, правильно будет писать .person__eye , а не .person__head__eye .

Добавляем модификации элементов

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

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

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

.person--handsome .person__face <> 

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

.person <> .person__face < .person--handsome & <>> .person--handsome <> 

Заметьте, что мы не добавляем новый элемент .person__face внутрь элемента .person—handsome ; вместо этого мы используем родительский селектор Sass внутри уже существующего селектора .person__face . Это значит, что все правила, связанные с .person__face будут находиться в одном месте, и нам не придется разбрасывать их по всему файлу. Это хорошая практика при работе с вложенным кодом: храните все нужные стили внутри одного контекста (в нашем случае, внутри .person__face ).

Именование в разметке

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

Как классы .box и .profile связаны друг с другом? Как классы .profile и .avatar связаны друг с другом? Связаны ли они вообще? Зависит ли класс .bio от класса .pro-user ? Можно ли использовать класс .avatar вне этой разметки?

При просмотре такой разметки очень сложно ответить на все эти вопросы. Использование соглашения об именовании меняет дело:

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

JavaScript-хуки

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

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

Как правило, разработчики используют отдельный класс для js, начинающийся с префикса «js-», например:

Такая разметка позволяет использовать стили .btn в любом другом месте, при этом не затрагивая поведения .js-btn .

data-* атрибуты

Также довольно часто разработчиками используются data-* атрибуты в качестве js-хуков, но это неправильно. data-* атрибуты, согласно спецификации, предназначены для хранения данных, недоступных на странице. data-* атрибуты созданы для хранения данных, а не для для привязки к js.

В продолжение темы.

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

Материалы для дополнительного изучения

Источник