Fermer le menu
 

WebKit : « un monopole n'encourage jamais à l'excellence »

Stéphane Moussie | | 10:30 |  47

Grâce à l’incroyable succès de l’iPhone notamment, WebKit est devenu en quelques années le moteur de rendu incontournable. Tellement incontournable que Firefox, qui utilise un autre moteur nommé Gecko, va prochainement prendre en charge ses principales spécificités, par l’intermédiaire des préfixes CSS qui lui sont rattachés. Et sur iOS, la fondation Mozilla a fini par céder en adoptant le moteur de Safari pour son navigateur.

En 2012, Daniel Glazman, alors coprésident du groupe de travail CSS du W3C et créateur de BlueGriffon (un éditeur de sites web utilisant Gecko), mettait en garde contre une hégémonie de WebKit (lire : WebKit, nouveau syndrome IE6). Quatre ans et une prédiction avérée plus tard, Daniel Glazman répond à nos questions sur la domination de WebKit.

MacGeneration : D'abord, à quoi servent les préfixes utilisés par les développeurs web ?

Daniel Glazman : Les préfixes CSS sont un mécanisme permettant l'implémentation par les navigateurs d'extensions propriétaires ou de nouvelles fonctionnalités expérimentales. Je vous renvoie à l'article très détaillé que j'ai écrit sur ce sujet.

Extrait de code CSS avec deux préfixes spécifiques à un navigateur. Ligne 106, la ligne commence avec le préfixe -webkit spécifique à ce moteur d’affichage et aux navigateurs qui l’exploitent. Ligne 107, c’est un préfixe exclusif à Firefox sous OS X qui est utilisé.
Extrait de code CSS avec deux préfixes spécifiques à un navigateur. Ligne 106, la ligne commence avec le préfixe -webkit spécifique à ce moteur d’affichage et aux navigateurs qui l’exploitent. Ligne 107, c’est un préfixe exclusif à Firefox sous OS X qui est utilisé. Les deux lignes servent à obtenir le même rendu, mais chacune pour un navigateur.

Il y a quatre ans, vous publiiez « un appel à l'action pour le web ouvert » dans lequel vous mettiez en garde contre« la transformation d'une implémentation unique (WebKit, donc) en un nouveau standard mondial ». En quoi est-ce un problème que WebKit, qui est open source rappelons-le, devienne un nouveau standard mondial ?

Tout d’abord un standard de fait fondé sur un unique produit n’est pas un standard ouvert, c’est un monopole et donc une prison pour les usagers. C’est tout ce que l’on a toujours essayé d’éviter dans le Web, qui doit rester accessible par tous et partout. Si les auteurs Web se limitent au préfixe -webkit quand ils développent des sites ou des applications, ils excluent instantanément tout usager d’un navigateur ne reconnaissant pas ce préfixe.

Mozilla a fait le constat qu'« une bonne partie du web d'aujourd'hui » — pour reprendre les termes du développeur responsable de l'implémentation — utilisait les préfixes WebKit et que tous les principaux navigateurs concurrents les prenaient en charge. N'est-ce pas une décision pragmatique de la part de Mozilla que de supporter ces préfixes comme les autres ?

Je suis bien obligé de vous répondre que oui, même si cette décision me navre, en particulier de la part de Mozilla... Mais que voulez-vous, tout se ligue pour rendre cela indispensable :

  • le mobile domine ;
  • dans le desktop, Chrome domine ;
  • dans le mobile, Android et Chrome écrasent la concurrence ;
  • Android est un marché hyper-fragmenté et Chrome avec. Les vieilles versions de Chrome conservent des versions préfixées de propriétés très utiles ;
  • Safari sur iPhone et iOS est aussi en préfixe -webkit ;
  • les compétiteurs demeurent faiblards : Windows Phone n'arrive pas à prendre une part significative du marché, Firefox OS n'est pas vraiment une réussite (Firefox OS a été abandonné sur smartphone, ndr) ;
  • la communauté des Web Designers ne s'est pas mobilisée plus que ça sur les préfixes ;
  • les éditeurs de navigateurs ont, de multiples manières, encouragé les Web Designers à utiliser et déployer des fonctionnalités maintenues trop longtemps à l'état expérimental, donc préfixées.
Daniel Glazman lors de la conférence Paris-Web 2006. Crédit Raphael Goetter CC BY

