Jusqu'il y a deux jours, les fondements du Web étaient simples. Le HTML était un standard normalisé par le W3C et les éditeurs proposaient des navigateurs qui géraient au mieux les différentes générations du standard.
Les responsabilités respectives du développeur et de l'utilisateur étaient claires. Le développeur travaillait à rendre le HTML et le JavaScript le plus indépendant possible des déclinaisons HTML des éditeurs, et l'utilisateur choisissait librement son navigateur.
Aujourd'hui ça n'est plus le cas, le webmaster peut suggérer au navigateur une méthode pour traiter et afficher son contenu. Plus même qu'une suggestion, le développeur choisit pour l'utilisateur. Le prétexte technique provient de l'introduction par Microsoft d'une balise <meta> destinée à faciliter la gestion de la compatibilité d'Internet Explorer (IE) 7 et 8 :
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
Google l'a rapidement détourné en publiant Google Chrome Frame, extension d'IE qui remplace le moteur de rendu d'IE par celui, plus rapide et plus fidèle à HTML 5, de Chrome. Les développeurs deviennent prescripteurs du moteur de rendu de Chrome en ajoutant la ligne suivante à leurs pages Web :
<meta http-equiv="X-UA-Compatible" content="chrome=1">
Avec Chrome Frame installé, toute page Web chargée par IE et qui contient cette ligne est en réalité traitée par Chrome au sein d'IE. Chrome dans IE c'est plutôt une bonne chose pour les internautes. Moi qui suis plutôt familier des outils Microsoft, j'ai adopté Chrome sans tergiverser tant Chrome apparaît rapide et léger comparé à IE. Google Chrome Frame va donc donner un coup de jeune à IE -- qui peut même y gagner.
Ce qui est gênant c'est que cet évènement sonne la fin du HTML et le début des HTML. Pour la première fois le HTML quitte la voie "a-navigateur" et peut prendre parti pour un dispositif de rendu. La guerre entre éditeurs se diffuse côté serveur et affecte le HTML.
Va-t-on, par cette astuce technique, assister à une explosion de jargons HTML visant chacun une version de navigateur ? Faudra-t-il installer tous les navigateurs du marchés pour tout voir du Web ?
Imagine having the Google browser-within-a-browser for some sites, the Facebook browser-within-a-browser for Facebook Connect sites, the Apple variant for iTunes, the mobile-carrier variant for your mobile sites — all injected into a single piece of software the user thinks of as his or her “browser”. Each browser-within-a-browser variant will have its own feature set, its own quirks, and its own security problems.
Salut,
Je ne pense pas que cela va révolutionner le fonctionement actuel du web. On ne developpe pas pour des geek mais pour monsieurs/madamme tout le monde et je ne pense pas qu'il vont s'amuser à installer un moteur de rendu différent. Je pense que cela va continuer d'évolué comme en ce momment : rapidité du js et du rendu, nouvelles normes, sécurité. bref la routine ;)
Rédigé par: Vincent | 25 septembre 2009 à 10:37
→ “Le HTML était un standard normalisé par le W3C et les éditeurs proposaient des navigateurs qui géraient au mieux les différentes générations du standard.”
→ “Le développeur travaillait à rendre le HTML et le JavaScript le plus indépendant possible des déclinaisons HTML des éditeurs, et l'utilisateur choisissait librement son navigateur.”
Oulah ! On ne doit pas vivre dans le même monde ;-)
J’avais plutôt l’impression que les éditeurs proposaient des navigateurs qui leur permettaient de tirer la couverture à eux : Microsoft avec Internet Explorer vs Mozilla/Safari/Opera, Apple avec le navigateur de l’Iphone vs le Wap/Smartphones.
Le libre choix du navigateur par l’utilisateur, tu as vu ça où ? On n’en est pas encore là, les utilisateurs restent souvent sur le navigateur par défaut de leur système.
Et si le développeur s’amuse à faire du code qui passe sur un maximum de navigateur c’est qu’il n’a pas envie de développer 2, 3 ou 4 fois le même code et le maintenir, guère pour faire plaisir à l’utilisateur.
Il est vrai que ces denières années ont vu quelques velléités des éditeurs les plus rebelles de coller à des standards mais on est très loin du compte car aussitôt une technologie validée, le champ de bataille se déplace vers d’autres horizons.
→ “Va-t-on, par cette astuce technique, assister à une explosion de jargons HTML visant chacun une version de navigateur ? Faudra-t-il installer tous les navigateurs du marchés pour tout voir du Web ?”
À mon avis cette astuce technique sert uniquement à assurer une compatibilité entre IE7 et IE8. Elle permet d’assurer une compatibilité entre des sites développés exclusivement sur IE7 et qui se trouvent tout chamboulé avec IE8. Je dirais que ça concerne avant tout des intranets développés sur IE7. Je peux me tromper, mais je ne vois pas trop pourquoi un site compatible IE6/IE7/Firefox/Safari/Opera passerait mal sous IE8.
Ensuite il existe déjà d’autres techniques pour régler le comportement d’une page ou d’un serveur vis-à-vis des clients web : la signature du client, les commentaires Internet Explorer, les hacks CSS/HTML.
Qu’en penses-tu ?
Rédigé par: zigazou | 27 septembre 2009 à 09:32
Quand on fait des hacks CSS/HTML, qu'on utilise des commentaires IE ou qu'on travaille à faire en sorte que le même HTML soit bien rendu sur tous les navigateurs, fondamentalement on ne prend pas parti pour un navigateur, non ? Qu'on ajoute des hacks ou pas, c'est le même HTML qui est servi au navigateur (et comme tu le dis, le mieux c'est d'avoir le moins de code spécifique possible, c'est moins de travail de maintenance).
En revanche si l'usage d'une balise qui indique à qui se destine le HTML se développe, on s'éloigne radicalement de cette voie "apolitique", on prend parti. Pour moi le X-UA-Compatible qui spécifie Chrome ou IE est le premier pas dans cette direction.
Science-fiction : on peut imaginer que les PC soient livrés avec les trois ou quatre grands navigateurs du marché et leur système de "frame-switching" à la Google Chrome Frame. On en aurait la vie (de développeur) bien simplifiée. Plus besoin de s'arracher les cheveux pour rendre notre HTML cross-browser, il nous suffirait de spécifier le navigateur de destination... Cool.
Mais la divergence des HTML serait engagée, avec des conséquences difficiles à évaluer. C'est pas pour demain, certes, mais ça peut aller très vite. D'autant plus vite que, comme tu le notes, les éditeurs on déjà tendance à développer leurs propres particularités dès qu'une nouvelle techno apparait.
Rédigé par: DenisDollfus | 28 septembre 2009 à 22:17