Mozilla vient de publier une nouvelle version de son navigateur Firefox pour iOS. Parallèlement, l’éditeur se prépare à intégrer dans son produit une certaine couche de compatibilité Webkit. Une décision qui aura certainement des conséquences sur la manière dont certains développements web sont envisagés.
Firefox 1.3 pour iOS est disponible depuis quelques heures sur l’App Store. Comme la première mise à jour est parue le 16 novembre, elle commence par proposer une série de corrections pour améliorer la stabilité générale de l’ensemble. Le navigateur n’est en effet arrivé que le 12 novembre et est donc encore jeune. Cette mise à jour apporte également quelques nouveautés plus substantielles, notamment la possibilité de demander facilement la version « desktop » d’un site mobile, autrement dit l’affichage classique que l’on aurait sur un PC ou un Mac.
Firefox 1.3 pour iOS prend en compte les gestionnaires tiers de mot de passe
Bonne nouvelle également pour ceux qui utilisent un gestionnaire de mots de passe sur leur iPhone ou iPad, à la manière de Dashlane, LastPass ou 1Password. Firefox 1.3 ajoute en effet une compatibilité avec ces produits, ce qui permettra aux utilisateurs d’importer leurs mots de passe dans les sites visités avec le navigateur mobile. Ça n’a peut-être l’air de rien, mais ceux qui ont voulu essayer Firefox pour iOS et n’ont pas retrouvé leurs mots de passe ont potentiellement fait demi-tour.
Comme d’habitude, cette version mobile pour le système mobile d’Apple peut se récupérer directement depuis l’App Store. Pour rappel, Firefox est obligé – comme tous les autres navigateurs tiers sur iOS d’ailleurs – d’utiliser Webkit, le moteur de rendu de Safari, pour afficher les pages web. Il ne s’agit donc pas de Gecko.
Webkit, ce moteur omniprésent sur le web mobile
Puisque l’on parle de Webkit, Mozilla a pris une décision qui pourrait avoir des conséquences plus ou moins importantes pour le développement web. L’éditeur est parti d’un constat : ce moteur de rendu dispose d’une présence écrasante sur le parc mobile. Il est bien sûr présent dans Safari sur iOS (et dans sa mouture OS X), mais il a également été longtemps celui de Chrome, jusqu’à ce que Google en crée un fork pour son moteur Blink, repris ensuite par Opera.
Cette présence écrasante fait qu’un certain nombre de développeurs web construisent des sites avec ce que l’on appelle des préfixes : des caractères qui servent à appeler une fonction ou une balise spécifique à Webkit, soit parce que les autres moteurs ne les proposent pas, soit parce que Webkit implémente une technologie d’une manière particulière. Ces préfixes pullulent sur les versions mobiles et ne peuvent être interprétés que par un navigateur Webkit.
Pour les autres, il y a deux solutions : soit il existe un fallback, soit il n’y en a pas. Un fallback est simplement une solution de rechange, dans laquelle le développeur indique au navigateur quoi faire s’il ne sait pas interpréter ces fameuses balises. Quand il est présent, Firefox reçoit par exemple une instruction claire sur la manière de procéder. Mais quand il n’est pas prévu, le navigateur fait au mieux, mais l’internaute a des chances de se retrouver face à une erreur d’affichage… qu’il imputera probablement à son logiciel.
Les principales propriétés CSS de Webkit seront prises en charge
Mozilla est conscient de ce problème. L’éditeur avait intégré mi-2015 une liste blanche de sites dont les préfixes Webkit étaient volontairement pris en charge. La grande majorité de ces sites étaient asiatiques, montrant au passage que les développeurs concernés ne respectaient les standards du W3C et préféraient s’appuyer sur les parts de marché. Six mois plus tard, décision a finalement été prise d’aller plus loin.
Depuis quelques jours dans les versions Nightly (compilées chaque nuit), une fonctionnalité spécifique peut être activée dans le « about:config » de Firefox en cherchant simplement le mot « webkit ». Une fois la valeur fixée à « true », tout site visité contenant les propriétés CSS et fonctionnalités les plus importantes de Webkit seront interprétées par Firefox, pour s’assurer que l’affichage de la page web n’est pas brisé.
Bonne ou mauvaise nouvelle ?
Ce changement, dont les tests ne font que commencer, sont prévus pour être répercutés dans la version stable 46 ou 47, en fonction des retours. Mais c’est à la fois une bonne et une mauvaise nouvelle. D’un côté, les utilisateurs apprécieront certainement d’avoir des sites web parfaitement alignés et dont les différentes zones fonctionnent sans anicroche. De l’autre, certains reprocheront à Mozilla de rendre les armes et de légitimer en quelque sorte le travail des développeurs qui ne veulent pas voir plus loin que Webkit.
Évidemment, les utilisateurs de Firefox pourront tirer les bénéfices de cette décision, surtout sur la version mobile (Android) du navigateur. Sur iOS, la question ne se posera pas puisque Firefox y est obligé d’utiliser directement Webkit. Dans tous les cas, les développeurs intéressés par cette nouvelle compatibilité peuvent récupérer Firefox Nightly depuis la page consacrée à ces versions spéciales. Pour les autres, rappelons que ces moutures ne passent par aucun contrôle qualité et sont donc potentiellement très instables. Mieux vaut attendre que le canal Aurora soit mis à jour, voire le canal Bêta.
Commentaires (58)
#1
Sont en train de faire la même erreur qu’à l’époque des vieux IE… Ce moteur, webkit, devient de plus en plus problématique et la direction de Apple embête tous les dev front ><
#2
Retour dans les années 2000, et tous les problèmes des sites fait pour un seul navigateur…
" />
#3
#4
#5
Et en ce qui concerne edge de Microsoft ? Vu que tu le cites pas :)
#6
Donc en gros, les préfixes -webkit- vont prochainement fonctionner tous les navigateurs qui ont une part de marché non négligeable.
Super, ça va encourager les dévs à faire des efforts …
#7
Y-a-t il réellement une justification à l’utilisation de préfixes -webkit ? Ou les devs ont-ils juste la flemme de faire du less/sass?
#8
Edge a déjà annoncé qu’ils se calqueraient sur tous les “comportements” de WebKit :
http://www.nextinpact.com/news/95478-edge-tout-ecart-rendu-avec-webkit-sera-bug-…
#9
L’article jette la pierre envers les développeurs de sites web et in fine envers webkit, mais il faut surtout rappeler que c’est ce qui a été préconisé par le W3C concernant les préfixes en beta.
On en est arrivés là car webkit était à la fois en avance (ou plus précisement firefox/IE en retard) et à la fois majoritaire sur le mobile, mais à vrai dire, on ne peut pas reprocher grand chose ni à webkit, ni aux dév.
Le seul reproche que l’on peut faire aux devs est de ne pas avoir fait de mise a jour de leurs sites déjà livrés, mais sincèrement je les comprends.
Le vrai problème à la base, c’est le retard qui a été pris par IE et par firefox dans le support des ces tags html5 alors que le mobile était en train d’exploser…
#10
#11
Merci
" />
#12
#13
Et concrètement quels sont ces tags révolutionnaires qui seraient indispensables à la création de sites mobiles ?
Sachant que la mise en page de ceux-ci (souvent déjà pas brillante à la base) est pourrie par les Ads ?
A part les flex box je pense que l’essentiel de ce qui posait problème (radius, gradient…) a déjà une solution standard depuis un certain temps, non ?
#14
Vous avez beau dire ce que vous voulez, le pb c’est que des dev web ont utilisé sur des sites en production, des instruction non standardisées, avec des préfixes (moz ou webkit) justement fait pour tester.
Et qu’on se retrouve à mettre des rustines dans les navigateurs pour que ça fonctionne de partout.
Parce que oui, utiliser en production des standards pas fini, c’est faire de la merde, par ce que tu sais pertinemment que ça va finir par poser des problèmes.
#15
ça fait quand même un certain temps que -moz et -ms existent aussi pour certains comportements CSS beta mais sont rarement ajoutés par les dév à côté des définitions -webkit (ces dév’ étant souvent sous Chrome) d’où le choix de Mozilla et de Microsoft d’interpréter désormais les -webkit pour compenser le laxisme de nos confrères.
#16
Même si webkit est un bon moteur HTML, ça me met pas super a l’aise qu’il n’y en ai plus qu’un …
#17
#18
#19
#20
#21
#22
#23
#24
#25
Ce ne sont pas les devs front le problème, ce sont les clients : “Je veux le même truc trop cool que sur ce site !”.
Soit on est un résistant comme moi et on développe en pure norme (et on perd les marchés et on crêve de faim), soit on en n’a plus rien à foutre et à nous les sousous (et encore, un front ne vaut plus rien aujourd’hui). Le choix est souvent vite fait.
C’est le même problème qu’avec les “contournements” JS/JQuery qui ne tiennent pas dans le temps. Les clients veulent le truc cool pour une bouchée de pain, tu prends un truc JQuery à l’arrache parce que tu ne rentres pas dans ton budget sinon et c’est pêté au bout de quelques temps. Et le client te rappelle en voulant une maj gratos en plus.
Donc perso, je dis niet à ce genre de pratiques. C’est pour ça que je suis en reconversion (et puis, place aux jeunes, je fais du design/front/light back depuis 2000, j’en ai ma claque sérieux).
#26
Cette affaire démontre ce que les bons informaticiens ont toujours su : une spec ne vaut rien, c’est juste un bout de papier, le vrai standard de fait, c’est l’implémentation.
Une grande partie du problème viens du fait que l’ensemble Html+Dom+Javascript n’est pas suffisamment synthétique, limpide et puissant à la base, ce qui aboutit fatalement à un standard qui s’écroule sous sa propre complexité.
Même si l’on en est sorti, la vision du w3c qui était trop mathématicienne et théorique et pas suffisamment informaticienne et pragmatique pour s’adapter aux vrais besoins des gens, tout cela à laissé des séquelles.
Ne fait pas un bon standard qui veut…
#27
#28
#29
Pas d’accord, Apple ne se concerte pas avec les autres, c’est bien pour ça que Google a forké, ça n’avançait pas assez vite pour eux. Apple ne rajoute que ce qui les arrange, et c’est pas forcément les trucs les plus attendus côté front, et en plus ils laissent les prefix… Du coup faut rajouter des outils côté front pour rajouter les prefix en mode automatique ou alors certain navigateur vont les rajouter. IE style.
#30
#31
#32
C’est idiot cette histoire… Plutôt que de supporter -webkit il aurait fallu implémenter les fonctionnalités CSS manquante sans le préfixes non ? Bref que les préfixes deviennent obsolètes plutôt que de les entériner.
#33
#34
#35
#36
#37
Que les asiatiques fassent leurs conneries dans leur coin : rien à cirer - je ne consulte pas de sites chinois ou japonais - et je ne pense pas être le seul ici… J’espère en tout cas que tous les développeurs un peu futés continueront de boycotter en masse les préfixes CSS. On a vu le bordel à l’époque avec un microsoft qui voulait faire sa sauce à lui - aucune raison de reperdre 10 ans !!!
Quand à Mozilla, je pense qu’ils feraient mieux de continuer à améliorer leur debugger javascript qui a certes progressé, mais reste toujours en dessous de chromium, plutôt que de vouloir à tout prix singer le camp d’à côté. L’abandon de Firefox OS pour les smartphones est la pire connerie jamais faite par la fondation - et si le but final est d’avaliser webkit partout, alors autant abandonner tout de suite gecko… S’ils ne croient plus en leur propre produit, alors il faut prendre la décision qui s’impose. C’est dommage notamment pour Firefox OS, parce qu’il ne manquait vraiment pas grand chose pour avoir un webide pratique et fonctionnel - mais la séparation entre l’affichage des sources et le debugger est tout sauf pratique en développement. Il y a comme ça quelques bugs et quelques erreurs flagrantes de conception qui font qu’au bout d’un moment, on retourne sous chromium, tout simplement parce qu’il est plus pratique. Firefox reste mon navigateur de fait au quotidien, mais les derniers choix de la fondation ne rassurent clairement pas sur son avenir. Il serait temps que Mozilla rejoue cartes sur table, et rassure un peu ses usagers.
#38
Sachant pour pour chaque -webkit il y a une propriété standardisée qui va avec (sauf pour deux trois trucs ultra négligeables), je vois pas pourquoi tout ce tapage encore une fois.
" />
En plus on est quand même en 2016, les préfixes sont ajoutés automatiquement avec des outils tiers, taper ces immondices a la mano faut pas abuser non plus, comme si les devs allaient faire “exprès” parce qu’avec du -webkit on obtenait des rendus différents.
Edit: En plus les gens pigent pas ce que sont les préfixes, c’est pas du tout du vodoo propriétaire comme certains aimeraient le faire croire, c’est simplement des fonctionnalités normées (W3C/CR pour la plupart) qui ne sont pas encore implantées selon le standard (donc ça se comporte pas forcément comme attendu), rien de plus.
Enfin je suis ptet naïf et y’a peut-être des abrutis qui codent en flexbox en mettant juste les préfixes sans mettre la propriété officielle
#39
Pff vous abusez tous .. que de commentaires negatifs …
Soyez contents .. ou mangez des sites en Flash pour le reste de l’annee :p
pour revenir sur la “guerre” des moteurs de rendu de page internet
les vrais victimes sont les dev et les utilisateurs
-les dev parce qu’on les prend pour des girouettes
-les utilisateurs parce qu’ils risquent de devenir enfermés
(meme le fork d’opera utilisera webkit … et non gecko …)
quant aux prefixes CSS (et au HTML en general ..)
si le W3C faisait bien / correctement son boulot (au lieu d’etre a la solde de …)
on ne se retrouverait pas a devoir jongler sur un fil
je prendrai l’exemple ahurissant de la gestion des scrollsbars ..
3 moteurs differents >
2 systemes de code differents (avec des fonctionnalités chez l’un non implente chez l’autre et vis et versa)
et 1 qui n’affiche rien du tout … (et bien oui, pourquoi s’emmerder a l’implanter, utilisez le flash ou le JScript .. oh wait …)
#40
#41
#42
#43
#44
@sr17
Un bon webmaster ne crèvera pas de faim. Mais je suis d’accord pour dire qu’en agence de comm, les jeunes développeurs manquent souvent d’expérience et de recul, et font parfois (et même souvent) n’importe quoi…
Ensuite, c’est au client de savoir avec qui il travaille et ce qu’il achète.
Côté Firefox OS, viser un OS full web n’est pas débile du tout, et Mozilla a prouvé que techniquement, ça marche. En outre, l’avantage de développer en full web reste qu’on peut adapter le programme facilement à d’autres appareils. L’inconvénient est qu’on n’est plus limité en accès bas niveau.
Bref, ça dépend jusqu’où on veut aller. Mais la vision de Firefox OS n’est pas incohérente côté grand public, car elle suffit finalement à la grande majorité des usagers. Le problème de Firefox OS est plutôt sa visibilité, et le fait que commercialement, la fondation n’a effectivement pas la puissance commerciale d’un géant pour menacer le cartel en place, surtout en Europe où l’on peut vendre n’importe qu’elle merde à des gens qui n’y comprennent rien.
#45
Non, c’est vrai qu’on y est pas, mais j’ai peur d’une tendance qui pourrait devenir probable.
Ta remarque est bonne, j’avoue volontiers avoir une vision très classique d’un marché où plus la concurrence est bonne (avec plusieurs acteurs faisant valoir leur produit maisons, pas de concurrence déloyal ni d’entente, enfin bref, une bonne concurrence), plus les produits s’améliorent et cela est bénéfique pour les utilisateurs finaux.
J’avais déjà un peu critiqué Webkit pour son coté mangeur de RAM (disons Blink si tu n’est pas d’accord, mais quand je vois Opéra et Vivaldi prends autant de mémoire vive qu’un Chrome, je ne pense pas qu’à une coïncidence), certain aspect graphiques moins agréables qu’un Gecko (par exemple), et je reconnais ses qualités, mais j’ai quand même beaucoup de réticences a accepter un marché dominé par un seul moteur de rendu sans d’autre moteurs d’origines différents pour apporter des valeurs différentes.
Donc je veux bien que tu développes un peu ton point de vue, notamment sur les aspects libres qui ne s’alignent pas avec la vision purement “marché”. Comment tu verrais un futur ou il n’y aurai que des Forks de webkit ? Ca pourrait/devrait être intégré dans les standards W3C ?
#46
#47
#48
#49
#50
J’imagine bien Google implémenter sa propre version de la pile IP de tel manière à ce que les services Google soient optimisé dans leur ecosystème et pour les utilisateurs des services Google, et les autres utiliseront la pile classique avec leur OS/Navigateur standart. Un peu comme les préfixes editeurs quoi XD
#51
#52
Si ça venait à être le cas, il n’y aurait un petit soucis vis-à-vis de la neutralité du net?
#53
C’est vraiment nul comme décision, parce que ça légitime les mauvaises pratiques de dév web : utiliser de l’expérimental Webkit et pire sans mettre l’équivalent non expérimental. On en arrive à légitimer du CSS non standard comme standard et je pense que cette décision doit un peu emmerder ceux du W3C.
Il y a tout de même de bonnes choses qui sont intervenues en voyant les dév utiliser de l’expérimental : arrêter d’utiliser les préfixes pour mettre dernière des préférences/drapeaux, qu’il faut activer à la main (ce qu’aucun utilisateur lambda ne fera). Cette façon est bien meilleure, mais quand je vois l’exemple donné par Mozilla, c’est assez inquiétant sur le niveau de certains dévs.
#54
Tu parles d’une implémentation webkit comme ça :
background-image: -webkit-gradient(linear, left top, left bottom, from(hsl(0, 80%, 70%)), to(#BADA55));
background-image: -webkit-linear-gradient(top, hsl(0, 80%, 70%), #BADA55);
background-image: -moz-linear-gradient(top, hsl(0, 80%, 70%), #BADA55);
background-image: -o-linear-gradient(top, hsl(0, 80%, 70%), #BADA55);
background-image: linear-gradient(to bottom, hsl(0, 80%, 70%), #BADA55);
Marrant, la final ne ressemble pas du tout à l’implémentation webkit… qui en a deux.
#55
#56
Je sais pas, une bidouille dans le Datagramme qui permet de mettre des trucs en plus :p
Je suis pas ingénieur réseau
#57
Comment Google continue sa destruction du Web ouvert au profit de ses environnements…. avec le sourire et la bénédiction de tous…..
Degoogliser le Web est une urgence…..
#58
Je ne comptais lire que les 15 premiers commentaires et le tiens me réconforte parce que je n’ai pas l’impression que les 13 précédents prennent en compte les bourdes des devs.
Qui utilisera Firefox beta ou Win10 en fast update pour un client ou en prod… ? C’est pareil ici.