Toujours dans cet « appel à l'action » lancé début 2012, vous déclariez que l'une des conséquences du monopole de WebKit serait la mort du processus de standardisation du W3C. En quoi ce processus est-il important ?

La standardisation est une confrontation entre les propositions et les techniques de plusieurs acteurs, et la confrontation amène à l’amélioration, au compromis et in fine à l’interopérabilité. A contrario, une situation de monopole amène quasiment à coup sûr à des choix trop rapides, des choix hasardeux ou suboptimaux, ou les deux. Un monopole n’encourage jamais à l’excellence.

Non seulement vous mettiez en garde contre un monopole de WebKit, mais en plus vous prédisiez que cela arriverait si personne ne bougeait. Alors, à qui la faute ? Aux créateurs de sites web que vous exhortiez « d'arrêter de faire des sites uniquement pour WebKit » ? Le W3C n'a-t-il pas sa part de responsabilité également ? Pour reprendre une critique régulièrement faite à son encontre, le W3C n'est-il pas trop lent ?

J’entends souvent cet argument « le W3C est trop lent ». Mais stop, de quoi parle-t-on, là ? Est-ce le W3C qui standardise ou ses membres ? Est-ce le W3C qui doit produire des suites de tests pour faire évoluer un document de standard candidat à standard tout court ou ses membres ? C’est bien entendu ses membres. Donc arrêtons de dire que le W3C est responsable ; les éditeurs de navigateurs diminuent (ou ont diminué) fortement leur investissement sur les spécifications en cours de standardisation dès le stade de Candidat atteint (la 3e étape du processus de standardisation qui en compte 5 ; les deux restantes sont la validation par les instances du W3C après les tests d’implémentations, ndr). Nous appelons cela le problème du « good enough ».

Cet alignement de Firefox sur WebKit marque-t-il la fin du web ouvert ? Quelle est la prochaine étape selon vous ? L'abandon de Gecko, le moteur de rendu de Firefox ?

Pour l’instant, Gecko implémente uniquement des alias, c’est-à-dire que le préfixe -webkit est reconnu et bascule sur l’implémentation -moz (voire non préfixée) de la propriété. Vous les trouverez sur cette page.

L’étape suivante, c’est malheureusement l’implémentation par un navigateur non Webkit d’une propriété -webkit sans passage du tout par la table du CSS Working Group… Heureusement, le CSS Working Group est une communauté parfaitement vivante et stable, qui reste le lieu unique de publication des évolutions de CSS. Cela ne devrait donc pas arriver facilement.

Catégories: 
Tags : 

Les derniers dossiers

Ailleurs sur le Web


47 Commentaires

avatar Thom80 28/01/2016 - 10:50

Ca fait longtemps que le W3C ne sert plus à rien ... C'est un peu comme la bureaucratie française, d'une lenteur pas possible...

avatar macinoe 28/01/2016 - 11:49 (edité)

L'innovation et l'intelligence ne se décrètent pas.

C'est simple à comprendre.

Les organismes de normalisation dans le meilleur des cas ne peuvent que valider avec énormément de retard des standards de fait et des innovations créées par d'autres.

C'est leur nature et il n'y a rien d'étonnant à ça.

avatar C1rc3@0rc 29/01/2016 - 01:57 (edité)

L'environnement qui permet a l'innovation et l'intelligence de s'exprimer non seulement se décrète, mais un cadre légale est nécessaire pour permettre son émergence et sa duree dans une organisation sociale.

Les organismes de normalisation sont necessaires pour synthetiser les pratiques et connaissances demontrées et eviter de réinventer la roue tous les 4 matins ou de réaliser des choses dangereuses et inefficaces.

Le problème de la normalisation c'est lorsque celle-ci est le fait d'organisations commerciales (corruption, lobbying, idéologie étatique, bureaucratie dirigeante) dans le but de contrecarrer artificiellement un environnement concurrentiel.

« un monopole n'encourage jamais à l'excellence »
Bien sur que si.
Tous les organismes biologiques en sont la demonstration.
La concurrence dans un organisme conduit a sa destruction! Seul les mécanismes de régulation de l'homéostasie garantissent la survie de l'organisme!

Le monopole est délétère lorsqu'il s'établit dans un cadre commercial et comme système de lutte contre la concurrence.

