Le moteur de rendu WebKit n’utilisera bientôt plus aucun préfixe pour l’ensemble des CSS. Parallèlement, sa couverture de la norme ECMAScript 2015 (ES6) culmine désormais à 99 %, prenant ainsi la tête du classement des navigateurs.
ECMASCript est une norme, ou plutôt un ensemble de normes définissant les caractéristiques des langages de scripts qui décident de s’y référer. L’exemple le plus connu est JavaScript, mais on pourrait citer également l’ActionScript d'Adobe et le TypeScript de Microsoft, spécialisé dans la réalisation des gros projets. Les moteurs de rendu doivent également être compatibles avec cette norme via leur machine virtuelle JavaScript pour que les fonctionnalités de ce dernier puissent être prises en charge.
ECMASCript 2015 : WebKit est en tête
Aussi, quand WebKit atteint 99 % de compatibilité avec la version 2015 de la norme (anciennement ECMAScript 6). En l’état actuel des choses, il ne manque en fait plus que six éléments en tout et pour tout à supporter pour atteindre les 100 %. Un très bon rythme quand on sait que la norme a été validée dans sa version finale en juin de l’année dernière seulement. Une course qui en dit long cependant sur la nécessité dans ce domaine d’harmoniser non seulement les pratiques, mais de donner aux développeurs des outils supplémentaires.
Si l’on se réfère à la table de compatibilité ES6, il est facile de voir que WebKit est clairement en tête. Cela étant, tous les navigateurs sont dans leurs plus récentes préversions dans un mouchoir de poche. Edge supporte 90 % de la norme, Firefox 93 % et Chrome 98 %. On peut estimer que la plupart des navigateurs auront atteint la barre des 100 % dans les six mois qui viennent.
Les 100 % pour la WWDC d'Apple en juin ?
Ces 99 % sont atteints notamment par la dernière Technology Preview de Safari sur OS X. Rappelons qu’il s’agit du canal de test lancé il y a quelques semaines par Apple, qui pilote majoritairement le développement de WebKit. La TP3 contient bon nombre d’améliorations, mais on remarque vite en consultant la liste des nouveautés que beaucoup concernent justement… l’ECMAScript 2015.
Il est fort probable que les 100 % soient présents dans le futur Safari 10, qui devrait arriver avec les nouvelles versions d’OS X et iOS. Les deux systèmes devraient être présentés tous les deux à la conférence WWDC d’Apple en juin.
Le vaste problème des préfixes WebKit...
L’équipe WebKit a également annoncé une autre nouvelle d’importance : la fin des préfixes CSS. Un changement majeur pour le développement web.
Pour comprendre l’ampleur de ce virage, il faut comprendre ce qu’est un préfixe. Il s’agit d’un moyen commode de tester en avance le support d’une technologie ou d’une norme qui n’est pas encore finalisée. L’éditeur du moteur de rendu utilise alors un préfixe pour marquer une balise par exemple, pour bien faire comprendre qu’il s’agit d’une implémentation « maison » et donc susceptible d’évoluer par la suite. Quand la norme est finalisée, le préfixe est supprimé. WebKit utilise le préfixe « -WebKit » par exemple, tandis que Mozilla se sert de « -moz »
Dans le cas de WebKit, il existe cependant une différence importante. Le moteur de rendu dispose d’une part de marché écrasante sur le web mobile. Le travail au W3C était relativement lent (car prenant en compte de multiples facteurs d’harmonisation), le moteur se retrouve en avance sur le support des technologies. Les développeurs se servent alors des préfixes, qui finissent par rester par inertie des habitudes.
... va enfin être réglé
Or, les développeurs de WebKit ont annoncé que cette pratique allait prendre fin. Une nouvelle très attendue par les développeurs qui voyaient s’installer une sorte de contre-pouvoir au W3C, avec ses propres règles. Dans un billet de blog, l’ingénieur Edward O'Connor (Apple), indique que l’idée initiale de supporter en avance les technologies via des préfixes « n’a pas si bien fonctionné ». Pourquoi ? Parce que de « nombreux sites web sont devenus dépendants des propriétés préfixées ».
Un reproche fait depuis longtemps à WebKit justement. Et pour donner une idée de la problématique, rappelons que Mozilla avait été forcé de supporter les préfixes de WebKit dans Firefox tant de nombreux développeurs ne se référaient qu’au moteur le plus utilisé sur les mobiles. Nous avions alors partagé un sentiment mitigé, avec d’un côté un avantage pour les utilisateurs, et de l’autre un échec pour le web.
Mais concrètement, comment compte faire WebKit pour continuer à tester les nouveautés ? Via des « flags », que l’on activera spécifiquement, exactement comme dans Chrome et Firefox. Chaque nouvelle fonctionnalité expérimentale aura son propre flag, et non plus un préfixe spécifique. L’équipe espère que le fonctionnement global sera plus clair pour tout le monde, d’autant qu’il n’a pas d’impact immédiat.
Les flags ne seront en effet surtout valables que pour les nouvelles technologies, laissant tranquilles celles qui fonctionnent pour l’instant avec des préfixes. Tout supprimer dès maintenant aurait sans conteste des effets désastreux sur l’affichage des pages web. Les CSS seront donc progressivement nettoyés de leurs préfixes sur les prochaines années, mais on peut d’ores et déjà estimer qu’il s’agit d’une victoire pour l’ouverture du web.
Commentaires (41)
#1
C’est très bien, l’abandon des préfixes. Ca allait à l’encontre de l’esprit du web, où un même code doit fonctionner quel que soit le support.
#2
Le monde des navigateur se pacifie peu a peu ^^ . C’est bien.
#3
Ca va facturer sec de la maj chez certains " />
#4
Or, les développeurs de WebKit ont annoncé que cette pratique allait
prendre fin. Une nouvelle particulièrement attendue par les développeurs
propres règles. Dans un billet de blog, l’ingénieur Edward O’Connor (Apple), indique que l’idée initiale de supporter en avance les technologies via des préfixes « n’a pas si bien fonctionné ». Pourquoi ? Parce que de « nombreux sites web sont devenus dépendants des propriétés préfixées ».
#5
Recherche - Remplacer : “-webkit-” par “”. Ça vous fera 200€ ma ptite dame " />
Avec LESS et SASS ça ira encore plus vite :p
#6
T’as oubli au moins un 0 " />
#7
Par jour de presta ? :p
#8
On peut applaudir
#9
Bien vu " />
#10
C’est bien d’être en avance là dessus mais …
au niveau de WebRTC ça donne quoi dans les projets d’Apple ?
Parcequ’actuellement, Safari est le seul navigateur (parmi les populaires) à ne pas le supporter du tout.
#11
Apple et Google sentiraient le souffle chaud des procès pour abus de position dominante ?
ENFIN ?
#12
Abus de position dominante. Le mantra juridique du geek… Que dis-je ? Son culte du cargo. On ne sais pas très bien comment ça marche ni à quoi ça s’applique, mais de vieilles légendes parlent d’un procès sur ce motif qui en un temps lointain porta ses fruits.
Alors le geek contrarié par une compagnie ou une autre répète cette vaine malédiction, “abus de position dominante,” en espérant que l’objet de ses aigreurs en soit affligé. Un peu comme souhaiter la syphilis à quelqu’un sans savoir comment on attrape une MST.
#13
C’est encore autre chose que le standard w3c ?
#14
C’est en cours de dev a priori https://bugs.webkit.org/show_bug.cgi?id=124288 :)
#15
#16
Ah, ils auront mis le temps :)
#17
ECMASCript (JS) et W3C (HTML/CSS) c’est deux choses différentes. Tout comme pour d’autres technos : WebGL/WebCL (Khronos), asm.js (Mozilla), etc.
#18
#19
Wooot
#20
Tiens, la lobotomisation marche à fond manifestement !
Google, Apple et Microsoft sont tes amis…. dans les yeux j’ai dis… regarde moi dans les yeux !
#21
Si tu ne vois pas d’abus dans les comportements d’Apple et de Google, on ne peut plus rien pour toi !
Soumission un jour, soumission toujours !
#22
#23
justement !
#24
#25
200€/j c’est pas cher !
Minimum 350 dans le milieu normalement (à Paris en tout cas)
#26
#27
C’est logique, si on considère leur jeunesse, on ne fait pas tourner des avions ou des centrales nucléaires avec les technologies web non plus…
#28
Une approximation honnête en SS2I :
Facturation quotidienne *216 / 1.9 = salaire annuel brut qu’une SS2I peut se permettre de payer en gardant une marge confortable. Si tu es en agence digital ou petite structure, ce coefficient baisse ;)
#29
Heureusement que tu as mis honnête. La mienne doit être plutôt entre 3 et 3.5 (en fonction de si j’inclu les panier assez élevé) et pas 1.9. Après je ne sais pas si le client demande des marges arrières
#30
Nous avions alors partagé un sentiment mitigé, avec d’un côté un avantage pour les utilisateurs, et de l’autre un échec pour le web.
“Ach ya… Nous afons échoué a instaurer la pureté dans le c-SS. Les préfixeu étranchers se zont répandus dans nos codes, nos zerveurs, nos maizons. ya…. Mais tout ca va changer. Même zi le combat sera difficile, nous restaureuront la pureté du c-SS. Et pour cela nous impozerons une stricte obéissanceu à la normalization établie par l’organization internazionale ECMA !! ECMA !!! ECMA !!! ECMA !!!”
Sans déconner, c’est pas un peu exagéré de décrire le support par mozilla des préfixes webkit comme un “échec pour le web” ? L’échec ca n’aurait pas été l’inverse: l’absence de convergence ?
#31
#32
Bien évidemment, tout dépend de ton staffing, si tu es positionné sur une mission longue durée, tu peux t’en rapprocher lors de la négo d’embauche.
Mais le 1,9 n’est pas la norme, juste une approximation de ce que tu pourrais potentiellement demander en focntion d’un TJM.
#33
#34
Merci pour cette réponse très complète " />
#35
Une approximation partagée sur des forums liés au monde des SS2II, aussi bien par des consultants que des commerciaux.
En prenant en compte charge patronales, cout de structures et marge…
Ca permet parfois de négocier une augmentation en se basant sur de vrais chiffres et pas que du ressenti.
Sinon tu peux partir de ton salaire journalier brut (brut annuel / 216), rajouter charges patronales (40%), coût de structures (20%), marge (30%) et tu regardes la différence avec ton TJM.
C’est une autre méthode.
Désolé pour le HS ^^*
#36
#37
#38
En quoi c’est compliqué de respecter une norme ?
#39
#40
#41