Salut,

Je compte écrire un nouvel article pour mon blog, et j'aimerais avoir le fond de pensée d'un peu tout le monde, et éventuellement faire quelques citations de ce qui sera dit (avec l'accord des cités, bien sûr) si je trouve ça pertinent (même si c'est diamétralement opposé à mon propre avis).

J'en viens donc au problème, et je donnerai mon propre avis plus tard (vous d'abord !) :

Depuis quelque temps maintenant, les "bonnes pratiques" nous recommandent de coder nos sites à la mode du "tout-classe" : Plus d'ID, peu ou pas de sélecteurs et le moins de précision possible dans le ciblage. Les arguments les plus courants à ça concernent le poids des déclarations et la facilité de surcharger celles-ci, les performances, ou encore la maintenabilité et la réutilisabilité.

Qu'en pensez-vous, et comment faites-vous ? Avez-vous adopté cette recommandation ? Pourquoi ?

Merci. ;)

C'est un ressenti assez vrai de mon point de vue.

Le tout classe permet de facilité l'intégration de framework CSS comme Bootstrap et Blueprint assez facilement. On sait qu'en utilisant une classe donnée, alors le bloc va réagir de tel ou tel façon. D'un point de vue rapidité d'intégration, c'est bijou car on gagne énormément de temps. Cependant, ce qui me déplait dans cette méthode, c'est qu'on finit par remplacer des balises dépréciées et on copie leur rendu par le biais du CSS. Ainsi, à défaut de devoir modifier que du CSS pour modifier le rendu d'un bloc, on est rapidement contraint de supprimer des classes dans le code html. Il n'y a plus de vrai dissociation du code HTML et son rendu.

Par ailleurs, nous le vrai monde, on doit encore travailler pour des navigateurs qui ne supportent pas toujours des sélecteurs CSS avancés. Typiquement, on assure encore la compatibilité avec des IE7, alors bonne pratique ou pas, mais je préfère coller des id de temps en temps et mettre de coté l'empilement de classes compliquées à surcharger (en assurant une compatibilité de bonne qualité).

Moi ça dépend surtout du projet, de la compat' (on a droppé IE7 mais IE8 résiste encore un peu), et du langage utilisé.

J'aime autant réduire un maximum le nombre de classes dans mon css, et, travaillant constamment avec un préprocesseur (Stylus en interne, généralement sass en sous-traitance), je privilégie une approche "tout mixin" plutôt que "tout classe".

Les sélecteurs avancés, qui seront d'autant plus supportés avec le drop final d'IE8 (qui ne devrait plus vraiment tarder avec la fin du support XP), permettent de s'affranchir d'énormément de "classes utilitaires" qu'on voyait par le passé.

Voilà, voilà, my 2¢

• J'aime autant réduire un maximum le nombre de classes dans mon HTML ;)

Pouvoir contrôler l'opacité des fonds ne plus devoir utiliser les rgba

[jv]jojo36: J'ai du mal à saisir le rapport ?

Bon, merci à vous pour vos retours, je laisse ouvert aux avis. ;) Effectivement, le "choix" de la cible (IE7 / 8) n'a pas été évoqué très souvent, c'est une bonne remarque.

Je suis globalement de votre avis. Pour moi, cette "mode" est née principalement de l'arrivée des framworks CSS (bootstrap et foundation en tête), qui devaient permettre de jouer aux légos avec le html sans avoir à toucher au CSS. Mais cette tendance vire un peu au n'importe quoi, et certains commencent à prôner le "CSS atomique", une sorte de paroxysme de ce système. Devant cette mode, certains ironisent en disant grosso modo qu'on a qu'à sauter les étapes intermédiaires et aller directement au "une propriété = une classe".

Comme l'a soulevé Deepblue, on fini par briser la séparation qu'on avait mise en place entre le html et le css. Et comme le dit Lisarael, on a eu de nouveaux sélecteurs avancés en CSS3, très pratiques (il en manque encore un paquet à mon sens), et les "bonnes pratiques" du moment seraient de n'en utiliser aucun, même les plus basiques ? C'est paradoxal.

