Plusieurs événements ont récemment mis en émoi la communauté Web autour des préfixes constructeur. Plusieurs constructeurs de navigateurs ont annoncé vouloir supporter des préfixes autres que le leur. Divers appels, dont un par Daniel Glazman qui a été relayé sur Openweb, ont été lancés afin de sensibiliser les acteurs du Web sur ce problème.
Hors de tout émoi et de toute agitation, reprenons calmement le principe et voyons-en les mécanismes et les impacts sur un projet.
But premier des préfixes
Les préfixes ont été créés dans un but simple : permettre aux implémentations d’expérimenter la technologie sans encombrer le vocabulaire final. Ils évitent la cacophonie qui se produisait jusque là quand les navigateurs inventaient des propriétés et les implémentaient, parfois sous le même nom mais avec un rendu différent.
La règle est la suivante : les navigateurs testent des implémentations de diverses propriétés en les préfixant, des retours sont faits au W3C, les implémentations s’affinent, une fois la propriété au stade de Candidate Recommendation, les navigateurs doivent ne plus supporter la version préfixée.
Plusieurs raisons ont toutefois fait dérailler le processus, provoquant l’utilisation de ce système en production :
- L’implémentation de certaines propriétés étant relativement stable, il eût été dommage de ne pas déjà bénéficier des avantages qu’elles amènent.
- Le processus de standardisation est moins rapide que la récente course effrénée à l’innovation des navigateurs.
- Cette course à l’innovation draine les web designers et plein d’autres acteurs du Web : il est diablement tentant de vouloir profiter de toutes ces belles choses !
Toutefois, cette mise en production des préfixes ne s’est pas faite sans erreurs.
Les erreurs qui ont été commises
Non-utilisation de certains préfixes
Chaque moteur de rendu dispose de son préfixe constructeur, les principaux sont :
- -o- pour Opera/Presto,
- -moz- pour Firefox et les navigateurs Gecko,
- -ms- pour Microsoft,
- -webkit- pour les navigateurs utilisant WebKit : Chrome, Safari, etc.
D’autres sont plus ou moins connus :
- -mso- pour Microsoft Office,
- -xv- Opera Software (voix),
- -atsc- Advanced Television Standards Committee,
- -wap- The WAP Forum,
- -khtml- pour le navigateur Konqueror,
- -apple- Apple,
- -prince- YesLogic,
- -ah- Antenna House,
- -hp- Hewlett Packard,
- -ro- Real Objects,
- -rim- Research In Motion,
- -tc- Tall Components
Si une version préfixée est oubliée, le rendu pourra être insatisfaisant sur certains navigateurs, et ce, alors que ces derniers supportent bien la propriété !
Cela pose un problème pour l’utilisateur de ce navigateur, et également pour le constructeur du navigateur : les sites qui apparaissent cassés ou qui sont non-fonctionnels avec son navigateur peuvent faire croire à tort que le navigateur en question est dépassé ou mal construit.
Si l’on utilise des propriétés non standardisées, il faut avoir une très bonne raison pour ne pas mettre une version préfixée d’une propriété, la seule est le support réellement insatisfaisant d’une propriété donnée par un navigateur. Sinon, à quoi bon dégrader sciemment l’affichage sur un navigateur donné ?
Aparté : des tutoriels sur les dernières nouveautés de CSS3 abondent, et oublient parfois d’insister sur leur caractère non-standard et/ou très expérimental. Ils omettent également de préciser que les autres préfixes ne doivent pas être oubliés. Si vous tombez sur ces tutoriels, n’hésitez pas une seconde à proposer des corrections aux auteurs ou à les commenter.
Utilisation de propriétés exclusives à certains moteurs de rendu
Certaines implémentations de propriétés expérimentales sont exclusives à certains moteurs de rendu. Même si on les qualifie de CSS3 par abus de langage, certaines propriétés ne font pas partie de ce standard.
Encore une fois, il est important de se renseigner sur le support réel de ces propriétés : des outils comme Can I Use permettent de savoir quels navigateurs supportent telle ou telle propriété.
Il est important de garder à l’esprit que ces propriétés ne doivent être utilisées que comme des bonus, et sûrement pas comme une façon de discriminer d’autres navigateurs... et leurs utilisateurs.
Restriction à certains navigateurs
Ce cas est extrême mais malheureusement encore bien présent. Les restrictions sont inutiles car aisément contournables : elles sont basées sur la détection de l’agent-utilisateur et ce dernier est modifiable très facilement. Qui plus est, le monde des chaînes d’agent-utilisateur est une jungle épaisse et mouvante dans lequel il est quasi-impossible d’obtenir une certitude absolue.
Autrement dit : il n’y a aucune garantie que la détection marche correctement et durablement. Ajoutons à cela que restreindre un site/service à un seul navigateur est un pari hautement risqué : qui peut dire quel sera le paysage des navigateurs dans quelques années ?
Le but de cet article n’est pas de montrer du doigt et de brocarder ceux qui font ce choix. Cela dit, nous nous permettons de leur rappeler que l’universalité du Web n’est pas une option mais un principe.
Les problèmes et interrogations
En soi, utiliser des propriétés préfixées n’est pas nécessairement une mauvaise chose. Cela permet par exemple de bénéficier d’effets qui évitent l’utilisation d’images et de simplifier l’intégration dans certains cas.
Cela dit, il faut avoir plusieurs choses à l’esprit quand on le fait.
Stabilité
Premièrement, ce sont des implémentations expérimentales de propriétés CSS par les constructeurs de navigateurs. Il arrive que les premiers essais indiquent que la syntaxe utilisée n’est pas optimale. Il est également possible qu’une meilleure syntaxe soit proposée ultérieurement.
À titre d’exemple, la première syntaxe utilisée pour les dégradés proposée par Apple a évolué durant le travail de standardisation, elle est passée de :
background-image: -webkit-gradient(linear, left bottom,left top,color-stop(0.04, rgb(210,245,238)), color-stop(0.55, rgb(0,8,13)) );à
background-image: -webkit-linear-gradient(to bottom, rgb(210,245,238) 4%, rgb(0,8,13) 55%);Compatibilité
Deuxièmement, du fait de cette instabilité potentielle, plusieurs autres aspects sont à prendre en compte : la mise à jour future du projet et la rétrocompatibilité avec les anciennes versions, si elle est souhaitée.
Pour assurer ces aspects, il faut avoir la possibilité de proposer toutes les syntaxes avec tous les préfixes de tous les navigateurs, et ce à différentes périodes du projet. Sur des implémentations très expérimentales, cela peut devenir extrêmement compliqué car la maintenance peut devenir délicate : il n’y a pas toujours le budget et/ou la disponibilité pour revenir sur un projet.
Il sera donc sage de s’assurer que les implémentations et les syntaxes soient relativement stabilisées, et ce, même si ce sont des implémentations expérimentales. C’est d’ailleurs un des paradoxes de l’utilisation des préfixes en production : rechercher la stabilité d’une implémentation... expérimentale (!).
Un travail de veille constante sur l’implémentation de ces propriétés sur les navigateurs et sur leur processus de standardisation est donc indispensable. Encore une fois, des outils comme « Can I Use » permettent de connaitre l’avancement du processus de standardisation des propriétés CSS.
La bonne pratique consiste, dans le cas d’une propriété relativement stabilisée, à proposer toutes les versions préfixées suivies de la syntaxe finale non préfixée : ainsi les navigateurs qui reconnaîtront dans le futur la propriété non préfixée pourront l’utiliser et offrir la garantie d’une propriété standardisée, et les navigateurs plus anciens profiteront de leur version préfixée.
Par exemple :
background: #eee; /* fallback */
background: -moz-linear-gradient(top, #eee 0%, #bbb 100%); /* FF3.6+ */
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#eee), color-stop(100%,#bbb)); /* Chrome,Safari4+ */
background: -webkit-linear-gradient(top, #eee 0%,#bbb 100%); /* Chrome10+,Safari5.1+ */
background: -o-linear-gradient(top, #eee 0%,#bbb 100%); /* Opera 11.10+ */
background: -ms-linear-gradient(top, #eee 0%,#bbb 100%); /* IE10+ */
background: linear-gradient(to bottom, #eee 0%,#bbb 100%); /* W3C */
Note : cet exemple est tiré de Ultimate CSS Gradient Generator.
C’est un risque à mesurer, même si les principaux navigateurs se sont accordés sur une syntaxe, il n’y a pas de garantie qu’elle ne change plus tant qu’elle n’est pas proposée en Candidate Recommendation.
Conclusion
On peut utiliser des préfixes en production, à condition d’évaluer l’impact en terme de pérennité et de maintenance, et de prendre des précautions : ne pas en dépendre pour des fonctionnalités critiques, inclure tous les préfixes dont l’implémentation est correcte, et terminer par la version non préfixée.
A minima, il faut prévoir une possibilité de mise à jour, car même si tous les signaux sont au vert pour l’utilisation d’une propriété préfixée, il faut savoir que tant qu’une propriété n’est pas une recommandation, elle peut évoluer.
Il est important pour les créateurs de sites de comprendre que l’utilisation de ces préfixes n’est pas une chose anodine : le projet met un doigt dans un engrenage. De mauvaises pratiques trop fréquentes impliqueront des changements ou des décisions radicales qui auront des répercussions sur tout l’écosystème : les constructeurs de navigateurs, le processus de standardisation au W3C, les créateurs de sites et les internautes. En résumé, prenons tous garde à ne pas démolir l’édifice dont tout le monde bénéficie.
L’utilisation des préfixes en production a des avantages mais ne doit pas contrevenir au principe fondateur du Web : permettre à tout le monde d’accéder aux contenus, peu importe le logiciel, le matériel, et la situation personnelle.
Vos commentaires
# Anthony Ricaud Le 13 juillet 2012 à 10:58
Je rajouterais deux erreurs commises :
– Lorsqu’une spécification est stabilisée et que la version non-préfixée est implémentée, il convient d’enlever le support de la version préfixée après un certain temps. Cela permet de "casser" les pages qui n’avaient que la version préfixée, ce qui oblige les auteurs à les corriger, ce qui rend la page compatible avec tous les navigateurs. Apple ne joue pas le jeu sur ce point et a dit à plusieurs reprises qu’ils n’enlèveront pas les versions préfixées.
– Apple (oui, encore) ne joue pas le jeu de la standardisation en ne faisant que très peu de propositions de standards. Lorsqu’ils implémentent
<meta viewport>,-webkit-device-pixel-ratio,-webkit-mask,-webkit-gradient, etc. ils ne soumettent pas de spécification au W3C. Du coup, les autres navigateurs doivent faire de la rétroingénierie, ce qui prend énormément de temps tout en n’assurant pas une compatibilité maximum.# Prestarocket Le 13 juillet 2012 à 10:59
Hello,
Avec less ou saas, la maintenance est facilité avec ce type de problématique (changement de syntaxe)
En effet, en utilisant un mixin pour gérer le background, on peut avoir à modifier qu’une seule ligne si la propriété change et si les arguments du mixin sont compatibles avec la nouvelle propriété.
# Olivier Audard Le 13 juillet 2012 à 12:03
Il est important de noter que les préfixes s’appliquent aussi lorsque l’on souhaite accéder à une propriété CSS depuis Javascript.
Une bonne pratique consiste à utiliser un outil comme Modernizr pour la gestion des préfixes côté JS.
# _kud Le 13 juillet 2012 à 12:07
Je recommande vivement aux gens d’aller faire un tour du côté de Compass (framework pour SASS) : http://compass-style.org/. Un petit exemple de ce que propose Compass sur les linear-gradient : http://compass-style.org/examples/compass/css3/gradient/
# Tanguy Martin Le 13 juillet 2012 à 12:13
Tres bon article qui resume bien les problemes potentiels lies a la mauvaise utilisation de prefixes proprietaires. C’est drole (enfin ca depend..) car je viens juste de tomber sur un tweet donnant un lien pointant vers le bugzilla de mozilla firefox, avec une personne se plaignant de l’arret de support de certains prefixes constructeurs sur la derniere version de firefox : https://bugzilla.mozilla.org/show_bug.cgi?id=765645
Ce qui amene a un autre point quand on utilise les prefixes proprietaires, non critique cependant : etre au courant quand les navigateurs "laissent tomber" les prefixes pour supporter complement la syntaxe officielle, et ainsi reagir en mettant a jour ses CSS pour virer les prefixes au fur et a mesure. Evidemment apres s’etre assurer que le pourcentage d’utilisation d’anciens navigateurs ne supportant pas les version non prefixees est negligeable. (et si on peut revenir sur un projet potentiellement deja termine, en terme de temps/cout).
# Tanguy Martin Le 13 juillet 2012 à 12:15
Je viens de voir qu’Anthony Ricaud a fait la meme remarque dans son commentaire !
# Nicolas Hoffmann Le 13 juillet 2012 à 12:32
Tanguy : Oui, j’ai vu le tweet passer ce matin, je l’ai ajouté dans références et compléments ("Un exemple de dégât collatéral occasionné par l’utilisation des préfixes"), vu que c’est un exemple parfait de ces problèmes.
# karl Le 13 juillet 2012 à 12:49
Il y a deux conditions essentielles pour que les préfixes CSS fonctionnent dans l’esprit initial de leur conception :
1. les sites Web sont mis à jour en permanence.
2. les navigateurs Web ne rendent pas disponibles la fonctionnalité du préfixe dans la version finale du navigateur.
Nous savons tous que ces deux conditions ne sont pas remplies. Un site déployé est rarement retouché s’il ne fait pas partie d’un système de gestion interne. Résultat : Nombre de pages sur le Web traînent avec des préfixes qui ne devraient plus y être. Bien sûr comme dans le bug de Mozilla, certains se plaignent de l’abandon de la propriété avec préfixes. L’ironie est que les équipes de Chrome et Safari ne veulent pas laisser tomber les préfixes pour être compatibles avec les pratiques des auteurs. Nombre de sites codés uniquement pour Webkit s’arrêteraient de fonctionner proprement.
# karl Le 13 juillet 2012 à 12:50
Partie 2
Et donc cela pose à nouveau la question en des termes différents pour les autres navigateurs… de supporter la syntaxe des préfixes d’autres navigateurs diluant un peu plus la signification des préfixes (un espace réservé et protégé pour tester une technologie). La pression essentielle pour les navigateurs est d’être compatible avec le Web et la façon dont il est écrit afin de pouvoir interprêter les pages Web.
C’est pour cela que les pratiques de less et de sass ne font qu’accentuer le problème en faisant croire à une amélioration de la situation. Finalement, ne courrons nous pas après les problèmes quand individuellement nous faisons le choix sur nos sites Web d’utiliser des propriétés qui ne sont pas prêtes. La structure sociale et économique du Web n’appelant pas à une solidarité collective de l’interopérabilité. Il y a peu de chances pour un changement de pratique des concepteurs.
Au final, cela pose la question de la pertinence des préfixes CSS dans le processus de normalisation.
# Nicolas Hoffmann Le 13 juillet 2012 à 13:53
A mon sens, les préfixes ont leur pertinence, toutefois il faut la repenser : à mon avis, ils sont maintenant là pour dire surtout "attention, usage à risque/truc pas stable" : c’est ce que j’ai humblement essayé de transmettre dans cet article : en substance, vous voulez franchir la ligne, ok, mais vous ne pourrez plus dire que vous n’étiez pas au courant des risques en ouvrant la boite de Pandore.
Et comme tu l’as dit, Less et Sass simplifient la vie des intégrateurs, pas des navigateurs.
# karl Le 13 juillet 2012 à 14:04
@Nicolas,
Oui, c’est une possibilité de signaler attention propriété instable. Mais dans ce cas, je choisirais plutôt l’option suivante :
-draft-propriete: blah;. Et si les comportements sont différents en fonction des navigateurs, cela montre bien le danger d’utiliser une propriété non finie.Cependant, cela ne résoud pas le problème du « legacy. » C’est à dire du support du préfixe, une fois la version non préfixée a été déclarée stable.
Le grand enjeu des préfixes CSS n’est pas tant technologique que structurel et social.
# Tanguy Martin Le 13 juillet 2012 à 14:57
Que des prefixes css se retrouvent en production je ne vois pas le probleme, ne serait que pour faire du "progressive enhancement", a condition (encore une fois une condition) de s’etre renseigner sur l’utilisabilite de tels prefixes grace a des sites comme CanIUse. A partir de ce moment la, utiliser Less/Sass pour qu’il rajoute tous les prefixes qu’il faut plus la propriete CSS n’est pas un probleme.
Je pense qu’on en revient toujours au meme conclusions a la fin : le principe est bon mais souvent son application ne l’est pas, de fait d’un manque d’education des developeurs web. C’est pour cela que des articles comme celui la son primordiales, et plus il y en aura, plus le novice qui cherchera des infos pourra en trouver facilement. Encore faut-il qu’il cherche ! Mais je m’eloigne du debat..
# Anthony Ricaud Le 13 juillet 2012 à 17:10
Tanguy : "A partir de ce moment la, utiliser Less/Sass pour qu’il rajoute tous les prefixes qu’il faut plus la propriete CSS n’est pas un probleme."
Et bien si justement c’est un problème. Imagine que tu développes un site à l’époque de la première version de la syntaxe des gradient. D’après ce que tu dis, tu vas inclure toutes les versions préfixées et la non-préfixée. Et bien cette fonctionnalité ne marcherait plus aujourd’hui puisque la syntaxe a énormément changé. Si c’était une prestation et qu’elle est terminée, tu n’as pas moyen d’aller modifier ce site.
# Nicolas Hoffmann Le 13 juillet 2012 à 17:30
"Cependant, cela ne résoud pas le problème du « legacy. » C’est à dire du support du préfixe, une fois la version non préfixée a été déclarée stable".
Ajoute à ça que le navigateur peut ne pas être à jour... donc abandonner le préfixe dans la CSS du projet n’est pas pour autant une solution satisfaisante.
Pourquoi l’expression "doigt coincé dans un engrenage" me vient à l’esprit ? ;)
# Anthony Ricaud Le 13 juillet 2012 à 18:27
Ah oui et depuis le début, j’ai oublié de filer la page pour bien vivre dans le futur !
Recommandations de Mozilla
# Tanguy Martin Le 13 juillet 2012 à 18:40
@Anthony Tout a fait d’accord avec toi, c’est pour ca que j’avais precise dans mon commentaire la condition de s’etre renseigner sur l’utilisabilite d’une feature css3 aupres de la communite des dev web (blogs, twitters, etc..), et grace notamment a des sites comme CanIUse ou HTML5Please sur lesquels on peut plutot bien se fier. A l’epoque ils auraient surement pointe du doigt le fait que l’utilisation des prefixes gradients n’est pas digne de confiance.
Mais ce sont evidemment pas mal de conditions qui peuvent etre contraignantes et a moduler selon les budgets et le temps alloues a chaque projet.
# Nicolas Hoffmann Le 13 juillet 2012 à 20:06
@Anthony : c’était déjà dans les références et compléments ! ;)
# Anthony Ricaud Le 14 juillet 2012 à 09:08
@Tanguy : Il y a peu de temps, la communauté t’aurait recommandé d’y aller sur les dégradés parce que c’est bon, c’est réglé, ça bougera plus. Et puis il y a eu l’introduction du préfixe "to". Donc ça n’aurait pas aidé de consulter la communauté.
Il n’y a que deux solutions :
– ne pas utiliser les préfixes
– avoir un fallback correct si la solution préfixée ne marche pas
@Nicolas : Oups, ma énième relecture était fainéante :)
# Goulven Champenois Le 14 juillet 2012 à 15:35
Inutile de mettre -ms-gradient dans l’exemple de code : aucune version d’IE ne supporte la version avec préfixe, et IE 10 la supporte sans préfixe.
D’ailleurs un grand nombre de propriétés sont en train de perdre leur préfixe : transitions, transforms, animations, gradients dans IE 10 et Firefox 16. Voilà pourquoi il est indispensable de mettre la version non préfixée en dernière position !
# Pascale Lambert Charreteur Le 21 juillet 2012 à 14:22
C’est curieux ça : je viens de faire le test avec IE10 sous win8, ça ne fonctionne pas du tout sans le préfixe -ms ! Peut-être que cela va évoluer d’ici la sortie officielle de win8, mais je pense qu’il est plus prudent de le mettre...
# Stéphane Deschamps Le 24 juillet 2012 à 20:56
Sur le fait que les préfixes ont vocation à valider une syntaxe, le meilleur exemple vient de Firefox 16 qui va sortir sans préfixe pour les dégradés, et comme le montre Paul Rouget :
La syntaxe a changé entre les tests et l’implémentation définitive.
# David Rousset Le 25 juillet 2012 à 14:39
@Pascale : c’est normal, nous avons commencé à supporter les versions non préfixées qu’à partir d’IE10 PP6 livré avec Windows 8 Release Preview. Si tu as une version antérieure de Windows 8 (Developer Preview ou Consumer Preview), tu as une ancienne version d’IE10 qui ne supportait les gradients qu’en version préfixée.
Conclusion : mets à jour ta tablette !!! :-P
David
# Pascale Lambert Charreteur Le 6 août 2012 à 11:05 En réponse à : David Rousset
Maisheuuu ! Elle est à jour :/
Faut me renvoyer à Anaheim, je ne vois que ça ;)
# Nicolas Hoffmann Le 6 août 2012 à 15:10
Pascale, David : ça montre bien en tout cas qu’il faut garder toutes les versions préfixées. ^^
Vos commentaires
Suivre les commentaires :
|
