Le web en kit

Beaucoup de gens qui fabriquent le web se sont plaints de lʼhégémonie dʼIE6.

Pour protester, ils se sont rués sur les nouveaux arrivants : Firefox et Chrome. Puis les produits Apple ont débarqué, apportant avec eux Safari. Cʼétait encore une révolution — et de fait, le nouvel endroit ou aller. Or Safari fonctionne sur la même base que Chrome, à savoir le moteur de rendu Webkit. Et petit à petit, nous nous sommes retrouvés avec un nouveau monopole.

Malheureusement, on ne casse pas un monopole avec un monopole. Car tous ces gens qui se sont rués sur les navigateurs WebKit ont produit des morceaux de web qui ne sont pas inter-opérables : on ne pouvait sʼen servir (voire simplement y accéder) autrement quʼavec un sésame estampillé WebKit.

Microsoft et Edge

De façon parfaitement sensée, Microsoft — qui détenait environ 95% des parts de marché des navigateurs web (ce qui lui est reproché) — a voulu faire table rase du passé pour en finir avec la mauvaise réputation de son navigateur vedette.^[1]

Alors ils font passer Edge pour WebKit.

Le -webkit-only

Les préfixes vendeurs

Vous commencez à flairer lʼarnaque, pas vrai ? Edge interprète désormais les CSS préfixées par -webkit-. Bon allez, si ça nʼest que ça cʼest de bonne guerre !

Sauf que… Non. Ça ne sʼarrête pas à ça.

Les propriétés hors spécification

Pendant très longtemps, Chrome et Safari ont implémenté des nouveautés avant de les proposer aux concepteurs des spécifications — notamment des propriétés et valeurs CSS. Ça permet de mettre un peu de pression sur le processus de spécification et de tenir en haleine les développeurs.

Parmi ces nouveautés, la valeur text pour la propriété background-clip.

Cette propriété fait partie intégrante de la spécification (en anglais) depuis longtemps. La valeur text a été proposée en 2008 par WebKit (en anglais), et nʼétait — jusquʼà preuve du contraire — supportée que par les navigateurs basés sur WebKit.

Edge gère !

Edge lʼinterprète, cette valeur exotique — et sans souci. Jʼai découvert ça inopinément, en me disant que la solution de repli proposée par Divya Manian (en anglais) était robuste. En terme de logique, elle est imparable : lʼarrière-plan est conçu pour ne sʼappliquer que si le clip est interprété, car lʼensemble est préfixé par -webkit-. Voyez plutôt :

[class="rainbow"] {
  color: #fff;
  display: inline-block;
  /* -webkit-only: Chrome, Safari, Opera */  
  background: -webkit-linear-gradient(…);
  background: -o-linear-gradient(…);
  -webkit-text-fill-color: transparent;
  -webkit-background-clip: text;
}

Mais Edge considère désormais les préfixes -webkit- comme des aliases, et les mange tout crus. Ça aurait pu être un problème dans ce cas précis, puisque théoriquement la paire background-clip: text; nʼest reconnue que par les navigateurs basés sur WebKit. Là encore : surprise ! Edge lʼapplique sans rechigner.

Cas isolé ?

De nombreuses techniques ont vu le jour et nʼont vécu que pour WebKit. Je mʼinterroge donc : parmi ces techniques que nous pensons réservées à WebKit, combien dʼautres encore ont atterri dans Edge discrètement ?

Et Windows Phone, on en parle 😄 ?

Et bien… En quelque sorte ! Pour clarifier, précisons que jʼutilise Windows Phone 8.1, qui embarque IE11. Dʼaprès mes lectures sur le blog technique de Edge, ce mécanisme dʼinterprétation des préfixes vendeurs -webkit- nʼest inclus que dans Edge — en tout cas, il nʼy est fait aucune mention du cousin IE11.

Figurez-vous que cʼest pourtant le cas (je suis sûr que vous nʼavez rien vu venir, avec mes gros sabots 😇). Enfin… Presque.

Le cas qui pique

Une fois nʼest pas coutume, Windows Phone et son IE représentent une configuration particulière. En lʼoccurrence, IE11 interprète les valeurs -webkit-linear-gradient(…) mais est incapable dʼappliquer la valeur text pour la proriété background-clip. Oups 🙈 !

Captures à lʼappui

Dans un monde merveilleux et homogène, nous « devrions » voir ceci :

Et, le cas échéant si votre navigateur est allergique aux arc-en-ciels, voici le résultat attendu :

Jusque là, tout va bien. La mécanique est belle, aucun danger grâce à la solution de repli évoquée précédemment. Maintenant, cassons tout ! Voici le rendu sur IE11 et UC Browser sur Windows Phone 8.1 :

Difficile de garantir quoi que ce soit dans ces conditions. A priori ce problème nʼexiste pas dans les versions antérieures de Windows Phone, et il faut noter que la version bureau dʼIE11 nʼapplique pas lʼarrière-plan !

Si vous voulez tester par vous-mêmes ou compléter mes propos, nʼhésitez pas à dupliquer mon dabblet.

Et pour ceux qui rigolent dans le fond, sachez que Windows Phone représente 4% de parts de marché des systèmes dʼexploitation sur mobile en France, entre juillet et septembre 2015 (en anglais). Ce nʼest pas négligeable, si tant est quʼon admette négliger une population.^[2]

1. Jʼaime rappeler aux gens qui pestent après IE quʼil est ma foi fort probable quʼils fissent partie des 95% dʼinternautes qui naviguaient avec. Ça pique. ↩︎

2. Je mettrais dʼailleurs ma main a couper quʼen réalité ce chiffre est déjà sous-estimé, à en croire mes yeux de lynx qui officient dans le tramway, le bus ou le TER à Nantes ↩︎