Blink : Google répond aux questions sur ses choix et leurs conséquences

Blink : Google répond aux questions sur ses choix et leurs conséquences

Du moins en partie

Avatar de l'auteur
Sébastien Gavois

Publié dans

Logiciel

05/04/2013 1 minute
24

Blink : Google répond aux questions sur ses choix et leurs conséquences

Hier, Google a créé l'événement en annonçant qu'il quittait le moteur de rendu Webkit et qu'il créait un fork : Blink. Voulant jouer la carte de la transparence, la firme de Mountain View a publié une vidéo d'un peu plus de 30 minutes afin de répondre aux questions des internautes.

chrome

 

C'est officiel, Google prend ses cliques et ses claques et quitte Webkit afin de monter, et surtout diriger, son propre projet en parallèle : Blink. L'idée est claire : être le seul maitre à bord et pouvoir décider de l'orientation de son moteur de rendu pour Chrome, sans avoir à en discuter avec Apple, entre autres.

 

Suite à cette annonce, plusieurs responsables de la firme se sont prêtés à un jeu de questions réponses. Certaines sont relativement basiques, tandis que d'autres essayent de pousser plus en profondeur les tenants et les aboutissants de ce changement important de stratégie :

 

Notez que les 22 questions sont détaillées ici avec des liens directs vers la partie de la vidéo qui les concernant.

 

 

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Fermer

Commentaires (24)


Alors ça c’est la loose !



Selon moi ils vont dans le sens inverse de ce qu’il faudrait, à savoir, que tous les navigateurs s’uniformise sous un même moteur de rendu.



J’espère au moins qu’au niveau du codage on aura pas à tout refaire pour assurer la compatibilitée de nos sites, pas que ce soit compliqué à faire mais c’est quand même chiant…



Entre les -moz- | -ms- | -o- (qui va bientôt disparaitre) | -webkit- doit on s’attendre à un -blink- supplémentaire ?


Un seul moteur de rendu pour tous est peut être la pire chose qui puisse se produire.








Narjhan a écrit :



Entre les -moz- | -ms- | -o- (qui va bientôt disparaitre) | -webkit- doit on s’attendre à un -blink- supplémentaire ?







Non, un des objectifs de blink est de virer les préfixes customs (source).









Doc_Nimbus a écrit :



Un seul moteur de rendu pour tous est peut être la pire chose qui puisse se produire.





Pourquoi ?



Opera veut utiliser blink maintenant <img data-src=" />








Esarend a écrit :



Pourquoi ?



“L’ennui naquit un jour de l’uniformité.”

(Antoine Houdar de La Motte)



Plus prosaïquement, si c’est pour refaire ce qu’a tenté de faire IE4, non merci !



Je suis plutôt satisfait de cette nouvelle, voir webkit seul sur le marché des rendus navigateurs aurait été très préjudiciable à long terme.







Esarend a écrit :



Pourquoi ?





Parce qu’avec une seule vision, l’innovation se meurt.









Narjhan a écrit :



Alors ça c’est la loose !



Selon moi ils vont dans le sens inverse de ce qu’il faudrait, à savoir, que tous les navigateurs s’uniformise sous un même moteur de rendu.



J’espère au moins qu’au niveau du codage on aura pas à tout refaire pour assurer la compatibilitée de nos sites, pas que ce soit compliqué à faire mais c’est quand même chiant…



Entre les -moz- | -ms- | -o- (qui va bientôt disparaitre) | -webkit- doit on s’attendre à un -blink- supplémentaire ?





A la base aucun développeur ne doit utiliser ces préfixes car ils sont uniquement utilisés pour activer des fonctionnalités expérimentales.



Les prendre en considération lorsqu’on est en phase de développement est la plus grave des erreurs que l’on puisse commettre.



Les préfixes sont un faux problème.









Doc_Nimbus a écrit :



Un seul moteur de rendu pour tous est peut être la pire chose qui puisse se produire.





Un peu du mal avec cette façon de penser perso.

Certes, dans l’absolu : plus il y a de choix, plus les utilisateurs s’y retrouvent en fonction de leur utilisation et de leurs besoins.



Mais là on est pas dans l’absolu, on est dans un cas très spécifique, et le constat est le suivant : on a des standards, mais interprétés différemment par chaque moteur (niveau perf ok, mais aussi et surtout niveau rendu)… rendant ces mêmes standards caducs.



