Compatibilité web : Firefox va prendre en charge les préfixes WebKit
Pour améliorer sa compatibilité avec les sites web, Firefox va prendre en compte les principaux préfixes de WebKit. « Une grosse partie du web d'aujourd'hui (et en particulier le web mobile) repose sur les propriétés CSS et les fonctions en préfixe -webkit », constate Daniel Holbert, développeur chez Mozilla.
-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.« Nous aimerions vivre dans un monde où les sites web intégreraient toujours des solutions standards (ou au moins des préfixes compatibles avec plusieurs moteurs), mais hélas, nous ne vivons pas dans ce monde », poursuit-il. Et d'indiquer que la solution inévitable pour afficher correctement le web aujourd'hui est d'intégrer une liste de préfixes -webkit fréquemment utilisés, comme le fait par exemple Microsoft pour son nouveau navigateur Edge.
Firefox, qui continuera à utiliser Gecko comme moteur de rendu, est ainsi le dernier navigateur majeur à se rallier à ces fameux préfixes. Ce changement est prévu dans Firefox 46 ou 47 (la version actuelle est la 43).
En 2012, Opera, qui avait alors encore son propre moteur de rendu, avait adopté ces préfixes. La même année, Daniel Glazman, alors coprésident du CSS Working Group, avait mis en garde contre ce nouveau syndrome IE6 (à la différence majeure que WebKit n'est pas propriétaire et fermé, et que ses nouvelles fonctions sont proposées au W3C pour standardisation) :
Sans une réaction forte [de la part des éditeurs de sites web], nous nous dirigeons inexorablement vers une chose : d'autres navigateurs vont commencer à supporter les préfixes -webkit, et transformer ainsi une implémentation unique en un nouveau standard mondial. Cela va créer un standard de facto. Encore une fois. Notre processus de standardisation va être tué. Il ne s'agit pas de savoir si cela va arriver, mais quand.
Mais c'est quoi les préfixes Webkit ?
:up:
C'est quoi le problème si une propriété libre et ouverte devient un standard ? C'est quoi le but de la standardisation si ce n'est pas de simplifier la vie des développeurs et des internautes ? Si encore le projet webkit était particulièrement instable et propriétaire, mais ce n'est pas le cas. Du coup je ne comprends pas bien la réaction de Mozilla sur ce coup là... D'autant plus que webkit a apporté pas mal de chouettes trucs au web.
Je n'ai d'ailleurs jamais bien compris pourquoi les développeurs de navigateurs ne se mettaient pas d'accord à W3C pour supporter les mêmes fonctions et la même syntaxe. Le langage est une chose, le moteur en est une autre.
@joneskind :
Si tu as l'occasion de participer une fois à une séance de travail du W3C, tu comprendras tout de suite : lent, bureaucratique où chacun essaie de défendre son truc. Du coup, les développeurs trouvent des solutions avant eux.
@iPal :
Exactement ça
"C'est quoi le but de la standardisation si ce n'est pas de simplifier la vie des développeurs et des internautes ?"
Mais C'EST le but. Voilà comment WebKit avait introduit les dégradés en 2008 :
background: -webkit-gradient(linear, left top, left bottom, from(#00abeb), to(#fff), color-stop(0.5, #fff), color-stop(0.5, #66cc00));
Si c'était devenu le standard :
background: gradient(linear, left top, left bottom, from(#00abeb), to(#fff), color-stop(0.5, #fff), color-stop(0.5, #66cc00));
Et voilà comment on produit le même résultat après standardisation :
background-image: linear-gradient(#00abeb, #fff 50%, #66cc00 50%, #fff);
Non seulement c'est plus concis, plus lisible puisque la succession des couleurs se fait dans l'ordre de la lecture, mais pour diverses raisons, c'est aussi bien plus logique et flexible de l'avoir classé en background-image.
A mon avis, iPal et pommecroquee sont soit jeunes, soit n'ont jamais eu à maintenir un gros projet pendant des années. L'empressement conduit toujours à ce qu'on appelle la "technical debt" : chaque raccourci qui est pris pour gagner du temps finit par se payer avec des intérêts. Et c'est cumulatif : plus il y a eu de concessions au départ, plus le projet est englué quelques temps plus tard, et pour des années et des années.
Je n'ai mis qu'un exemple, maintenant il faut imaginer ce que ça donnerait avec 50 choses mal pensées qu'on utiliserait pendant de nombreuses années (ou dizaines d'années, plutôt), avec des syntaxes illogiques, des limitations parce qu'on a mal conçu le truc au départ (comme considérer les dégradés comme un fond uni dans la première implémentation)... ça devient vite l'enfer à utiliser au quotidien.
@jackhal :
Il y a empressement et bureaucratie. Il y a un juste milieu aussi. Quand à ma jeunesse, j'ai assisté à ma première réunion du W3C en 1998 alors que je bossais pour l'ennemi juré d'Apple (pas taper).
@jackhal
"c'est aussi bien plus logique et flexible de l'avoir classé en background-image."
Pourquoi un background-image serait plus logique ? Pour moi, le suffixe image fait plutôt appel à une image en pixels. Mais ici on est plutôt dans le vectoriel non ? Ça prête à confusion je trouve.
"il faut imaginer ce que ça donnerait avec 50 choses mal pensées qu'on utiliserait pendant de nombreuses années (ou dizaines d'années, plutôt), avec des syntaxes illogiques,"
Je n'ai pas fait beaucoup de développement web mais j'avais pris l'habitude de me créer un lexique en .txt des différentes instructions utilisées. Comme ça je n'avais qu'à scripter un chercher-remplacer pour mettre à jour mes sites avec la nouvelle syntaxe. Ça marchait plutôt bien la plupart du temps ^_^ !
Erreur de ma page : ça a toujours été considéré comme image.
"Comme ça je n'avais qu'à scripter un chercher-remplacer pour mettre à jour mes sites avec la nouvelle syntaxe. Ça marchait plutôt bien la plupart du temps ^_^ !"
oui mais c'est pas toujours possible. personnellement je me suis fait des fonctions PHP, là c'était plus flexible et puissant (jusqu'à la génération automatique d'images de fond pour les dégradés).
je suis allé assez loin dans les délires, jusqu'à servir des CSS avec seulement les préfixes nécessaires pour optimiser au maximum les temps de chargement.
j'ai largement levé le pied et me contente maintenant de faire de la CSS plutôt standard.
Il était temps. C'est pratiquement le standard du web. Trop d'ouverture chez Mozilla débouche sur la fermeture!
Mozilla ne combat certainement pas l'utilisation des préfixes. Ce serait plus certainement l'inverse.
Mozilla combat la mauvaise utilisation des préfixes qui malheureusement devient la norme.
Qui ne connaît pas SASS/LESS ne devrait pas être autorisé à utiliser des préfixes (et encore moins à livrer en production)
Quand tu connais SASS tu n'utilises plus les préfixes (ou alors tu les utilises a bon escient)
Les préfixes propriétaires sont mis à disposition des développeurs à fin de tests.
Beaucoup de développeurs utilisent malgré tout ces préfixes en production et ce n'est pas une bonne idée. En effet leur stabilité de comportement, leur pérennité n'est en rien garantie.
Google (qui propose via Blink), le moteur le plus utilisé a entrepris de ne plus créer de nouveaux préfixes, et de proposer ces fonctionnalités, via un drapeau "enable experimental web platform features".
Il faut faire attention à ne pas confondre, les licences (libre ici), standards, normes, ou implémentations de standards/normes.
Un des piliers fondateurs du web, c'est l'interopérabilité. Celle-ci ne doit pas être placée derrière les objectifs commerciaux des constructeurs.
---
Normal que la spec de CSS 3 n'avance pas : https://youtu.be/6MqN-9I_nAo ^_^
Ouais... sans préfixes c'est encore pire. Ca ne serait accessible que dans Canary, ok, mais là... abus dans 10... 9... 8... 7...
Mais bon, que faut-il espérer de la boite qui a créé sa propre VM javascript sans la mettre au pot commun, et qui a fini par faire son propre moteur de rendu "débarrassé" de tout ce qui ne servait pas son propre navigateur ?
De la boite qui met régulièrement en production SES technologies sur SON navigateur et SES serveurs pour avoir un avantage concurrentiel ? (SPDY, SPDY 2, SPDY 3, WebP, WebM/VP8/9, QUIC, SDCH...)
Quand Google fait quelque chose, tu peux être sûr que ça pousse les intérêts de la boite plus que tout autre chose.
SPDY est supporté par tous les navigateurs
webP webM VP8 VP9 sont des alternatives libres à des standards payants poussés par d'autres (Apple entre autres).
Si Apple veut libérer du code pour le successeur de h265 on prend.
Si Apple pouvait passer à OPUS et FLAC au lieu de solutions proprios on prend aussi
Oui, maintenant. Mais regarde l'historique : Septembre 2010 dans Chrome, Janvier 2011 pour tous les services de Google.
Première implémentation dans un autre navigateur : 5 juin 2012 (Firefox). Avec une période du jeu de chat et de la souris : Firefox supporte une version de SPDY, Google en change.
IE : octobre 2013
Safari : octobre 2014
A l'extrême minimum, Google a gagné 1 an et demi d'avantage technique sur tous les navigateurs pour des petits sites comme Google.com, YouTube, GMail, GMaps...
Et là je fais comme si le support de SPDY par un seul autre navigateur suffisait, et comme si les mises à jour qui déboulent de nulle part mais mises en prod immédiatement et qui cassent l'intérêt des autres implémentations ne comptent pas, c'est dire si je suis sympa.
Quant aux codecs multimedia, c'est une toute autre histoire. Mais sois heureux, un codec devrait naitre. Apple n'est pas acteur de ce projet mais avec Microsoft, Google, Mozilla, Intel, Cisco, Netflix... il devrait aboutir, et surtout avoir un décodage matériel rapidement.
Mais les projets avec un seul acteur (ou du moins un seul gros acteur) derrière sont généralement voués à l'échec : VP, Theora... Ca ne sert à rien de "libérer du code" pour le fun.
Sinon, Apple ne supporte pas le FLAC mais leur ALAC est libre sous licence Apache, et ils fournissent les sources d'un encodeur et d'un décodeur. Ca n'est plus proprio.
Quant à OPUS... j'avais même complètement oublié que ça existait. En tant que format audio, laisse tomber il a autant d'avenir que le HD-DVD. La guerre est finie, MP3 et AAC ont gagné. MP3 sera libre de droits fin 2017. Je ne sais pas quand ça sera le cas pour AAC mais probablement avant que OPUS se fasse vraiment un nom.
La dev team de MS Edge a annoncé le support OPUS pour l'ORTC ("skype directement dans ton browser sans plugin") dans la dernière Windows Insider Preview.
Le support d'OPUS est assez logique vu que ce codec combine une évolution du codec SILK (le codec VOIP de Skype racheté par MS) avec le codec CELT (équivalent à AAC)
Avec son support dans Chrome, Edge, FF, Opera, OPUS semble donc bien parti pour devenir le standard de facto pour la VOIP direct dans le browser.
Manque à l'appel ? Safari dont on ne connait pas les intentions concernant l'ORTC.
" que faut-il espérer de la boite qui a créé sa propre VM javascript sans la mettre au pot commun, et qui a fini par faire son propre moteur de rendu "débarrassé" de tout ce qui ne servait pas son propre navigateur"
Ne pas confondre standard et implémentations. Que Google ai ses propres implémentations quel est le soucis ? Pour en revenir au schisme webkit/blink, il faut voir que la version de webkit de Google était très largement différente de la version stock, notamment car les objectifs sont très différents (en particulier sur Chrome OS).
"De la boite qui met régulièrement en production SES technologies sur SON navigateur et SES serveurs pour avoir un avantage concurrentiel ? (SPDY, SPDY 2, SPDY 3, WebP, WebM/VP8/9, QUIC, SDCH...)"
On a donc un couplage fort à des fin de tests et démonstration technique à très grande échelle.
Les protocoles SPDY, QUIC, ne sont-ils pas traduits sous forme de brouillons de standards ?
Concernant WebP, et VPx c'est effectivement fâcheux que cela ne débouche pas sur des standards, à voir ce qu'il va sortir de AO Media.
-
"On a donc un couplage fort à des fin de tests et démonstration technique à très grande échelle."
Pour faire un test ou une démo, il n'y a pas besoin d'un milliard de "testeurs".
Quand le test s'applique à tous les utilisateurs et qu'il renforce mutuellement deux produits d'une même boite, j'aurais plutôt tendance à appeler ça un abus de position dominante.
@jackhal :
Mais les dégradés ne sont pas des "background-image" alors ce que tu dis ne fais aucun sens... Tu ne dois pas être un très bon développeur web ! De plus, la SEULE différence avec la méthode webkit et la méthode standard est la suppression des préfixes TO, FROM et COLOR-STOP... car le fonctionnement est le même puisque dans webkit aussi on écrivait dans l'ordre d'apparition et non comme tu l'as montré !
WEBKIT:
background: -webkit-linear-gradient(left, from(red), color-stop(25%,green), to(yellow))
STANDARD:
background: -linear-gradient(left red green 25% yellow)
"Mais les dégradés ne sont pas des "background-image""
Si si, regarde ce qui se passe avec l'inspecteur web. Background c'est un raccourci qui peut remplir plusieurs propriétés. Ca n'est pas le seul, par exemple :
font: 1.2em/1.5 sans-serif;
défini en une fois font-size, line-height et font-family.
"De plus, la SEULE différence avec la méthode webkit et la méthode standard est la suppression des préfixes TO, FROM et COLOR-STOP"
Il y en a un peu plus que ça.
Mais quand tu écris :
background: -webkit-linear-gradient(left, from(red), color-stop(25%,green), to(yellow))
Ca n'est déjà plus la syntaxe du début, cf le blog de WebKit : https://webkit.org/blog/175/introducing-css-gradients/
Article dans lequel on peut voir une erreur de ma part, par contre : ça a toujours été considéré comme image de fond.
Et mon exemple était directement repris des exemples de cet article : http://trac.webkit.org/browser/trunk/LayoutTests//fast/gradients/simple-gradients.html?format=raw
Et ton background: -linear-gradient(left red green 25% yellow) ne fonctionne pas :
- tu as mis un - qui sert aux préfixes,
- left n'est pas standard, c'est "to left". Il a effectivement été question de donner la direction sans "to" mais ça pouvait porter à confusion (origine ou sens ?), et maintenant il faut mettre to direction (ou un angle).
- les valeurs doivent être séparés par une virgule.
"Tu ne dois pas être un très bon développeur web !", comme qui dirait.
P.S. : j'ai justement pris l'exemple des gradients parce qu'il y a eu plusieurs versions. Mais j'aurais tout aussi bien pu prendre le module Flexbox.
À quand Firefox avec une intégration de force touch dedans ?
C'est quoi le forcetouch ? c'est un click avec une pression plus importante ?
Essaye MouseEvent.mozPressure