Les arguments pour cette recommandation ne sont pas nombreux, mais plutôt tenaces. Il ressort très souvent une question de performances. Pourtant, les benchs montrent que les ID sont plus performants que les classes (justement parce qu'ils sont uniques). On dit aussi que le fait d'utiliser des sélecteurs trop génériques amène à des baisses de performances (car une déclaration CSS est interprétée de droite à gauche). Ainsi, une déclaration #menu li a {} serait plus coûteuse, car elle cherche d'abord tous les liens, puis fais le tri pour ne garder que ceux dans les éléments de liste, puis fait le tri encore pour ne garder que ceux dans #menu. Mais là encore, les tests montrent que la différence de performance est négligeable dans la grande majorité des cas.

À l'inverse, les benchs montrent que l'emploi de CSS non utilisé était relativement coûteux. Or, cette pratique de prévoir des classes pour à peu près tous les usages au lieu de définir des propriétés spécifiques pour des éléments précis a justement tendance à générer des portions de code non utilisées, redondantes, excessives. Paradoxal.

Et encore plus paradoxal, je vois souvent que les "grands" adeptes de cette pratique utilisent normalize afin de redéfinir les styles pour une majorité de balises qu'ils n'utiliseront jamais (code non utilisé, donc), ou "pire", un reset CSS qui va supprimer les styles pour une partie de balises qu'ils n'utiliseront jamais, et ils devront ensuite redéfinir lesdits styles pour les autres.

Quant à la suppression des ID... On parle du poids de celle-ci comme d'un problème, mais à mon sens il suffit d'un peu de logique, ou d'un peu de changement en CSS pour en tenir compte. J'ai du mal à me projeter dans un cas où je me rendrais compte qu'un de mes éléments définis par un ID se révèlerait soudainement ne pas être unique... Comment pourrais-je avoir besoin une seconde fois du header de ma page, de mon menu principal ou bien de mon footer ? C'est surtout une bonne ou une mauvaise conception en amont qui fera la différence.

Bon question : Si je vous cite dans l'article, je mets quel nom / pseudo, et quel lien (ça peut être votre site, votre twitter, ou rien... Ce que vous voulez).

J'ai rien à redire, tu as synthétisé tout ce que je pense.

Avec juste un gros focus sur les sélecteurs css3 qu'on peut utiliser sans crainte en droppant IE8, sélecteurs qui sont jouissifs à utiliser : avec un document bien construit sémantiquement, on peut (presque) se passer de classes, ou du moins les réduire drastiquement.
J'ai redonné un p'tit coup de jeune à mon CV (que j'ai pas encore remis en ligne, mais bref), en droppant le support IE8 (pasque merde), et j'ai pu retirer toutes mes classes, et je style l'entièreté du document avec les sélecteurs avancés et 5 ID, dont j'aurais pu me passer, mais au bout d'un moment, hein...

Bref, tout ça pour : +1 ;)

---

S'tu tiens à me citer (c'est bien gentil de le signaler), mon pseudo sur le web c'est Leny (lisarael c'est vraiment vieux, jamais eu le coeur de recréer un compte), et si tu veux un lien, tu peux faire pointer vers http://leny.me
Merci beaucoup

Au passage, IE8 s'accroche encore un peu, mais ça ne devrait plus durer longtemps avec l'abandon du support de XP : http://www.w3schools.com/browsers/browsers_explorer.asp

Ça durera encore quelques années, m'est avis. Preuve étant qu'on s'occupe encore d'IE7 malgré sa très faible part, principalement parce qu'on taffe pour des entreprises. Récemment (cette année), j'ai dû bosser pour un gros client (que je ne citerai pas, la dernière fois j'ai eu des emmerdes) dont le parc informatique (national) était sous IE6. Alors IE8, malheureusement, c'est pas encore pour tout de suite. Mais il me tarde, parce qu'actuellement, je trouve le métier d'intégrateur relativement bridé par rapport aux possibilités existantes.

Simon Vieille / deblan.tv pour moi, ta synthèse me parait plutôt bonne, en tout cas elle exprime plus précisement avec des détails supplémentaires ce que pense.

WarpShadow j'avais juste lu le titre en fait