HTML naming conventions for ID, class and to include element type prefix?

Html Problem Overview

Does anyone know of a good resource to explain good naming conventions for HTML ID and classes and whether to prefix with IDs with an element type i.e. btn or button or similar?

Should classes be plural or singular? I get that IDs should be singular due to them being unique, but what about classes?

IDs and classes should use nouns, right?

I am using pages that inject other pages in the existing pages, kind of like partial pages ... hence... I was wondering if anybody as prefixed a name in front of IDs and/or classes .. kind of like a namespace or similar?

Any comments or insights really appreciated.

Html Solutions

Solution 1 - Html

2015: a fresh answer focusing on existing CSS & HTML naming systems

For any convention you choose, I'd suggest you pick requirements that targets your project's needs.

Namely: is your project small or huge? is your project going to be reused or need to handle some kind of theming? Are the devs working on the CSS/HTML keen or experienced-enough to stick with conventions? & so on..

First, if you are not aware of this common (good?) practice: avoid IDs as styling hooks, try to only use Classes

Because:

only very few blocks (ie. page-header, page-footer) can 100% garantee the fact that they will not be reused elsewhere
you want to keep specificity low, there will always be times you need to override it (without using an extra ID selector or !important)

Common requirements/conventions:

Names should be intuitive/meaningful
Do NOT abbreviate names unless its a really well known abbreviation (ie. msg for Message, accnt for account)
Use known/common names: .site-nav, .aside-nav, .global-head, .btn-primary, .btn-secondary
Allow structural hierarchy (ie. BEM convention)
Use - or _ in namings: probably subjective (devs' opinions) & depending on the keyboard languages used. Note that camelCase has been left aside for browser-compatibility issues I believe, although I never found a proof for this.
Never use elements in selectors unless exceptional case: this allows for more flexibility, ie. you have buttons you created using <input type="button"></input> and you want to switch to using <button></button>, if you used element types in some selectors then you can plan some annoying/time-consuming refactoring/testing/prod-bug-fixing, whereas if you use element-less selectors then the switch will be infinitely easier. SMACCS also has it in its conventions
For states, try to match known conventions from other languages (php, java, c#): ie, use "is-active", "is-badass", & so on
Name from left-to-right: from the most generic to the most precise, ie. btn-bluetheme-create-accnt or accordion-modrnlook-userlist
a class or id name should always be specific enough to be searched across a whole project & return only the relevant results
Prefer direct descendant if you use descendent selectors - use .module-name > .sub-module-name vs .module-name .sub-module-name - you'll save yourself some headache in the future (simpler CSS but also more performant, although the term "CSS performance might be laughable")

Known conventions:

Structural naming convention: name element's class by describing what it is, rather than where it is or how it looks. See examples below.

.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

Presentational naming convention: name element's class by describing its location and/or appearance. See examples below.

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

Semantic naming convention: name by describing the content it enclose. As in. See examples below.

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

BEM naming convention: stands for "Block, Element, Modifier". Syntax is such as <module-name>__<sub-module-name>--<modifier-or-state>. Block is a the "main" container, a kind of module/component whatever you call it. Element is just a child component of the main component (the Block). Modifier is some kind of state. Peculiarities: the syntax (usage of dbl underscore & dbl dash), & child elements must contain their closest component's name. See examples below.

.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 naming convention: stands for Object Oriented CSS. Uses skins for branding purposes or consistency of design (ie. bg color, border color, ...). Abstracts the structural styles. Example of abstract structural style below. Two main principles of OOCSS: separate structure & skin, secondly separate container & content.

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

Some CSS guidelines:

There has been a "trend" to share your CSS styleguide, here are a few you can read to pick & choose whatever seems to fit for your need (naming convention but also much more, this may be out of scope of your question):

My biased opinion:

I currently use a mix of BEM, semantic & structural naming conventions & it's been working out quite well.

BEM & semantic working quite well together (yes, I name my classes such as .list-of-friends__single-friend). BEM makes things especially simpler: no nesting madness in the CSS & very verbose code.

Structural naming convention is also welcome for the bare structure of the website, or each "template" if the website has several structures. This should, in my opinion again, be only used for very generic elements, so use carefully.

Presentational naming convention: really?? thanks, but no thanks. You may consider it in special cases (ie. skin a whole page in different themes).

OCSS naming convention: I have to admit, still got to look further into this. I provided links in the resources below for you to investigate further.

Resources:

Solution 2 - Html

A lot of people don't realize you can do this stuff:

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

Solution 3 - Html

I wouldn't prefix with the type, as you can infer this in the selector if you must

form#contact {
    property: value;

}

The method you described is known as Hungarian notation, and isn't very popular.

For what you mention, you could place your injected HTML inside one div with one unique class/id, which has a sort of localised reset. Look up CSS selector specificty to ensure your rules will take affect and not other rules in the host page's CSS. See this answer to a similar question regarding styling an element within a parent page.

Content Type	Original Author	Original Content on Stackoverflow
Question	mark smith	View Question on Stackoverflow
Solution 1 - Html	Adrien Be	View Answer on Stackoverflow
Solution 2 - Html	Ryan Florence	View Answer on Stackoverflow
Solution 3 - Html	alex	View Answer on Stackoverflow