C’est un cauchemar pour les développeurs web en terme de test (la fragmentation des résolutions/définition/formats des écrans de smartphone/tablettes ne faisant qu’empirer la chose), gonflant inutilement les coûts et temps de conception.



Même en me positionnant en simple utilisateur, j’apprécierai grandement avoir la garantie d’un rendu identique de mes sites favoris d’un device à un autre.

Un moteur de rendu unique ne me gênerai pas le moins du monde… tant qu’il n’est pas proprio of course <img data-src=" />



Ou alors on demande à un organisme comme le W3C de définir un standard pour le rendu des éléments, les moteurs ne se dissociant plus que par leurs performances.









Inpactian a écrit :



Parce qu’avec une seule vision, l’innovation se meurt.





L’inovation est sensé être au niveau des standards web.

Les features non standardisées ajoutées par Chrome, FF, IE et autres (basées sur des drafts ou sur rien du tout) ne sont que des arguments de bataille dans la “guerre des navigateurs”.



“Regardez mon navigateur, il sait faire ça et pas le concurrent, donc il est plus mieux.”



Ces fonctionnalités devraient selon moi être réservées aux builds dev, et en aucun cas se retrouver dans les versions publiques (mais j’omets peut être un détail dont je n’ai pas connaissance ?).









Zed-K a écrit :



L’inovation est sensé être au niveau des standards web.

Les features non standardisées ajoutées par Chrome, FF, IE et autres (basées sur des drafts ou sur rien du tout) ne sont que des arguments de bataille dans la “guerre des navigateurs”.



“Regardez mon navigateur, il sait faire ça et pas le concurrent, donc il est plus mieux.”



Ces fonctionnalités devraient selon moi être réservées aux builds dev, et en aucun cas se retrouver dans les versions publiques (mais j’omets peut être un détail dont je n’ai pas connaissance ?).





En respectant les standards de développement, le site ne peut être que compatible entre les différents navigateurs.



Utiliser les fonctionnalités nouvelles n’est point obligatoire et non l’innovation ne vient pas des standards. Ces standards n’apporteront jamais de l’innovation ; c’est seulement un moyen de définir comment cela doit être mis en oeuvre par tout un chacun.









Inpactian a écrit :



A la base aucun développeur ne doit utiliser ces préfixes car ils sont uniquement utilisés pour activer des fonctionnalités expérimentales.



Les prendre en considération lorsqu’on est en phase de développement est la plus grave des erreurs que l’on puisse commettre.



Les préfixes sont un faux problème.







Non, pas au vue du temps que met un standard à être finalisé, HTML5 ne devrait être finalisé qu’en 2014 par exemple… Et le W3C lui même pousse les dev à utiliser les spec non finalisé implémenté par les différents navigateur.



Regarde les site grands publiques à fortes audience, ils utilisent tous des spec non finalisé aux implémentations variée pour chaque navigateurs. Et heureusement j’ai envie de dire, sans ça le web n’évoluerai pas. C’est important dans la mise en place et l’amélioration de ces standards.



Après il faut trouver le juste milieux entre ce qui peut être fait et ce qui ne peut l’être en fonction de la manière dont l’utilisateur va être INpacté, des parts de marché et des utilisateurs ciblé.





Bref toujours est-il que pour blink c’est pas une mauvaise chose, webkit en seul moteur de rendu face à gecko me dérangeai un peu. Reste à voir ce qu’ils vont faire.









Inpactian a écrit :



En respectant les standards de développement, le site ne peut être que compatible entre les différents navigateurs.





Compatibles, oui (et encore c’est discutable, cf. caniuse.com), mais identique niveau rendu, c’est une autre histoire <img data-src=" />







Inpactian a écrit :



Utiliser les fonctionnalités nouvelles n’est point obligatoire et non l’innovation ne vient pas des standards. Ces standards n’apporteront jamais de l’innovation ; c’est seulement un moyen de définir comment cela doit être mis en oeuvre par tout un chacun.





J’ai mal formulé : l’innovation doit au préalable être standardisée avant d’être implémentée <img data-src=" />



Une implémentation avant standardisation est utile en guise de proof-of-concept, pour prouver le bon fonctionnement et l’intérêt d’une fonctionnalité.

Elle devrait par la suite donner lieu à une étude par le W3C, une série de drafts, et aboutir sur un standard… mais en aucun cas ne devrait se retrouver sur une release publique àmha.



