Web : Google privilégie la vitesse à la richesse

Anthony Nelzin-Santos |

En passant de WebCore à Blink, Google a allégé Chrome de quelque 4,5 millions de lignes de code. Alors que la firme de Mountain View veut améliorer les performances de Blink sur mobile, Eric Seidel propose d’abandonner la spécification CSS Regions — ce qui provoque l’ire de son créateur, Adobe.

Regions facilite la création de mises en page complexes et flexibles, un des talons d’Achille du langage CSS. Cette spécification permet notamment de répartir les contenus d’une page web au fil d’une série de conteneurs, à la manière des blocs de texte de Pages… ou d’InDesign. Elle est prise en charge par Safari sur OS X et iOS, Chrome et Opera donc, mais aussi Internet Explorer : ces quelques démonstrations développées par Adobe illustrent bien son intérêt.

Seidel, spécialiste des moteurs de rendu HTML passé par Apple avant de rejoindre Google, estime cependant qu’elle n’est pas seulement lourde en pratique, mais aussi structurellement trop complexe. Il est rejoint en cela par Håkon Wium Lie, à la fois créateur de CSS et directeur technique d’Opera. La société norvégienne utilise elle aussi Blink et a proposé CSS Multi-column, une spécification certes moins ambitieuse que celle d’Adobe, mais qui permet déjà de répartir du texte sur plusieurs colonnes.

Avec son concept de « fragmentation » (la manière dont des éléments peuvent être répartis sur plusieurs blocs, pages, écrans…), Regions est bien éloignée des préoccupations beaucoup plus prosaïques de Google. Sa remise en cause de certains acquis de l’approche responsive pose aussi problème à un moment d’optimisation des navigateurs mobiles. Péché suprême, elle représente 10 000 lignes de codes, alors que Blink comporte en tout 350 000 lignes de code C++.

Adobe compte travailler avec Google pour tenter de préserver Regions, mais la firme de Mountain View n’est pas loin d’avoir pris sa décision. Chrome a pris une telle importance aujourd’hui que son abandon de Regions pourrait tout simplement signifier l’arrêt de mort de cette spécification. Pour Google, la rapidité de chargement l’emporte sur la flexibilité de la mise en page.

Source
Via Cnet et Chris Coyier. Image de tête : Google.
avatar BestMBP | 

En même temps, les logiciels d'adobe ont toujours été des éléphants.
Très (trop?) complets, certes, mais des usines à gaz.

avatar nayals | 

Entièrement d'accord avec toi ! Visiblement, Adobe ne sait pas faire dans la simplicité.

avatar Androshit | 

@BestMBP

Aucun rapport entre la richesse de l'outil et ce qu'on en fait...

avatar roccoyop | 

On parle bien que quelque centièmes de seconde, c'est bien ça ?

Autant revenir au web d'avant, on met que du texte et on retire les vidéos et les images. Ça va trop booster !

LOL

avatar CKJBeOS | 

Excellent, a trop vouloir mieux on finit par avoir moins bien ;(
il faut garder la fonctionnalité mais l'améliorer.
A quoi bon laisser Google décider ou non de la richesse des outils web ;(((
Google commence vraiment a avoir une attitude de moins en moins "ouverte".

avatar Lennart | 

Et on abandonne Chrome pour "mosaic" :)

avatar zearnal | 

Non Lynx serait beaucoup mieux :)

avatar Mathias10 | 

Région reprend le cl cept d'indesign avec un texte qui se poursuit dans un autre bloc c'est bien ça?

avatar Teenage | 

@Mathias10

Le chaînage c'est pas un truc aussi vieux que les logiciels de PAO : il existait sous Xpress, et même sous MS publisher ?

avatar Liena | 

Une bataille pour imposer un nouveau standard ?

avatar Ast2001 | 

Au niveau du W3C, il y a aussi le flexible box model qui arrive pour gérer le responsive design.Et là aussi, c'est un joyeux bordel.

avatar MrSoul | 

Criez pas au scandale, cette fonction lourde au possible n'a jamais été utilisé, et pour cause, seul webkit en version nightly sait le faire tourner, sans parler du fait que la sémantique de la chose est discutable.

avatar Jiminy Panoz | 

À part dans des démos dont certaines proposent un intérêt très largement discutable tant cela affecte la lisibilité du texte... Mais on ne va pas juger sur une mauvaise utilisation de l'outil.

À savoir que personne ne voulait se cogner l'intégration de la chose, c'est Adobe qui s'en charge elle-même. À savoir aussi que beaucoup expriment ouvertement le fait que la spec est tellement complexe qu'elle sera infiniment difficile à gérer dans le temps... Sauf à passer par les outils qu'adobe ne manquera pas de proposer.

Et ça me rappelle la naissance du format iBooks. Apple, non content que l'IDPF ait choisi la proposition d'Adobe sur l'adaptive layout pour EPUB, sort sa propre proposition via iBooks (faut quand même souligner que techniquement, c'est un énorme bordel, me suis cogné à l'étudier à l'époque). Résultat : Apple envoie sa proposition en quelques mois là où côté EPUB, on doute que l'adaptive layout soit supporté un jour tellement c'est complexe à intégrer (doute y compris chez des gens de l'IDPF qui ont participé à la rédaction des specs).

avatar noAr | 

Microsoft, le retour.

avatar Istrydhil (non vérifié) | 

Adobe a toujours fait des usines à gaz, lourdes à gérer et gourmandes en ressources (notamment dans la gestion des pdf). Il ne faut donc pas s'étonner de ce genre de décision

avatar oxof | 

Y en en marre aussi de sacrifier le design et l'expérience utilisateur au profit du seul moteur de recherche. Si ça continue, on ne va plus faire de la mise en page que pour Google. Et les lecteurs, on s'en fout ?

avatar Lucier_lenlen | 

Heu sérieusement les commentateurs... On se renseigne avant de crier à la perte de possibilités au profit d'un "moteur de recherche" (Google Chrome est un browser au passage)

http://caniuse.com/css-regions

avatar Makime | 

J'aime ton lien juste pour voir la rubrique IE et IE Mobile :D

avatar Armas | 

Je trouve très cynique l'attitude de google qui sacralise l'optimisation alors que de son coté, elle multiplie les gadgets connectés qui consomment une quantité de ressource importante.

Néanmoins, l'action est louable, car Adobe est très négligeant vis-à-vis de l'optimisation de ses outils à l'heure d'internet.

avatar Gui13 | 

Blink ne contient plus que 350kLOC car Google a pu retirer 4,5 Millions de LOC???
Genre, ils ont benné 80% du code de Webkit??
Y a pas une petite erreur là? Les 350kLoc ça doit correspondre à la partie CSS de Blink/Webkit non?

CONNEXION UTILISATEUR