Ce billet fait partie de la série « Dirty Hacky ». Le but de cette série est un objet critique sur les astuces de web-développement, et n'a pas pour vocation d'être une recette définitive, mais d'attirer l'audience par la polémique technique.
BANG! BANG!            BANG!

0. Je parse en HTML .357 S&W
1. Commentaires conditionnels
2. Magouilles dans les CSS
3. Des confettis troués en CSS
4. Liens serrés dans la police
5. Des Bleus et des Boss
6. Exécutions très rapides
7. Le script des bas-fonds
8. Préfixes frelatés

Expérimentations devenues folles

Dans l'analyse juridique de ce hack, je dois reconnaître qu'il y a polémique.
Dans son intention première et sa réalisation, l’idée est très bonne. L'origine est purement standard. Le préfixage ne corrompt pas les parseurs, indique d’une manière claire que l’objet ou la méthode appartiennent à un moteur et que nous devons considérer sa disponibilité comme très limitée et sujette à changements.

Alors que s'étoffait le langage CSS, il apparaissait vite le besoin de marquer qu'une solution était expérimentale, de pouvoir la tester dans des navigateurs sur de multiples plateformes sans mettre en péril l'éventuelle implémentation finale. Il a été prévu dans le namespace des CSS (puis plus tard en Javascript) un espace réservé pour chaque constructeur de navigateur existant ou à venir afin de pouvoir tester les propriétés avant qu'elles soient standardisées. Cela était motivé par les errements de Microsoft qui a mis du zoom, du filter et du expression avec MSIE5.5, ce qui bloquait tout usage le temps de vie de ses navigateurs, certifié 10 années sur contrat.

Touche pas au grisbi !

Mais pourquoi ces propriétés sont devenues utilisées hors du cadre expérimental ?
Ce sont les longueurs de négociations du W3C, et surtout les blocages entre ses différents membres qui faisaient enrager certains navigateurs. Nommément, l'impossibilité de démontrer les effets de round-corner autrement qu'en utilisant les préfixes -gecko- et -webkit-. Or comme on parle de moteurs de navigateurs open-sources, dans un milieu hyper technophile, fallait pas croire que les échanges sur mailing-list allaient en rester là.

Dans les faits, c’est devenu une catastrophe. Les propriétés et les API préfixées sont en voie de standardisation. Elles ne sont pas fixées et surtout peuvent disparaitre à tout moment. Et quitte à construire un site avec, les ¾ des intégrat brico gens qui les utilisent n’ont même pas idée qu’il existe autre chose que -webkit- ou -gecko-. Or bien souvent, ces propriété deviennent dé-préfixées et standardisées. Et leur notation standard des valeurs ne correspond plus du tout à ce qui a pu être testé en navigateurs. Il est arrivé régulièrement que les notations implémentées par exemple par Firefox et par Chrome en test n'ont absolument pas été retenues par le CSS-WG, et qu'elles ont été retirées par ces mêmes navigateurs, mettant dans la panade les intégrateurs trop peu prévoyants.

Tout va trop vite, ma pauv' dame

Une propriété préfixée n'est nullement garantie de rester à terme, ou de garder sa notation de valeurs une fois standardisée. Elle est même rapidement abandonnée par les navigateurs, car elle oblige à conserver du code redondant, mourrant, ce qui grève les performances des parsers.

Afin de résoudre le problème, les navigateurs ont accéléré les changement de version. On se souvient que Firefox 3.6 est resté la version principale pendant 18 mois. Une éternité alors que maintenant, les navigateurs Chrome et Firefox changent de version tous les deux mois. Release early, release often comme on le dit dans le logiciel libre. Ils tentent aussi d'arriver à obtenir que le standard soit unifié et publié au plus vite.

Le problème du nouvel entrant

Les bonnes pratiques veulent qu'on écrive :

-webkit-new-property : format proposé par chrome,safari;
-gecko-new-property : mozilla format;
-o-new-property : version opera;
-ms-new-property : le format (microsoft);
new-property : syntaxe que vous pariez;

Et là, vous devinez que se pointe un autre problème : en attendant que cette nouvelle propriété soit standardisée, si un moteur supplémentaire arrive et veut essayer son implémentation (au hasard, NetFront pour faire plaisir à @HTeuMeuLeu), il ne sera quasiment jamais intégré sur les autres sites. Ce fut l'objet de l'inquiétude de Daniel Glazmann, vice-président du CSS-WG au W3C, et on en avait déjà discuté auparavent sur ce blog.

Délinquants en puissance

Google a dévoilé cette semaine l'outil d'authoring HTML5 que toutes les agences de comm' attendaient : Google Web Designer. Enfin Flash va mourir, dans la perspective de le faire disparaître assez vite avec les autres plugins. Énorme souci : l'usage de propriétés expérimentales.

Est-ce normal ? Non. Les propriétés prefixées sont purement expérimentales, et là, Google a clairement dépassé la ligne rouge. Nous sommes revenus aux heures catastrophiques de Flash Macromedia.

Mais j'ai la chance d'avoir pu discuter avec Valerio Virgillito, un membre de l'équipe de développement de GWD, alors que ce dernier tout juste annoncé n'est encore qu'un logiciel en béta que je n'ai pas eu le temps de tester en 24h. Et que ce support des préfixes expérimentaux est justement considérée comme expérimentale par les développeurs. Il est probable qu'elle ne soit plus activée par défaut, le temps de peaufiner le logiciel, et que les navigateurs dé-préfixent lesdites propriétés ;)

Personnellement, je préfèrerais que ces paramètres ne soient pas actifs par défaut, et soient même des paramètres cachés. Tant pis pour l'aperçu du futur.

To be continued

Te voilà en bas de mon procès-verbal, t'as la place pour placer tes commentaires ↓