WebKit supporte 99 % d'ECMAScript 2015 et abandonne les préfixes CSS

WebKit supporte 99 % d’ECMAScript 2015 et abandonne les préfixes CSS

Une victoire

41

WebKit supporte 99 % d'ECMAScript 2015 et abandonne les préfixes CSS

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)


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.


Le monde des navigateur se pacifie peu a peu ^^ . C’est bien.


Ca va facturer sec de la maj chez certains <img data-src=" />




Or, les développeurs de WebKit ont annoncé que cette pratique allait

prendre fin. Une nouvelle particulièrement 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 «&nbsp;n’a pas si bien fonctionné&nbsp;». Pourquoi&nbsp;? Parce que de «&nbsp;nombreux sites web sont devenus dépendants des propriétés préfixées&nbsp;».




Donc, de nombreux sites web dépendent de fonctionnalités en test. C'est magnifique.

Recherche - Remplacer : “-webkit-” par “”. Ça vous fera 200€ ma ptite dame <img data-src=" />

Avec LESS et SASS ça ira encore plus vite :p


T’as oubli au moins un 0 <img data-src=" />


Par jour&nbsp; de presta ? :p


On peut applaudir


Bien vu <img data-src=" />


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.

&nbsp;


Apple et Google sentiraient le souffle chaud des procès pour abus de position dominante ?

ENFIN ?


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&nbsp;répète&nbsp;cette vaine malédiction,&nbsp;“abus de position dominante,”&nbsp;en&nbsp;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.


C’est encore autre chose que le standard&nbsp; w3c ?


C’est en cours de dev a priori&nbsp;https://bugs.webkit.org/show_bug.cgi?id=124288 :)








AlphaBeta a écrit :



Apple et Google sentiraient le souffle chaud des procès pour abus de position dominante ?

ENFIN ?







position dominante, mouais peut être mais ou est l’abus ??? <img data-src=" />



Ah, ils auront mis le temps :)


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.








zefling a écrit :



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.





Merci.&nbsp;<img data-src=" />



Wooot


Tiens, la lobotomisation marche à fond manifestement !

Google, Apple et Microsoft sont tes amis…. dans les yeux j’ai dis… regarde moi dans les yeux !


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 !








AlphaBeta a écrit :



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 !





On parle de Webkit ici pas d’Apple.



justement !








AlphaBeta a écrit :



justement !





Un logiciel open source que tout le monde peut copier et forker.

Ici le problème vient essentiellement des mauvaises pratiques du cote développeur et donc pas en relation avec le projet Webkit directement. Et parler d’abus de position dominante ici est totalement absurde.



200€/j c’est pas cher !

Minimum 350 dans le milieu normalement (à Paris en tout cas)








Lochnar a écrit :



200€/j c’est pas cher !

Minimum 350 dans le milieu normalement (à Paris en tout cas)





Quand je vois combien je suis facturé et combien j’ai sur mon compte à la fin, ça fait mal&nbsp;<img data-src=" />



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…


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.&nbsp;Si tu es en agence digital ou petite structure, ce coefficient baisse ;)


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




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 ?








eax13 a écrit :



Donc, de nombreux sites web dépendent de fonctionnalités en test. C’est magnifique.





Il faut savoir que les règles du w3c imposent qu’il existe au moins une implémentation en production pour qu’une spécification soit validée en recommandation.

Cela peut paraître aberrant mais quand on connait les problématiques liées aux spécificités du CSS (les compatibilités entre propriétés), on se rend compte que seule l’approche empirique permet de valider une spécificité.

C’est pour cela que les préfixes existent : permettre l’implémentation en production sans toucher à l’existant déjà validé.

Dans la pratique, on peut utiliser certaines propriétés non validées dans ma mesure où elle est stabilisées.

Évidemment, la bonne pratique exige qu’il faille utiliser le préfixe de chaque navigateur en plus de la version non préfixée.



Malheureusement, beaucoup se sont contentés du préfixe pour webkit sans connaître la nature des préfixes.

C’est là où se situe l’erreur.

L’usage des préfixes n’en est pas directement l’origine.



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.



&nbsp;








Lochnar a écrit :



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.&nbsp;Si tu es en agence digital ou petite structure, ce coefficient baisse ;)





Je sais pas trop d’où tu tires ton coeff, mais ça correspond plus où moins au salaire que je pense pouvoir avoir en changeant de boîte (avec un bon gap de 15% par rapport à mon actuel).



Merci pour cette réponse très complète <img data-src=" />


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.

&nbsp;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 ^^*








seb2411 a écrit :



On parle de Webkit ici pas d’Apple.





Oui enfin le développement de Webkit est en grande partie cadré par des gens de Apple, c’est pas pour rien que Google a décidé de forker.

&nbsp;



seb2411 a écrit :



Un logiciel open source que tout le monde peut copier et forker.

Ici le problème vient essentiellement des mauvaises pratiques du cote développeur et donc pas en relation avec le projet Webkit directement. Et parler d’abus de position dominante ici est totalement absurde.





Le truc c’est que ça fait longtemps que l’on sait que les préfixes sont néfastes et que tous les autres navigateur ont décidé de passer au système des flags dans les options de configuration. Ça aurait de fait limité les mauvaises pratiques.









