I Love Belgium... and you?

dimanche 10 février 2008

Bibliothèques CSS : Les problématiques

Framework, bibliothèque, reset, productivité, simplicité, ... des mots très à la mode et CSS n'y échappera pas ! Du moins, c'est ce qu'affirment et espèrent certains.
Les problématiques :

  1. Interopérabilité
  2. Bugs de rendu
  3. Reset
  4. Facilité

1. L'interopérabilité
Avant tout, le majeur problème est l'existence d'une multitude de moteurs de rendu (Gecko, WebCore, Trident, Pesto, ...), ayant chacun leur propre interprétation des spécifications du W3C et leur implémentation propriétaire de certains modules et fonctionnalités.
C'est donc au développeur d'en prendre compte et de gérer cette problématique en y pensant pendant son développement, chose qui dans la plupart des cas est irremplaçable par un automatisme.

2. Les bugs de rendu
Au-delà des implémentations (ou non) des spécifications du W3C et des spécifications propriétaire. Comme dans tout logiciel, des bugs sont contraint d'apparaître, freinant encore le développeur et nécessitant encore une mise à niveau de ses connaissances.
Chose qui encore une fois ne pourra pas être évalué et automatisé par un framework.

3. Reset
Ce mot défini l'action de "remettre à zéro" une multitude de rendu développé par défaut pour les navigateurs.
Seulement, est-ce nécessaire de tous les remettre à zéro ? Ou une bibliothèque ne risquerait-elle pas d'en omettre certains ou de ne pas exactement correspondre à nos besoins ?

4. Simplicité
Au delà du reset, il existe des "modules" petits bouts de code qui par magie donne le résultat voulu, c'est le cas de certaines bibliothèques tel que YUI, BluePrint, YAML, ... En vous servant de class générique vous pourrez rendre une boite rouge flottante à droite doté d'une couleur de texte verte définis à 200px de largeur...
Ce genre de code "facilité" se représente souvent sous cette forme :
<div class="floatRight bgRed colorGreen w200px">Blah blah blah</div>
Ne facilitant malheureusement en rien la maintenance, car ceci revient à faire :
<div style="float:right;background:red;color:green;width:200px">Blah Blah</div>
Le jour où vous déciderez d'enlever la couleur verte, vous allez être obliger d'ouvrir votre document HTML, document qui théoriquement devrait UNIQUEMENT contenir les informations que vous distribuez au public et non pas la mise en forme graphique de votre site.
Encore une fois l'automatisme des bibliothèques échoue à ce niveau.

Très bien, donc l'idée de bibliothèque échoue-t-elle au niveau du CSS ?
Non, mais telle que la plupart l'entende oui.
Avant-tout une bibliothèque CSS devrait fixer une base d'interopérabilité, en valorisant le débugage de certains rendu, et en mettant à zéro tous les éléments possibles, chose qui faciliterai énormément la tâche aux développeur.
Elle ne devrait en aucun cas favoriser le développement total en class générique intrusive dans le code HTML, ce qui reviendrait à une régression et à un non respect des standards et recommandations prôné par le W3C.
Sachant que CSS 3 devrait nous permettre des développements CSS absolument non intrusive !
Finalement, définir certaines class SÉMANTIQUE s'avère utile en CSS 2.1, mais pas de floatRight, colorRed ... !


Le développement CSS manque également de méthodologie, définir un document propre est extrêmement important, thème sur lequel se basera mon prochain article dédié à CSS :)

3 commentaires:

br1o a dit…

Je suis d'accord pour éradiquer le colorRed et le remplacer par un .warning en fonction des besoins, mais les .floatLeft, les .clearer et autres .center sont parfois bien pratiques, à petite dose ;)

Yves a dit…

Oui mais non, ça reste une mauvaise habitude de disperser du code CSS en dure dans un document (sans parler du fait qu'un code propre ne nécessite pas ce genre de trucs).
Alors que nommer hiérarchiquement des parties d'un site est bien plus facile à maintenir.

Pour ce qui est des CMS, des applications, ... qui créent des parties de document à la volée, j'ai tendance à les préfixer de style-, pour créer style-color-1 par exemple, et de même pour les class dédié au JS, par script-.

Qu'en penses-tu ?

br1o a dit…

Dans l'absolue, je ne peut être que d'accord, mais disons que dans ma pratique il m'arrive souvent d'utiliser certaines classes génériques dans la phase de mise en place des éléments, quand tout n'est pas encore bien calé.

Pour le préfixage, oui, l'essentiel est de s'y retrouver. Comme je l'entend souvent : tant qu'une convention de nommage existe, tout va bien ;)