(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
idwon’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 :
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 . 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-classwill be banned, we will prefer
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 ).
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.
This article is part of the series “Great modern CSS conception principles”.