Les ingénieurs de Google veulent (encore) casser le Web, et se foutent bien des conséquences

Mardi 17 août

On le sait, Google est devenu propriétaire du Web. Plus ou moins.

Suite à toutes sortes de pratiques mafieuses et anti-concurrentielles, leur malware Google® Chrome™ est aujourd’hui devenu quasiment l’unique moyen d’accéder au Web. Et, donc, il dicte quelles fonctionnalités et quelles API sont disponibles pour concevoir des sites et des applications.

Il se trouve justement que, comme une autre multinationale mafieuse et anti-concurrentielle l’avait fait à une autre époque, Google intègre dans son navigateur de plus en plus de technologies non-standard, comme le montrent par ailleurs leurs propres chiffres, sur ce site conçu avec un design system de chez Google, par-dessus un framework JavaScript de chez Google, et qui utilise des liens sans attribut href, qui « fonctionnent » donc uniquement en JS et rendent techniquement impossible d’avoir une URL qui pointe vers un onglet précis. Je dis ça, je dis rien, mais ce site aurait été moins inaccessible en utilisant des <frameset>

Bref. Google rajoute sans cesse des tas d’API dans leur navigateur, selon l’idéologie de l’innovation qui progresse et du progrès qui innove. Des API qui servent leurs intérêts économiques directs, voire même tout simplement leurs besoins techniques internes (qui sont profondément différents de ceux de la quasi-totalité du Web), et leur rouleau compresseur leur permet d’imposer ça à tout le monde sans que qui que ce soit puisse y faire quoi que ce soit.

On ne va pas se mentir : c’est pas cool.

Mais ils peuvent aussi faire pire que de truffer leur malware de brols propriétaires : ils peuvent aussi casser et supprimer les choses standard.

L’éradication des « modales bloquantes »

En l’occurrence, leur dernière grosse connerie en date vise à faire disparaître trois des briques techniques les plus anciennes et les plus fondamentales à disposition du Web : alert(), prompt() et confirm().

La question centrale n’est pas de savoir s’il serait « bien » ou « mal » d’utiliser ces briques. La question est que des millions de sites les utilisent, dont un très grand nombre qui ne sont plus maintenus, ne seront jamais à jour, et dont les conceptrices et concepteurs ne sont peut-être même plus de ce monde (ou alors ils ont fait une markpilgrimade et font aujourd’hui pousser des tomates au milieu de la cambrousse).

Certains ont pointé le fait que la suppression (unilatérale, par Google) de ces trois composants ne concernerait que leur utilisation dans des pages chargées via <iframe>. Mais, d’une part, ça foutrait déjà beaucoup de choses en l’air (comme CodePen et ses semblables, par exemple, qui utilisent ce mécanisme pour des raisons de sécurité, ou bien même une fonctionnalité sur GitHub, comme le rapporte Chris Coyier) et, surtout, d’autre part, les ingénieurs de Google ne cachent pas leur intention (comme ici ou ) de les éradiquer totalement par la suite, dans tous les contextes.

Mais, au fait… Pourquoi vouloir éliminer alert() et ses amis ? Alors qu’ils vivent tranquillement leur vie depuis… [grand geste avec les bras] bien tout ça.

J’ai vu mentionnées des choses comme quoi ce serait « bad for the users », ce qui me fait penser que, un, non, pas « users » et, deux, si Google s’est pris une volée de bois vert sur cette histoire, c’est notamment, justement, parce qu’ils n’ont consulté personne, et ne savent donc absolument pas (et s’en tamponnent royalement — ou présidentiellement) ce dont les gens auraient besoin ou pas. Visiblement, ce qui est bad pour eux, c’est plutôt de défoncer des trucs qui tournent depuis trente ans sans rien demander à personne.

En creusant un peu, il semblerait que les vraies raisons touchent plutôt à de la popote interne, à des questions de dette technique que les ingénieurs voudraient bien éliminer, et à une espèce de quête idéologique pour supprimer toute fonctionnalité/API permettant de bloquer le « main thread » (que ceci soit fait exprès ou pas, cet « inconvénient » étant parfois vu comme quelque chose de désirable).

Ce n’est pas la première fois que Google veut casser le Web pour les caprices de quelques ingénieurs — et, en même temps que j’écris cette phrase, je réalise ce que ça signifie et implique en ce qui concerne la combinaison entre l’immense pouvoir de nuisance acquis par ces gens et leur… désinvolture (pour utiliser un très gros euphémisme). Mais, ici, ils sont encore moins subtils que d’habitude. Apparemment, ils gagnent toujours plus d’assurance au fil du temps.

Histoire de pousser le combo arrogance/indécence encore un peu plus loin, Google propose aux gens qui se sentiraient un peu ennuyés par cette situation de quémander quelques mois de répit, en devant activement demander un « opt out » temporaire. Mais vous finirez quand même comme tout le monde, gueux.

Rappeler les bases

