(Note : this article was previously published in French a few weeks before this translation –if you have any feedback on the translation made by Nicolas Hoffmann and John Elbing, please let us know.)

Ids and classes

HTML markup offers a lot of possibilities to style documents. Of course, it is possible to target blocks or elements by their tag, however, this approach – which was almost systematic before – tends to become rare.

Yes, we can target some elements directly by their tag for CSS “resets” or for tags which have “self-sufficient” semantics. But now, we often target elements by classes.

Even if targeting elements by an id is still possible in the style sheet
(doing so will not prevent a website from working, it is not an error in itself), it is now reserved for very special cases and/or highly discouraged for many reasons :

• It is difficult to guarantee that an item will remain unique
  throughout the life of the site. In other words, they are often too
  coupled to the HTML structure that can change a lot.
• Their definition makes them impossible to reuse : on principle they are unique.
• Their important weight make them difficile to surcharge, for example,
  a class added to the styled element by an id won’t be able to surcharge
  the styles added by this id. It caused a lot of time to use !important
  despite common sense or having selectors that expand or unnecessarily complicate (example : #element.classe).

To the opposite, if ids are less used to target elements in CSS or not used anymore, that does not mean that they have to be banned from HTML structures, on the contrary ! (for internal anchors, linking form elements to their label, etc.).

From global to specific

Whatever you are using a desktop-first or mobile-first approach, the CSS must always start from global rules (of the chosen approach) to the more specific ones. this will guarantee :

• covering as many cases as possible with the general rules ;
• avoiding setting up too many specific styles where a more general style would have limited them ;
• allowing a surcharge as light as possible.

This principle is expressed through several aspects :

• the order and the structure of your CSS (for example, reset comes first as it has the most global properties, they have to be executed before all others rules) ;
• the specificity of your CSS selectors : more specific ones override the global ones ;
• elegant factorization of CSS properties ;
• if your website if using media-queries, their properties should
  override or apply without using looooong selectors.

It will be very important to order the style sheet very carefully.

Some reasons may make this principle difficult to apply, for example if a project requires a large number of developers, sometimes having no communication possible between them (split team), it will be important to ensure that the specific styles don’t collide (by defining conventions before, for example).

N.B : this principle may also explain itself based on how styles are included. For example, inline styles take priority over styles included in a page by a <style> tag, which take also priority on an external style sheet file. However, as it is generally desirable to include the styles in an external file for obvious reasons of maintainability, we will stick to the inclusion of styles using files.

Separation of structure/layout as much as possible

Another great principle of integration is to allow separation between
structure (HTML) and layout (CSS). However, you might have noticed we have added “as much as possible” in focus.

Let’s face facts : if the separation structure/layout was an absolute principle a few years ago, applying it to the extreme has caused a lot of problems [1]. Although the semantics of classes is possible and sometimes desirable, let’s be honest : the classes are often just there to style, rarely to allow a document to be semantically communicating.

Nowadays, the principle is still true, it is its application that is slightly different than before. You might avoid making CSS too dependent on an HTML structure (which can change and won’t work anymore). For example :

• you should target an element by a direct class (.module-title) instead
  of relying on the tag in the container (.module h3) ;
• except in specific cases, too-specific selectors as p.my-class will be banned, we will prefer .my-class ;
• etc.

Semantic classes

Let’s make an aside on the subject of semantic classes. Many debates (sometimes heated) are raging on the subject of semantic classes, that is
to say, the use of classes that are supposed to inform or extend the meaning of what they contain [2]).

It is not the intention of this article to rewrite history. The only objective is to observe the evolution of the practice. Adding semantic classes to an element is totally possible in modern integration, just as it is entirely possible to use non-semantic classes… in short, as it is both possible to do or not to do so, this question is simply irrelevant in the context of this series of articles – and in this context only.

Note

This article is part of the series “Great modern CSS conception principles”.