Le monopole dans un environnement collaboratif et coopératif est ce qu'il y a de plus efficace.

C'est d'ailleurs amusant de lire que le systeme de l'economie de marché serait un système concurrentiel, puisque qu'il s'agit a l'inverse d'un système coopératif dont le régulateur d'homéostasie est le consommateur. Et l'on voit aujourd'hui justement que ce systeme n'est mis en oeuvre nulle part...



avatar fgirardey 30/01/2016 - 19:02 (edité)

Tu dis ça sans connaitre alors, la W3C est super utile ! Si Flexbox Layout est aussi bien ficelé aujourd'hui c'est grâce à la W3C qui a pris des décisions de standardisation super importantes !

Non vraiment la W3C est super utile et un web tout WebKit va nous ramener à l'époque infernale d'IE 6…

avatar madaniso 28/01/2016 - 11:14

Le titre marche aussi avec les services publics :)

avatar Moonwalker 28/01/2016 - 11:15 (edité)

Tout cela est plein de bon sens. Malheureusement, ça ne rend pas plus optimiste sur l'évolution du truc.

avatar joneskind 28/01/2016 - 11:25

Merci pour cet article super clair qui m'a fait comprendre les enjeux exacts du W3C, et le problème que pourrait représenter la domination de WebKit. Je dois admettre que je n'avais pas bien compris l'histoire des suffixes, qui sont en fait là pour appeler des fonctions expérimentales.

Il faut dire que pour le peu de développement web que je peux faire, la majorité des fonctions que j'appelle est expérimentale, ce qui m'a donné l'impression qu'il fallait écrire une ligne par navigateur pour que mon CSS fonctionne partout...

Je comprends mieux maintenant le sens de ces suffixes. Mais je comprends mieux aussi pourquoi on considère que le W3C est trop lent ! Par exemple, ça fait déjà des années que je vois un comportement aussi simple qu'une transition de noir et blanc à couleurs sur une image en passant au-dessus, et à ma connaissance il n'existe pas de fonction standard pour faire ça et qui marche dans tous les navigateurs. Il faut toujours faire appel à une fonction expérimentale...

Maintenant, si les navigateurs savent interpréter le suffixe WebKit, c'est forcément que leur moteur est capable de reproduire le même comportement non ? Donc qu'on écrive
Webkit-Tartempion ou Mozilla-Tartempion pour appeler la fonction expérimentale Tartempion, qu'est-ce que ça change ? Pourquoi les développeurs de navigateurs ne se mettraient pas d'accord sur une syntaxe pour les fonctions expérimentales ? À charge du W3C de valider la syntaxe standard par la suite.

J'ai une question pour finir. Y a t-il un endroit, un site web, qui relate les actualités du développement web ? Un site qui soit là pour comparer les différentes propositions des différents acteurs du W3C ? Parce qu'il faut admettre qu'on a aucune idée de ce qui se développe si on fait pas soi-même un gros travail de recherche.

avatar GoldenPomme 28/01/2016 - 12:49

"Webkit-Tartempion ou Mozilla-Tartempion pour appeler la fonction expérimentale Tartempion, qu'est-ce que ça change ?"

C'est la partie après les : qui change, pas juste le suffixe qui précède le nom de la fonction.

"Pourquoi les développeurs de navigateurs ne se mettraient pas d'accord sur une syntaxe pour les fonctions expérimentales ? À charge du W3C de valider la syntaxe standard par la suite."

Parce que ça reviendrait à avoir un w3c pour les fonctions expérimentales où ils devraient tous se mettrent au tour d'un table pour définir la meilleure façon de faire ou le meilleur compromis ?

avatar joneskind 28/01/2016 - 14:25 (edité)

@Golden-Pomme

J'ai pas été assez clair.

Disons que lorsqu'un navigateur propose une fonction expérimentale, il faudrait que tous les navigateurs l'implémentent par défaut avec la même syntaxe pour tout le monde (par exemple avec le suffixe Exp) et libre à chacun de proposer une syntaxe alternative pour la même fonction expérimentale, et à la fin c'est la W3C qui décide.

