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

Ответ 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", вот некоторые из них, которые вы можете прочитать, чтобы выбрать, выбрать, что, по-вашему, подходит для вашей потребности (соглашение об именах, но также и многое другое, это может быть вне сферы вашего вопрос):

• github.com/styleguide/css/
• cssguidelin.es
• css-tricks.com/sass-style-guide
• codepen.io/chriscoyier/blog/codepens-css

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

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

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

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

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

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

Ресурсы:

• http://www.smashingmagazine.com/2011/12/12/an-introduction-to-object-oriented-css-oocss/
• http://getbem.com/
• http://bem.info/method/definitions/
• http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/
• https://github.com/stubbornella/oocss/wiki
• https://css-tricks.com/semantic-class-names/
• http://www.stuffandnonsense.co.uk/archives/naming_conventions_table.html
• http://sixrevisions.com/css/css-tips/css-tip-2-structural-naming-convention-in-css/
• Соглашение об именах классов CSS
• Могу ли я использовать верблюжий случай в именах классов CSS
• https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Underscores_in_class_and_ID_Names
• https://softwareengineering.stackexchange.com/questions/141988/practical-considerations-for-html-css-naming-conventions-syntax
• http://smacss.com/book/type-module
• github.com/styleguide/css/
• cssguidelin.es

Ответ 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 */
}