Uther a écrit :



Oui enfin le développement de Webkit est en grande partie cadré par des gens de Apple, c’est pas pour rien que Google a décidé de forker.

 

Le truc c’est que ça fait longtemps que l’on sait que les préfixes sont néfastes et que tous les autres navigateur ont décidé de passer au système des flags dans les options de configuration. Ça aurait de fait limité les mauvaises pratiques.





Yep justement. Tu peux forker Webkit et surtout tu peux accéder au code et le réutiliser. Ca evite de fait une abus dans ce genre de situation puisque les concurrent peuvent facilement implémenter ce que Webkit implémente.



Les préfixes ne sont pas néfastes mais simplement mal utilise. Et pour les autres navigateurs le changement vers la désactivation des préfixé est aussi relativement récente. Maintenant ça n’évitera pas d’autres mauvaises pratiques. Et tout ca n’a strictement rien avoir avec un abus de position dominante.



En quoi c’est compliqué de respecter une norme ?








seb2411 a écrit :



Yep justement. Tu peux forker Webkit et surtout tu peux accéder au code et le réutiliser. Ca evite de fait une abus dans ce genre de situation puisque les concurrent peuvent facilement implémenter ce que Webkit implémente.






Sauf que forker webkit n'est pas donné a tout le monde. Si Google a pu le faire c'est qu'il a de sacré moyens. Et encore ils ont du attendre que Chrome ait atteint de très grosses parts de marché avant de se le permettre.       






Si tous les navigateurs récents se basent sur Blink ou Webkit, sans les forker, ce n'est pas pour rien. Même Opera qui avait un excellent moteur Web a du lâcher l'affaire a cause de la culture du Webkit sur mobile et Microsoft a explicitement annoncé qu'il se devait d'être compatible même avec les bugs de Webkit.      






Donc dans la pratique, oui Apple et Google font bien la pluie et le beau temps sur le web, particulièrement sur&nbsp; mobile.      









seb2411 a écrit :



Les préfixes ne sont pas néfastes mais simplement mal utilise. Et pour les autres navigateurs le changement vers la désactivation des préfixé est aussi relativement récente. Maintenant ça n’évitera pas d’autres mauvaises pratiques. Et tout ca n’a strictement rien avoir avec un abus de position dominante.






Il sont justement néfastes parce que mal utilisés, et on ne peut certainement pas compter sur les développeurs Web pour ne pas utiliser une fonctionnalité qui leur est disponible.       

Apple n'a d'ailleurs jamais rien fait pour dissuader leur utilisation en production, bien au contraire, il a fait beaucoup de pub dessus.








Uther a écrit :



Sauf que forker webkit n’est pas donné a tout le monde. Si Google a pu le faire c’est qu’il a de sacré moyens. Et encore ils ont du attendre que Chrome ait atteint de très grosses parts de marché avant de se le permettre.




Si tous les navigateurs récents se basent sur Blink ou Webkit, sans les forker, ce n'est pas pour rien. Même Opera qui avait un excellent moteur Web a du lâcher l'affaire a cause de la culture du Webkit sur mobile et Microsoft a explicitement annoncé qu'il se devait d'être compatible même avec les bugs de Webkit.      






Donc dans la pratique, oui Apple et Google font bien la pluie et le beau temps sur le web, particulièrement sur  mobile.      








Il sont justement néfastes parce que mal utilisés, et on ne peut certainement pas compter sur les développeurs Web pour ne pas utiliser une fonctionnalité qui leur est disponible.       

Apple n'a d'ailleurs jamais rien fait pour dissuader leur utilisation en production, bien au contraire, il a fait beaucoup de pub dessus.







Forker n’a rien de complique, et tu peux maintenir un fork proche de la version originale. Si tout le monde se base sur Webkit ou Blink c’est simplement qu’il n’y a aucun intérêt de ne pas le faire et que les deux projets son open source et donc dispos pour ça.



Au final ce sont les standards adopte qui font la pluie et le beau temps et toutes les décisions récentes vont dans ce sens.



Pour les préfixes ils peuvent facilement être utilise mais en intégrant, soit les préfixes des autres navigateurs avec en priorité la version standardise. Ça prend 1 seconde. Mais l’intérêt devient au final presque null aujourd’hui car les standards avancent maintenant suffisamment rapidement et leur intégration dans les navigateurs aussi pour ne plus avoir vraiment besoin de bidouiller.



Mais tout ça n’empêchera pas certains d’entretenir de mauvaises pratique de toute façon.









seb2411 a écrit :



Forker n’a rien de complique, et tu peux maintenir un fork proche de la version originale. Si tout le monde se base sur Webkit ou Blink c’est simplement qu’il n’y a aucun intérêt de ne pas le faire et que les deux projets son open source et donc dispos pour ça.






 Forker est évidement à la portée du premier venu, mais maintenir et surtout suivre l'évolution du web, clairement pas.        






Si ils utilisent le moteur en l'état, c'est bien pour ne pas avoir a faire la  maintenance et l'évolution qui n'est clairement pas a la portée du premier  venu. D'ailleurs pour utiliser un moteur il n'a pas besoin d'être open-source : Trident est propriétaire et tout a fait utilisable.


Fermer