Y a pas besoin de se mettre d'accord pour la syntaxe expérimentale. Y a un navigateur qui propose une fonction nouvelle. Si les autres navigateurs trouvent la fonction intéressante et qu'ils décident de l'implémenter, ils rendent leur navigateur compatible avec la syntaxe d'origine et documentent leur propre syntaxe. C'est pas plus compliqué que ça. Et c'est les webdev qui vont sur un site spécialisé compilant toutes les fonctions expérimentales qui choisissent laquelle est la plus adaptée ou la plus logique.

avatar françois bayrou 28/01/2016 - 14:31 (edité)

" lorsqu'un navigateur propose une fonction expérimentale, il faudrait que tous les navigateurs l'implémentent par défaut avec la même syntaxe pour tout le monde"

Oui.
En gros il suffirait que tout le monde soit d'accord pour qu'il n'y ait plus de conflit, quoi.

avatar harisson 28/01/2016 - 11:33

J'aime beaucoup les prises de positions parfois radicales de Daniel Glazman, même si, de mon point de vue, il a tort.
Apple a su créer un moteur web opensource performant à partir de KHTML et moins usine à gaz que celui de Mozilla, qui, par "manque de moyens", est toujours en position de challenger (au début c'était internet explorer, maintenant c'est webkit, demain ça pourrait être blink).
Le W3C et l'ECMA sont par nature beaucoup trop lents et très usine à gaz.

avatar lmouillart 28/01/2016 - 12:47 (edité)

C'est déjà le cas, Blink est de loin (très loin même), toutes plateformes confondues le moteur N°1.

avatar harisson 28/01/2016 - 13:04

@lmouillart :

Pas tout à fait encore dans le sens de l'influence sur les technos webs, même si dans les faits il est n°1.

Ce sera le cas quand Daniel Glazman pestera contre le "monopole de Blink" et de ses préfixes -blink-* ^_^

avatar Mrleblanc101 29/01/2016 - 07:54 via iGeneration pour iOS

@lmouillart :
Blink c'est WebKit avec quelques lignes en moins... Google n'a même pas commencer à ajouter du code pour commencer à se distancer/différencier

avatar lmouillart 29/01/2016 - 08:28 (edité)

Chromium et Webkit sont significativement différents, leur architecture dès le début de l'utilisation d'une partie WebKit par Google à diverger de manière forte. C'est notamment ce qui a poussé Google à créer Chromium et tout ce qui gravite autour, en effet avoir 2 cibles si différentes d'un même projet n'avait pas de sens. Le fossé s'est encore agrandi avec WebKit2

Techniquement Blink est plus le fork du composant WebCore de WebKit, le reste de WebKit n'étant simplement pas utilisé

Les moteurs JavaScript sont différents, l'adressage des ressources est différent, les extensions HTML,CSS, JS gérées sont différentes, la manière de les gérer l'est aussi, les toolkits Gfx utilisés sont différents, les api de gestion des plug-ins sont différents, les api de gestion des extensions sont différents, la gestion du cache ... bref quasi tout et depuis Blink : même le moteur de rendu HTML.

avatar fgirardey 30/01/2016 - 19:11 (edité)

Tu confonds moteur de rendu et navigateur.

Chromium contient Blink (fork de WebCore) et V8 (moteur JavaScript de Google).

D'ailleurs aujourd'hui le leader incontesté des moteurs JavaScript est clairement Microsoft avec Chakra, mais ça c'est encore autre chose.

avatar harisson 30/01/2016 - 19:58 (edité)

@fgirardey :

"D'ailleurs aujourd'hui le leader incontesté des moteurs JavaScript est clairement Microsoft avec Chakra, mais ça c'est encore autre chose."

C'est subjectif ou il y a des benchs quelques parts ?

avatar fgirardey 31/01/2016 - 12:00

Oui il y a des benchmarks pardon : http://www.nextinpact.com/archive/46149-navigateurs-comparaison-javascri...

Mais bon après je n'ai fait aucun test moi même hein, je fais confiance à ce qui est dit (peut-être à tort) mais Charka a l'air de faire consensus.

avatar C1rc3@0rc 28/01/2016 - 13:42 (edité)

Surprenant de ne pas evoquer le WHATWG!

En fait le probleme remonte au cafouillage qui devait conduire au XHTML.

Historiquement Microsoft et Adobe ont pourri le WEB avec Internet Explorer et Flash: 2 systèmes propriétaires qui s'ingéniaient a démolir les standards. Ils ont juste reporté leurs stratégies monopolistiques sur le WEB.
Le libre a commence a s'organiser et MS s'est fait taper sur les doigts lourdement et sans pouvoir continuer a utiliser les techniques anticoncurrentielles: IE a perdu son pouvoir.

