Anthony Ricaud

Allez, on continue dans Webkit (parce que ça me botte en ce moment). Je ne suis pas tombé sur beaucoup d'articles en français résumant les nouveautés de Safari 3.1. Et comme on n'est jamais mieux servi que par soi-même...

Commençons par getElementsByClassName. Kékecé ? À l'instar des getElementById, getElementsByTagName, getElementsByName c'est une méthode pour récupérer des éléments du DOM selon un critère, en l'occurence la ou les classes. Par exemple, sur la page d'accueil de ce blog, document.getElementsByClassName('post').length renvoie 20 mais document.getElementsByClassName('post odd').length renvoie 10. Comme toutes ces consœurs, cette méthode marche aussi à partir d'un élément du DOM, restreignant ainsi les résultats.

Il faut faire attention en manipulant la liste renvoyée. Elle est "live", c'est-à-dire que tout changement dans le DOM la modifie (comme getElementsByTagName). Exemple:

var list = document.getElementsByClassName('post');
for (var i=0; i < list.length; i++)
{
  list[i].parentNode.removeChild(list[i]);
  alert(list.length);
}

En exécutant cette fonction sur la page d'accueil, on verra disparaître un billet sur deux et la NodeList diminuera au fur et à mesure. Attention donc en manipulant les résultats. Pour être sûr de ce qui va se passer, on peut recopier le tout dans un tableau classique, mais attention aux performances.

Cette méthode est actuellement supportée par Safari 3.1 (of course) et bientôt Firefox 3 et Opera 9.5. Elle fait partie du brouillon pour HTML 5.

Vous voyez évidemment à quoi ça sert ? Ça accélère considérablement tous les accès qu'on peut faire, si on l'utilise. Et comme de plus en plus de gens utilisent des librairies pour ne pas s'embêter avec les compatibilités entre navigateurs, on va vérifier qu'on bénéficie bien de cette amélioration quand disponible. On va surtout étudier les méthodes du style $ ou $$, qui permettent de sélectionner des éléments à partir d'un sélecteur CSS

• Prototype n'a pas. Pire, ça peut casser dans les anciennes versions.
• jQuery : y a pas non plus.
• mootools : y a pas.
• YUI : non plus.
• base2 : non plus.

Bilan : Ah bah c'est pas génial. Si j'étais mesquin, je dirais que c'est une raison de plus pour ne pas utiliser de librairies Javascript. À leur décharge, ce n'est pas vraiment nécessaire puisqu'elles utilisent XPath lorsque c'est disponible et c'est disponible sur tous les navigateurs ayant cette méthode. Pour jQuery, c'est regrettable, puisqu'elle n'a pas d'implémentation XPath. Bien évidemment, XPath est plus rapide que DOM, mais tout de même plus lent que getElementsByClassName.

Mais finalement, on verra bientôt qu'il y a d'autres méthodes pour nous aider.

Et bien il fallait bien ça pour sortir ce blog de sa torpeur : Compatibility and IE8. Je ne ferais pas l'inventaire de toutes les réactions (on peut trouver assez de liens sur le QA Blog du W3C, mais ça fuse de partout. Que ce soit chez Mozilla, Webkit, Opera ou chez les développeurs web. Il y a bien quelques satisfaits tout de même.

On nous explique que ce nouveau mode de choix du rendu a été inventé par pragmatisme. Lorsque l'on était en mode "standard", on utilisait des hacks pour corriger les bugs de IE6. À l'arrivée de IE7, cette technique ne fonctionne plus puisque les hacks de contournement ont été corrigés mais pas les bugs en question. L'équipe de IE s'était dit que les améliorations n'étant disponibles qu'en mode "standard", le web ne serait pas cassé. C'est là que vient le pragmatisme : "faut pas refaire pareil !".

Les pages sont conçues à un moment précis, pour une version précise du moteur de chaque navigateur. Et bien inventons un moyen de fixer ces pages définitivement. Ça part donc sur une bonne intention, pleine de bon sens.

Là où le bon sens déraille, c'est que cela implique que chaque version d'IE devra intégrer toutes les versions précédentes jusqu'à IE6. Est-ce pragmatique, réalisable ? Bien sûr que non. Il y aura toujours des différences de rendu au fur et à mesure, pour s'adapter à une nouvelle version du système d'exploitation, des changements matériels, etc.

Bon, admettons que ce soit possible (oui, faîtes un effort). Je mets donc un tag pour bloquer à IE8. Mais quel IE8 ? Celui de la sortie ou celui un an plus tard avec les corrections de sécurité ? Ça pose encore plein de problèmes comme les frames et iframes mélangeant des pages ne souhaitant pas le même mode de rendu. Ou encore la question des copier/coller pour "widget".

Ce principe de choix du moteur rappelle aussi les très belles heures du web "Conçu pour Internet Explorer en 800x600". Ressortez tous vos gifs animés !

Évidemment, j'espère que Microsoft reviendra sur sa décision. On voit clairement que cette décision a été prise pour les Intranet qui restent encore la quasi chasse gardée de Microsoft vu l'inertie (tout à fait naturelle) des entreprises. Cette décision n'est pas néfaste pour les pages déjà existantes mais pour les prochaines à venir. Le slogan "Don't break the web" regarde en arrière, jamais en avant.

Au fait, comment fait IE8 pour passer le test Acid2 ?

PS : Merci à Sunny pour son logo

Update : Des solutions ?