it-roy-ru.com

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

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

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

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

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

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

60
mark smith

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

form#contact {
    property: value;

}

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

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

11
alex

2015: свежий ответ с акцентом на существующие системы имен CSS и HTML

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

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


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

Так как:

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

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


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

  • Имена должны быть интуитивно понятными/значимыми
  • НЕ сокращайте имена, если это не очень хорошо известное сокращение (т. Е. Msg для сообщения, для учетной записи)
  • Используйте известные/общие имена: .site-nav, .aside-nav, .global-head, .btn-primary, .btn-Secondary
  • Разрешить структурную иерархию (т.е. соглашение БЭМ)
  • Используйте - или _ в именах: возможно, субъективно (мнение разработчиков) и в зависимости от используемых языков клавиатуры. Обратите внимание, что camelCase был оставлен в стороне из-за проблем совместимости браузера, хотя я так и не нашел доказательства этому.
  • Никогда не используйте элементы в селекторах, кроме исключительных случаев: это обеспечивает большую гибкость, т.е. у вас есть кнопки, которые вы создали с помощью <input type="button"></input>, и вы хотите переключиться на использование <button></button>, если вы использовали типы элементов в некоторых селекторах, то вы можете запланировать некоторый раздражающий/трудоемкий рефакторинг/testing/prod-bug-fixing, тогда как если вы используете element- меньше селекторов, тогда переключаться будет бесконечно легче. SMACCS также имеет это в своих соглашениях
  • Для состояний попробуйте сопоставить известные соглашения из других языков (php, Java, c #): то есть используйте "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

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

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

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

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


Ресурсы:

66
Adrien Be

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

.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 */
}
19
Ryan Florence