Sinon je vois pas trop la différence avec l’époque où chacun développait son propre plugin de son côté en se contre-fichant des standards <img data-src=" />



D’autant plus que tous les acteurs susceptibles d’apporter ces innovations (Google, Mozilla, Opera, Apple, Microsoft…) sont précisément membres du W3C…

On en revient à une simple guéguerre entre navigateurs (ou “concours de kikalaplugrosse”, c’est kif-kif) :p









Eclek a écrit :



Non, pas au vue du temps que met un standard à être finalisé, HTML5 ne devrait être finalisé qu’en 2014 par exemple… Et le W3C lui même pousse les dev à utiliser les spec non finalisé implémenté par les différents navigateur.



Regarde les site grands publiques à fortes audience, ils utilisent tous des spec non finalisé aux implémentations variée pour chaque navigateurs. Et heureusement j’ai envie de dire, sans ça le web n’évoluerai pas. C’est important dans la mise en place et l’amélioration de ces standards.







Ça évolue parce que qui utilise les préfixes reportent les problèmes aux dév des navigateurs qui les reportent au W3C.



Et dire que ça évolue pas assez vite quand tu vois la taille de la doc que le représente HTML5 et CSS3.









zefling a écrit :



Ça évolue parce que qui utilise les préfixes reportent les problèmes aux dév des navigateurs qui les reportent au W3C.



Et dire que ça évolue pas assez vite quand tu vois la taille de la doc que le représente HTML5 et CSS3.







C’est bien alors on à le même avis <img data-src=" /> je pense que tu as mal lu ma réponse.



Et évidemment que les spec sont quelques choses de gigantesque qui ne se fait pas en quelques mois, années c’est pour ça que c’est loin d’être un mal de commencer à les utiliser avant une finalisation. Amélioration de ces dernières et évolution plus rapide.









AlexRNL a écrit :



Non, un des objectifs de blink est de virer les préfixes customs (source).







La disparition des préfixes telle que proposée par Mozilla ne changera absolument rien à ceux qui râlent ici.



L’idée est de laisser tomber les préfixes et d’ajouter un flag “utiliser les fonctionnalités expérimentales” mis par défaut à “false”.



Aujourd’hui, ceux qui se plaignent que c’est dur de faire un site parce que leur page passe bien sur X et mal sur Y sont justement ceux qui utilisent des fonctionnalités expérimentales.

Donc, ces mêmes pages seront encore plus cassées sous Firefox.



Le problème, depuis le début, ce sont les développeurs web qui ne comprennent pas qu’une fonctionnalité non standardisée (y compris l’HTML5, tjrs pas finalisé) ne peut pas être implémentée de manière incontournable sur une page web (en d’autres termes: tu peux t’amuser à rajouter des fonctionnalités expérimentales si et seulement si tu fais en sorte que qlq’un qui n’utilise pas ces fonctionnalités puisse utiliser la page web sans problème)



edit:

Ensuite, si la proposition de Mozilla est bonne, c’est surtout parce qu’on sait que Mozilla ne va pas jouer au con “mon navigateur il est meilleur, regardez, cette page passe bien sous mon navigateur mais est toute cassée sur ce navigateur concurrent” comme le font Apple, MS et Google.

Bref, quand Mozilla propose ça, ça a l’air pas con.

Quand Google propose ça, vu son attitude, ça risque surtout de créer encore plus de bordel.









Eclek a écrit :



C’est bien alors on à le même avis <img data-src=" /> je pense que tu as mal lu ma réponse.



Et évidemment que les spec sont quelques choses de gigantesque qui ne se fait pas en quelques mois, années c’est pour ça que c’est loin d’être un mal de commencer à les utiliser avant une finalisation. Amélioration de ces dernières et évolution plus rapide.





<img data-src=" /> En effet.









j-c_32 a écrit :



Ensuite, si la proposition de Mozilla est bonne, c’est surtout parce qu’on sait que Mozilla ne va pas jouer au con “mon navigateur il est meilleur, regardez, cette page passe bien sous mon navigateur mais est toute cassée sur ce navigateur concurrent” comme le font Apple, MS et Google.

Bref, quand Mozilla propose ça, ça a l’air pas con.

Quand Google propose ça, vu son attitude, ça risque surtout de créer encore plus de bordel.