Restait encore le problème de Flash.
Pour faire des WebApp, en remplacement de Flash, il fallait faire evoluer le HTML. Les acteurs de la norme XHTML voulaient réaliser une usine a gaz (avec SVG, etc) qui allaient jamais aboutir a temps et laisserait a Adobe et MS le temps de remonter le monopole.
Faut aussi rappeler qu'Oracle voulait que Java remplace Flash, mais sans changer le principe!

La reponse fut le WHATWG (Apple, Mozilla, Opera, mais ouvert a tout contributeur) qui allait creer le HTML5.
Plutot que de proposer une norme et d'implementer le navigateur selon cette norme, l'idee etait de proposer des evolutions experimentales avec des prefix, puis de normaliser ces extensions si elles étaient validées par les utilisateurs. C'est l'approche essai-erreur.
Le gros morceau fut Canvas, qui signait l'arrêt de mort de Flash.

De fait le WHATWG n'est pas un organisme de normalisation, c'est le boulot du W3C. Les extensions sont toujours pour des fonctions expérimentales vouées a disparaitre ou a etre integrées dans la norme HTML5 - sans extension.
Bref, personne ne devrait utiliser les extensions pour des sites autres qu'expérimentaux ou tres specifiques.
Apres, Apple, Mozilla et Opera mettent l'ecrasante majorité de leurs travail en opensource...

avatar occam 28/01/2016 - 12:22 (edité)

Jouons le jeu, en remplaçant webkit par ISO 8859:
« Si les auteurs se limitent au codage ISO 8859 quand ils développent des sites ou des applications, ils excluent instantanément tout usager d’un système ne reconnaissant pas ce standard. »
So what ?

Plus loin dans le texte:
Glazman : « La standardisation est une confrontation entre les propositions et les techniques de plusieurs acteurs, et la confrontation amène à l’amélioration, au compromis et in fine à l’interopérabilité. »
En quoi il a raison, ISO 8859 renonce à toute interopérabilité avec EBCDIC.
Again, so what ? Adieu, IBM System/360 ? RIP, depuis belle lurette.

Ça s'appelle la force normative des faits.
Pour lutter contre, il faut créer d'autres faits.

avatar lmouillart 28/01/2016 - 12:59

Si je comprends bien vos propos, les sites doivent donc être faits selon les désidératas de Google, et les concurrents doivent intégrer leurs propositions ou mourir ? C'est assez triste.
L’expérience (leadership ultra-dominant de Microsoft/IE) passé nous a montré que cette situation n'était pas la bonne.

avatar macinoe 28/01/2016 - 13:13

Situation bonne ou mauvaise, ce n'est même plus la question..

La situation des technologie web a toujours été un sacré fatras auquel il a fallut s'adapter.

Quelle serait une bonne situation au juste ?

avatar harisson 28/01/2016 - 13:23

@lmouillart :

C'est pourtant ce qu'il s'est passé avec WebKit de 2005-à_maintenant, KTHML est mort avec l'adoption de WebKit par Konqueror.

Et la situation est meilleure que par le passé par ce que ces moteurs (WebKit, Blink) sont opensource.

avatar lmouillart 28/01/2016 - 13:41

L'interopérabilité, c'est plus un problème de normes et standards qu'un problème de licences.

Je prends l'exemple d'un appareil électrique dont sa prise mâle aurait ses plans disponibles, modifiables, redistribuables (libre en gros), mais qui serait spécifique au constructeur.
De la même manière, les prises femelles ne seraient standardisées, mais les plans seraient eux aussi libres.
Avec votre appareil vous aurez bien du mal pour l'utiliser n'importe où, inversement vous aurez du mal pour utiliser n'importe où n'importe quel appareil.

Dans ce cas, les normes et standards servent donc à cela. Avoir un socle commun, permettant aux produits faiblement couplés de fonctionner ensemble.

avatar harisson 28/01/2016 - 13:54

@lmouillart :

On est dans l'immatériel avec le Web, les implémentations et les usages sont toujours "en avance" sur les "standards" surtout quand ceux-ci ont beaucoup de mal à se remettre en question.

Pages