{"partition": "head_middle", "source_domain": "openweb.eu.org", "digest": "sha1:C3SCM6DEBDGHSHCUE3GDSYCB2BPF2Z27", "path": "/lustre/fsn1/projects/rech/qgz/uzq54wg/processed_redpajama/base_processing/output/fr/2014-15/000_00004.parquet"}
Voir ailleurs
See this site in English
Décideur
Gourou
Pages dynamiques
Les préfixes constructeurs
Openweb.eu.org > Articles > Les préfixes constructeurs
Les préfixes constructeurs sont un sujet ayant de multiples facettes qui impactent tous les acteurs du Web sans exception. Les enjeux à court, moyen et long termes sont importants et ne doivent en aucun cas être sous-estimés. Nicolas Hoffmann vous propose un éclairage et une mise en perspective sur ce sujet épineux.
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é commisesNon-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.
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.
On peut utiliser des préfixes en production, à condition d’évaluer l’impact en terme de pérennité e