Y’en a qui râle parce que « ::selection » est toujours préfixé pour Gecko alors que celui-ci a été viré des selecteurs de niveau 3 (& 4).









zefling a écrit :



Y’en a qui râle parce que « ::selection » est toujours préfixé pour Gecko alors que celui-ci a été viré des selecteurs de niveau 3 (& 4).





Je ne vois pas trop le rapport.

Que ce soit au niveau du préfixe ou au niveau du niveau d’“expérimentalité” de la fonctionnalité, ça reste du subjectif de la part du concepteur du moteur (car après tout, même si une fonctionnalité est standardisée, ce n’est pas pour ça que l’implémentation par le moteur est reconnue comme parfaite de la part des développeurs).



Ce que fait Mozilla, c’est dire:

c’est pas bien d’utiliser une fonctionnalité qui marche bien sous Firefox et pas sur d’autres navigateurs.



Ce que fait Google (et d’autres), c’est dire:

utilisez cette fonctionnalité géniale. votre site ne marchera pas sous un autre navigateur, mais c’est bon pour nous, on pourra alors dire que ce navigateur est moins performant.



Du coup, l’approche de Mozilla pour supprimer les préfixes a du sens:

plutôt que de faire confiance aux développeurs pour ne pas utiliser les fonctionnalités expérimentales, on va les désactiver par défaut chez l’utilisateur.



Par contre, il y a peu de chance qu’on puisse faire confiance à Google, vu que sa politique est d’activer le plus possible les fonctionnalités expérimentales pour pointer ensuite du doigt les page qui les utilisent et qui passent donc mieux chez eux que chez la concurrence.









Esarend a écrit :



Pourquoi ?





sécurité, perfs…









Inpactian a écrit :



En respectant les standards de développement, le site ne peut être que compatible entre les différents navigateurs.





+10000 les gens qui chialent sont souvent ceux qui ont du mal avec les standard (ou qui utilisent déjà HTML5 certes <img data-src=" /> )









yvan a écrit :



+10000 les gens qui chialent sont souvent ceux qui ont du mal avec les standard (ou qui utilisent déjà HTML5 certes <img data-src=" /> )





C’est bien ça le problème.



Merci au brûlot de feu (see what I did there?) Steve Jobs contre Flash, qui a présenté aux yeux du grand public l’HTML5 comme une solution prête et couvrant tous les besoins du web.

Et les média de relayer le FUD de sa lettre comme parole d’évangile (sans parler des web agency, trop contentes de refaire passer à la caisse leurs clients inquiets <img data-src=" />)



Résultat aujourd’hui, les clients ne veulent plus entre parler de Flash, même pour un simple module garantissant pourtant une meilleure compatibilité que l’équivalent expérimental en “HTML5”.

C’est “Chetemeuleu 5” sinon rien - avec une bonne dose de “raisponsibeul dézaillegne” bien sûr (les nouveaux termes de marketeux sortis à toutes les sauces, remplaçant les bons vieux “Web 2.0” et “AJAX”).



Manque de pot, ni le standard ni son implémentation ne sont finalisées, et une grande partie des fonctionnalités pour lesquelles était utilisé Flash jusque là sont couvertes… dans des drafts, avec des implémentations expérimentales quand il y en a.



Du coup difficile de passer outre si on veut avoir à manger à la fin du mois hein <img data-src=" />









le-gros-bug a écrit :



Opera veut utiliser blink maintenant <img data-src=" />





Normal opera si j’ai bien compris se base à present sur le projet chromium.









Esarend a écrit :



Pourquoi ?









  • parce que sur le long terme, ça revient à ne plus s’appuyer sur le standard (qui n’est pas encore fini, certes), mais sur l’implémentation dominante

  • parce que ça revient à entériner les bugs de ladite implémentation comme des features plutôt que comme des bugs





    Sur le long terme, non seulement ça limite l’innovation, mais en fait, ça gêne aussi bien les devs utilisateurs que les devs fournissant le soft eux-même : quand des millions de devs s’appuient sur des comportements non spécifiés de ton soft, il devient incroyablement difficile de le faire évoluer !

    C’est typiquement ce qui est arrivé à Microsoft avec IE6, mais aussi avec le format de fichier d’office par exemple (ce qui les a obligé à faire un changement cassant avec Office 2007, avec des problèmes de conversion qui subsistent encore)