Соглашения об именах HTML для идентификатора, класса и включения префикса типа элемента?

Кто-нибудь знает о хорошем ресурсе для объяснения хороших соглашений об именах для HTML-идентификаторов и классов и должен ли префикс с идентификаторами с типом элемента i.e.btn или кнопкой или подобным?

Должны ли классы быть множественными или единственными? Я получаю, что идентификаторы должны быть единственными, потому что они уникальны, но как насчет классов?

Идентификаторы и классы должны использовать существительные, правильно?

Я использую страницы, которые вводят другие страницы в существующие страницы, вроде как частичные страницы... следовательно... Мне было интересно, если кто-то префикс имени перед идентификаторами и/или классами.. вроде как пространство имен или подобное?

Любые комментарии или идеи действительно оценены.

Ответ 1

Я бы не префикс с типом, так как вы можете сделать это в селекторе, если вы должны

form#contact {
    property: value;

}

Метод, который вы описали, известен как венгерская нотация и не очень популярен.

Для того, что вы упомянули, вы можете поместить введенный HTML внутри одного div одним уникальным классом /id, который имеет своего рода локализованный reset. Просмотрите специфику селектора CSS, чтобы гарантировать, что ваши правила повлияют, а не другие правила в CSS-странице хоста. См. этот ответ на аналогичный вопрос, касающийся стилизации элемента внутри родительской страницы.

Ответ 2

2015: новый ответ, посвященный существующим системам именования CSS и HTML

Для любого выбранного вами соглашения я бы предложил вам выбрать требования, которые соответствуют вашим потребностям проекта.

А именно: ваш проект маленький или огромный? ваш проект будет использоваться повторно или должен обрабатывать какие-то темы? Являются ли разработчики, работающие над CSS/HTML острыми или опытными, достаточно, чтобы придерживаться условностей? и т.д.


Во-первых, если вы не знаете об этой обычной (хорошей?) практике: избегать идентификаторов в качестве стилейных крючков, попробуйте использовать только классы

Потому что:

  • только очень мало блоков (т.е. заголовок страницы, нижний колонтитул страницы) может на 100% гарантировать, что они не будут повторно использоваться в другом месте

  • вы хотите сохранить определенность низкой, всегда будут моменты, когда вам нужно переопределить ее (без использования дополнительного идентификатора или важного)


Общие требования/соглашения:

  • Имена должны быть интуитивно понятными/значащими
  • НЕ сокращайте имена, если это не очень известная аббревиатура (т.е. msg для сообщения, accnt для учетной записи)
  • Использовать известные/общие имена:.site-nav,.aside-nav,.global-head,.btn-primary,.btn-secondary
  • Разрешить структурную иерархию (например, соглашение BEM)
  • Используйте - или _ в названиях: возможно субъективные (мнения разработчиков) и в зависимости от используемых языков клавиатуры. Обратите внимание, что camelCase остался в стороне для проблем совместимости браузеров, которые, как мне кажется, хотя я и не нашел доказательства для этого.
  • Никогда не используйте элементы в селекторах, если только исключительный случай: это обеспечивает большую гибкость, т.е. у вас есть кнопки, созданные с помощью <input type="button"></input>, и вы хотите переключиться на использование <button></button>, если вы использовали типы элементов в некоторых селекторах, тогда вы можете планировать некоторые раздражающие/трудоемкие рефакторинг/тестирование/исправление ошибок, тогда как если вы используете селектор без элементов, тогда переключатель будет бесконечно проще. SMACCS также имеет его в своих соглашениях
  • Для состояний попробуйте сопоставить известные соглашения с другими языками (php, java, С#): например, использовать "is-active", "is-badass" и т.д.
  • Название слева направо: от самого общего до самого точного, т.е. btn-bluetheme-create-accnt или accordion-modrnlook-userlist
  • имя класса или идентификатора должно всегда быть достаточно определенным для поиска по всему проекту и возвращать только соответствующие результаты.
  • Предпочитайте прямой потомок, если вы используете селектор потомков - используйте .module-name > .sub-module-name vs .module-name .sub-module-name - вы сохраните себе некоторую головную боль в будущем (более простой CSS, но также более результативный, хотя термин "производительность CSS может быть смехотворным" )

Известные условные обозначения:

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

.page-container
     .page-wrap-header-n-content
     .page-header
          .branding-logo
          .branding-tagline
          .wrapper-search
          .page-nav-main
     .page-main-content
     .page-secondary-content
          .nav-supplementary
     .page-footer
          .site-info

Презентационное соглашение об именах: класс имен, описывая его местоположение и/или внешний вид. См. Примеры ниже.

.theme-ocean-blue
.theme-apricot-orange
.skin-red-tango
.skin-darkness

Семантическое соглашение об именах:, описывая содержимое, которое оно заключает. Как показано ниже. См. Примеры ниже.

.product-review
.notification
.language-switch
.currency-switch
.list-of-friends
.latest-status

Соглашение об именах BEM: означает "Блок, Элемент, Модификатор". Синтаксис такой как <module-name>__<sub-module-name>--<modifier-or-state>. Блок - это "основной" контейнер, своего рода модуль/компонент, который вы называете. Элемент - это всего лишь дочерний компонент основного компонента (Блок). Модификатором является какое-то состояние. Особенности: синтаксис (использование dbl underscore и dbl тире), а дочерние элементы должны содержать их самое близкое имя компонента. См. Примеры ниже.

.nav-primary
.nav-primary__list
.nav-primary__item
.nav-primary__link
.nav-primary__link--is-active

.grid
.grid__item
.grid__description
.grid__img-wrap
.grid__img

.global-footer
.global-footer__col
.global-footer__header
.global-footer__link

Соглашение об именах OCSS: означает Object Oriented CSS. Использует скины для целей брендинга или согласованности дизайна (например, цвет bg, цвет границы,...). Абстрактные структурные стили. Пример абстрактного структурного стиля ниже. Два основных принципа OOCSS: отдельная структура и скин, во-вторых, отдельный контейнер и содержимое.

 .global-width {
      min-width: 780px;    /* minimum width */
      max-width: 1400px;   /* maximum width */
      margin: 0 auto;      /* Centering using margin: auto */
      position: relative;  /* Relative positioning to create a positioning context for child elements */
      padding-left: 20px;
      padding-right: 20px;
      overflow: hidden;    /* Overflow set to "hidden" for clearfixing */
 }

Некоторые рекомендации CSS:

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


Мое предубежденное мнение:

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

BEM и семантический работают довольно хорошо (да, я называю свои классы, такие как .list-of-friends__single-friend). BEM делает вещи особенно упрощенными: отсутствие безумия в CSS и очень подробный код.

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

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

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


Ресурсы:

Ответ 3

Многие люди не понимают, что вы можете делать это:

.awesome {
 /* rules for anything awesome */
}

div.awesome {
 /* rules for only awesome divs */
}

button.awesome {
 /* rules for any awesome buttons, but not awesome divs */
}

div.awesome h1 {
 /* rules for H1s inside of any div.awesome */
}

div.awesome>button {
 /* rules for immediate children buttons (not grandchildren+) of div.awesomes */
}