Le compromis entre ces deux types de classes permet de considérablement économiser en temps et en poids : là ou un site complet m'aurait demandé de cracher 5000 lignes, les classes non sémantiques réduisent cet effort d'une bonne moitié. ]]> text/html https://www.nicolas-hoffmann.net/source/1583-Les-classes-semantiques-en-CSS.html#comment158412 Gaël Wed, 28 Aug 2013 14:43:10 +0200

Pour cela, je préfère fonctionner à l'orthogonalité autant que possible : le JS manipule indépendamment des classes/id, les styles sont appliqués sur des classes/id et aussi peu que possible sur des balises (sauf cas particuliers), les classes sémantiques idéalement devraient être indépendantes des styles, etc.

Au moins, cela évite des prises de têtes du genre : "mééé euh, j'ai utilisé jQuery sur telle classe, et ça met le bordel". En gros, chaque donjon a des passerelles pour chaque autre donjon, et ça évite que bricoler la tourelle de la sémantique vienne mettre le cirque chez la tourelle JavaScript, si tu me permets l'analogie château-fort.

Soyons honnêtes, cette règle est "idéale", mais en pratique, y a-t-il à ce point besoin d'éviter l'interdépendance sur certains projets ? Sur les 3/4 des projets que je fais, y a jamais de casse car des conventions "raisonnablement strictes" sont prises. J'imagine que sur les plus gros projets, tu es obligé de prendre des conventions encore plus strictes. ]]> text/html https://www.nicolas-hoffmann.net/source/1583-Les-classes-semantiques-en-CSS.html#comment158409 Nico Wed, 28 Aug 2013 10:03:42 +0200 text/html https://www.nicolas-hoffmann.net/source/1583-Les-classes-semantiques-en-CSS.html#comment158408 Alf Tue, 27 Aug 2013 19:00:58 +0200