J’ai lu pas mal de bonnes choses écrites — par des gens extérieurs à Google… — en réaction à cette nouvelle agression contre le Web. Notamment cet article de Rich Harris, qui parle, entre autres, de pourquoi les « métriques » et mesures de Google, uniquement quantitatives, sont extrêmement pernicieuses si on les utilise pour mesurer l’usage d’une fonctionnalité. De tous les gens et leurs usages qui passent ainsi sous le radar (notamment tout ce qui concerne l’enseignement. De comment cette manière de procéder est une violation directe des principes à la base même du processus de standardisation (« don’t break the Web », standardiser ce qui existe plutôt que de viser une espèce de pureté idéologique, etc.). Que le Web ne serait jamais devenu ce qu’il est (encore un peu) si des amateurs, sans grandes connaissances techniques, n’avaient pas été capables d’assembler ensemble un peu de HTML et de CSS et de taper le tout sur un serveur FTP,…

Ce dernier point est brillamment — comme toujours — rappelé par Jeremy Keith également, de même que la manière particulièrement vicieuse dont les ingénieurs de Google parlent de casser la compatibilité comme s’il s’agissait d’une chose non seulement acceptable mais même « naturelle » (le progrès qui progresse l’innovation innovante, tout ça… Bref, la marche forcée sous le joug du capitalisme). Il rappelle également fort bien qu’il ne faut pas mélanger les responsabilités des uns et des autres :

Secondly, the onus is not on web developers to keep track of older features in danger of being deprecated. That’s on the browser makers. I sincerely hope we’re not expected to consult a site called canistilluse.com.

Rich Harris mentionnait également la fameuse hiérarchie qui fait que, dans la pratique de mon métier, j’essaie de systématiquement considérer les intérêts des gens (et non des « utilisateurs ») comme étant supérieurs aux miens (ou à ceux de mes consœurs et confrères) :

The W3C's priority of constituencies explicitly states that the needs of users and authors (i.e. developers) should be treated as higher priority than those of implementors (i.e. browser vendors), yet the higher priority constituencies are at the mercy of the lower priority ones.

Au-delà du fait que supprimer ces briques de base imposerait de facto de devoir recourir à des choses plus complexes pour faire la même chose (rendant ainsi l’apprentissage des technologies Web encore plus inutilement compliqué), Heydon Pickering souligne que des alternatives à développer soi-même seront toujours plus problématiques, inefficaces et moins accessibles que les composants d’origine.

Ce qui résonne beaucoup cette démonstration aussi simple qu’excellente de l’impasse qu’est le fait de vouloir réinventer la roue en ce qui concerne les éléments de base fournis par HTML et/ou les navigateurs : You can’t capture the nuance of my form fields.

Ce sont les éditeurs de navigateurs qui décident

Chris Ferdinandi, de son côté, a évalué les arguments « sécurité » donnés par les ingénieurs de Google, et n’y a pas trouvé beaucoup de sens. D’autant plus que, pour le sous-ensemble qui pourrait être considéré comme pertinent, il serait tout à fait possible de trouver des solutions techniques simples et permettant à alert(), prompt() et confirm() de continuer à fonctionner. Ce qui fait penser que ces arguments seraient effectivement davantage des prétextes que de véritables raisons. Après avoir, lui aussi, souligné l’incroyable arrogance du personnel de Google dans cette affaire, il parle brièvement des questions que pose le pouvoir acquis via Chrome. À cette occasion, il affirme que

No one browser vendor should be able to just deprecate a long-standing platform feature without consensus from the others.

Ce avec quoi je suis d’accord, mais j’irais personnellement plus loin. Je ne vois pas en quoi les éditeurs de navigateurs, même s’ils étaient tous du même avis, auraient une quelconque légitimité pour prendre entre eux des décisions ayant de telles conséquences sur l’ensemble des personnes concernées par le Web, depuis les auteurs de spécifications jusqu’aux gens utilisant le réseau au quotidien pour toutes sortes d’usages. « Priority of constituencies », disait-on. Ici, au-delà même d’une question de position dans la hiérarchie, les éditeurs de navigateurs se comporteraient en intermédiaires faisant pression ou chantage sur tous les autres groupes. Comme ces fournisseurs d’accès à Internet étant passés d’un rôle de « fournisseurs de tuyaux » neutres à celui de parasites cherchant à tout surveiller et à interférer avec tout le contenu qu’ils font transiter, que ce soit à des fins d’extorsion d’argent, de surveillance, de censure, etc.

Il se trouve, par ailleurs, que les éditeurs de navigateurs cumulent plusieurs rôles. Car, depuis la création du WHATWG, on peut dire sans caricaturer que ce sont eux qui écrivent directement les spécifications, ce qui les rend juge et partie. Et j’ai déjà eu l’occasion de dire que je ne crois pas au mythe méritocratico-bisounours prétendant que « chaque développeur est libre de contribuer ». Rich Harris n’y croit pas non plus, pour des raisons différentes — et complémentaires — des miennes :

Whenever I've questioned the wisdom of this or that proposal, I've been told I should simply get involved in the standards discussions — they're right there on GitHub! But openness means nothing without the power to effect change, and browsers have all the power.

Donc voilà

Aux dernières nouvelles, les choses prennent bel et bien la direction d’une suppression généralisée de ces trois types de fenêtres modales dans les prochains mois. Pour des motifs très douteux — quand ils ne sont pas carrément fantaisistes et/ou de mauvaise foi — et avec pour conséquence de foutre en l’air une quantité indéterminée de sites qui dépendent de ces fonctionnalités. confirm() fournit un booléen et prompt() une chaîne de caractères, ce sont des instructions qui font partie intégrante d’innombrables programmes.

À côté de ça, un nombre incalculable de tutoriels, cours, démonstrations techniques, etc. seront également rendus obsolètes du jour au lendemain. Tant pis pour les autodidactes qui apprennent avec un bouquin de seconde main, ou via des sites n’ayant plus été mis à jour depuis longtemps. Des gens qui ne comprendront même peut-être pas pourquoi leurs scripts ne fonctionnent pas. Qui se diront peut-être qu’ils ont dû faire quelque chose de travers, et qui laisseront tomber. Des gens dont les ingénieurs de Google et leurs supérieurs n’ont absolument rien à faire.

Tout ceci est vraiment un gros tas de merde. Du pur gaspillage, des décisions prises à la légère, de la mauvaise volonté, de l’arrogance,… Et un « breaking change » de plus.