Anthony Ricaud

During my contract with Mozilla, I decided to check all commits going into the Mercurial repository for the mozilla-central branch. Of course, I'm using the atom feed for that. But after a few days, I discovered that I was missing some commits. Some features went into the nightlies and no sign of the commit in my feed reader.

This is because, by default, the server is only sending the last 20 items. We can change that by using the revcount parameter. So now, my feed reader fetches this feed:

http://hg.mozilla.org/mozilla-central/atom-log?revcount=200

And that should work on every Mercurial project using hgserve.

Il y a déjà 3 semaines (comme ça passe vite), je me rendais à Londres pour @media. Plutôt que d'essayer de faire un résumé objectif, je vais donner mes impressions. Pour quelque chose de plus conséquent (parce qu'il a pris des notes pendant), allez voir chez Jérémie.

Brendan Eich - Grown-up JavaScript

L'inventeur de JavaScript, pour commencer, la grosse classe ! Il a résumé l'avancement actuel de ECMAScript, ce qui va bientôt arriver, ce qui est un peu plus éloigné et encore plus loin, le début de certaines discussions. Et pour conclure, quelques prédictions plus ou moins hasardeuses (de son propre aveu). Par exemple, Apple et Google vont forker WebKit.

Doug Scheppers - SVG today and tomorrow

Sans hésitation, la meilleure présentation des deux jours. Doug travaille au W3C et, comme je lui ai dit, c'est la première fois que je vois une présentation marrante (et donc accrocheuse) d'un membre du W3C (désolé Karl, Dominique et autres). Au final, ce n'était qu'une présentation de l'état de l'art mais le rythme, le sujet méconnu (à tort), et la sympathie qui transpire donne envie de faire du SVG partout.

John Resig - Testing mobile web apps

Le titre de la conférence est trompeur. Au final, il a beaucoup parlé des navigateurs que l'on devrait tester, à la manière des A-grade browser de Yahoo. Et à la fin, on parle un peu de ce que jQuery supportera côté mobile. J'ai été très déçu car je comptais apprendre des choses sur comment tester en général des web apps, plus particulièrement des mobile apps. À part mentionner brièvement TestSwarm, le sujet n'a pas du tout été abordé. Donc au final, c'était une présentation de graphiques, stats sur les parts de marché des navigateurs, une énumération des navigateurs et leurs capacités. Pas grand chose à en retirer.

Simon Willison - Building crowdsourcing applications

Avertissement : je suis ultra fan de ce touche-à-tout. Ayant travaillé pendant 3 ans sur un réseau social, cette présentation me parle beaucoup. Plutôt que d'aborder les problèmes techniques (scalabilité, disponibilité, etc.), il aborde les problématiques sociales, ergonomiques des services communautaires. À travers les exemples du Guardian et de projets persos, il donne des conseils pour réussir à faire participer les gens au maximum. Réduire au maximum les étapes avant pouvoir participer (0 étapes étant l'idéal), comprendre les mécanismes des jeux pour entretenir l'envie de participer, donner des récompenses, travailler énormément pour réduire la sensation de "et maintenant je fais quoi ?", etc. Beaucoup de choses à apprendre.

Mark Boulton - Designing grid systems

La grosse déception du premier jour. Il a passé beaucoup trop de temps à expliquer les mécanismes du cerveau, comment l'être humain réfléchit, comment il a résolu certains problèmes, etc. Au final, seulement 15 minutes sur les grilles. Évidemment, Il est important de donner du contexte à ce que l'on présente, mais pas trop. Au final, pas grand chose à ramener chez soi pour appliquer.

Jeremy Keith's hot topics

La pire table ronde jamais vue… 25 minutes de branlette (désolé pour le terme) sur qu'est-ce qu'un designer, un UX designer, un visual designer, j'en passe et des meilleures. On s'en cogne… Ensuite, "qu'est-ce que HTML5". Oui le marketing ne l'utilise pas comme les techniciens, mais franchement, on s'en cogne. Dernier sujet : les APIs. À peut-être un truc intéressant, et non ! On tombe sur des questions du genre "oh mais y a plein d'API différentes, comment je travaille avec ?", "XML est tellement bien, pourquoi y a plus rien en XML ?". Il y a tellement d'outils pour passer outre cela qu'on manque les questions intéressantes. En voyant cette table ronde et celles de Paris-Web, des fois je me demande si c'est vraiment utile.

Andy Clarke - Hardboiled web design

Très partagé sur cette présentation. J'aime l'idée générale d'oublier les plus vieux navigateurs et allez de l'avant. Mais il ne faut pas non plus faire n'importe quoi avec cette idée. Rajouter des petites touches subtiles (ombres, dégradés, bords arrondis) pas de souci, utiliser de nouvelles techniques et utiliser JavaScript pour combler sur les anciens navigateurs pas de souci, mais donner un look totalement différent selon le navigateur, non ! Son argument est qu'un utilisateur ne verra votre site qu'avec un seul navigateur donc ça ne le dérangera pas. J'objecte fortement. Nous utilisons de plus en plus d'ordinateurs. Il est très fréquent d'avoir, par exemple, un Mac avec Safari à la maison et un IE au travail, ou encore d'utiliser un site en vacances chez des amis. Sur mobile, l'utilisateur s'attend à une autre expérience donc on peut changer de design mais d'un ordinateur à un autre, non.

En plus du contenu de la présentation, j'ai une grosse aversion pour le personnage. Il a passé les deux jours en jean t-shirt mais est venu sur scène avec un costume. La présentation est remplie d'assertions fortes sans justifications. En gros, j'ai senti une grosse différence entre le style anglo-saxon — très confiant, sûr de ses idées, aisance à l'oral — et le style français — présente une idée, souhaite des retours, l'oral est un travail constant.

Matt Biddulph - Mobile social location

Un tour assez complet des interactions qu'apportent les mobiles, ces objets à la frontière du monde réel et virtuel. Ils connaissent beaucoup de choses sur le réel via des capteurs (emplacement, direction, son) qu'ils peuvent communiquer au très puissant virtuel et vice-versa. En tant qu'évangéliste Nokia, il souhaite évidemment que les développeurs trouvent des idées autour de cette liasion particulière. Ça rejoint la notion de "Very personal devices" de Jean-Louis Gassée

Pat Lauke pour Bruce Lawson - HTML5

Cette présentation devait être faite par Bruce mais ayant une extinction de voix, son collègue Pat Lauke s'en est chargé. Au passage, Bruce publie un livre via "Voices that matter", quelle ironie ;) Un tour d'horizon de HTML5, son histoire, ce qu'il apporte niveau compatibilité, niveau nouveaux éléments. J'ai du mal à résumer cette session vu que je connais bien le sujet. Mais je suppose que pour ceux qui souhaitaient apprendre, ce fut une bonne session, informative et fun.

Relly Annett-Baker - All the small things

Une conférence sur les formulations à utiliser et ne surtout pas oublier sur un site. Comment rassurer son utilisateur, ne pas le laisser dans le vide, toujours lui proposer un moyen de résoudre le problème qu'on rencontre. Même si je trouve le sujet important et les conseils donnés plutôt bon, il y a eu beaucoup de répétitions, d'exemples similaires. Dommage, mais c'était compensé par la pêche de Relly.

Steve Souders - Even faster web sites

Comme je connais assez bien le sujet, je n'ai finalement pas appris grand chose. Mais j'ai énormément apprécié la gentillesse et la disponibilité de Steve Souders. Bien qu'il soit l'orateur le plus connu de la discipline, il sait se mettre à niveau et répondre aux questions des débutants comme des confirmés.

Scott Berkun - The myths of innovation

Une dernière conférence très inspirée et inspirante. Pas de code, pas vraiment lié au web mais hautement intéressante. Comment réussir à innover ? Pas juste avoir une idée, parce que c'est la partie simple mais plutôt réussir à la réaliser et arriver à un produit fini. Quelques conseils sur la constitution d'une équipe pour la mettre dans les meilleures conditions, d'autres conseils pour que chacun soit innovant.

Ce sont les fêtes de fin d'année, une bonne période pour prendre du recul sur les choses. Par exemple, le fameux "j'en ai marre de IE6, ça me pourrit la vie". On va donc voir pourquoi on peut déjà l'abandonner, ce qu'on y gagne techniquement et peut-être financièrement.

Pourquoi c'est possible ?

La réflexion a commencé la semaine dernière sur Twitter (enfin sur Identi.ca). Ma réponse à ce cri de détresse était de faire un simple calcul que chaque société devrait faire :

Si l'argent que vous rapporte les utilisateurs de IE6 est inférieur à l'argent que vous investissez pour les avoir, alors oubliez IE6 et vous pourrez passer plus de temps à avoir un site plus agréable pour les autres utilisateurs.

Votre chiffre d'affaires sera inférieur, puisque vous perdez des clients (et encore, pas sur). Mais votre bénéfice augmentera. Bon, je ne vais pas vous expliquer comment calculer la rentabilité de votre entreprise, je n'en suis pas capable mais vous voyez l'idée.

Évidemment, je ne demande pas à tout le monde d'abandonner IE6 ^[1] , seulement si cela vous avantage. Mais réfléchissez, prenons un exemple vague : 20% du temps d'intégration consacré à IE6, 10% de visiteurs sous IE6 qui ne sont pas ceux ayant le meilleur taux de transformation en plus. Est-ce que ça ne vaudrait pas le coup de se passer de tout ça ?

Si vous décidez de passer le cap, n'expulsez pas les utilisateurs sous IE6. Les deux options à envisager sont :

• Proposer une CSS très simplifiée pour IE6 afin d'avoir un style global portant vos couleurs, mais pas plus.
• Fournir le même code mais en prévenant que vous n'avez pas tester et que ça peut péter à tout moment.

Et en complément, proposez d'autres navigateurs pour leur permettre d'avoir une expérience correcte.

Techniquement, qu'est-ce qu'on y gagne ?

Transparence alpha sur les PNG

IE6 ne supporte pas la transparence alpha sur les PNG. Il affiche un fond gris immonde pour les PNG24 ou considère tous les pixels avec un canal alpha comme transparents pour les PNG8. On a donc recours aux horribles filtres IE, immaintenables et lourds en performance. Et encore, ils ne sont utilisables que pour des backgrounds.

À partir de IE7, plus de problèmes, on utilise les PNG que l'on veut, où on veut, roulez jeunesse ! Et cette transparence est très utile pour des ombres, des dégradés, s'adapter à vos différentes couleurs, etc.

Une palette étendue de sélecteurs

Avec ces sélecteurs étendus, on évite beaucoup de trifouillages de HTML. Par exemple, plus besoin de classes spéciales pour sélectionner input[type=submit] ou html[dir=rtl] grâce aux sélecteurs d'attributs. Vous pouvez aussi cibler le premier enfant avec :first-child.

Plus de contrôle aussi grâce au sélecteur adjacent (h1+p) ou au sélecteur enfant (body>div). Pour illustrer une image avec légende, vous pourrez utiliser des sélecteurs simples tels .legend > img et .legend > img + p.

Et mon préféré, les classes multiples. Pouvoir identifier un élément grâce à .menu.active est très pratique. Pas besoin d'ajouter un élément englobant pour contourner cette absence de IE6.

Position fixe et background fixe

Peu de sites s'en servent mais ça peut-être bien utile. Pour avoir une interface toujours sous l'œil de l'utilisateur par exemple. Ou encore avoir une entête de liste toujours visible. C'est une possibilité de design sous utilisée, donc à vos claviers.

:hover partout

Avec IE6, :hover ne fonctionnait que sur les balises <a>. L'avoir sur tous les éléments vous permet de mettre en avant des parties de votre interface au fur et à mesure.

min- max-width et min- max-height

Des design un peu plus souples grâce à cela. Je me rappelle en avoir souvent eu besoin pour dimensionner correctement des images uploadées par les utilisateurs.

De meilleures performances

Vous êtes assurés d'avoir des visiteurs avec un navigateur plus performant. Du coup, vous pouvez utiliser des techniques plus lourdes sans que ça pose problème. Par exemple, IE7 ne passe plus par un ActiveX pour faire des XHR/Ajax.

Moins de bugs !

C'est certainement une des parties les plus intéressantes. Moins de temps à se prendre la tête, moins de temps en QA, moins de machines pour tester.

Avec cela, vous pouvez apporter un site de meilleure qualité, plus léger pour vos visiteurs, plus léger pour votre bande passante et beaucoup plus facile à faire évoluer pour vos développeurs.

Et en plus, on peut gagner plus !

Si vous abandonnez IE6, je vous conseille de communiquer sur cet abandon. Pourquoi ? Je suis persuadé que les technophiles tombant sur votre communication anti-IE6 la relaieront. Il y a une telle haine de IE6 chez les gens passionnés d'Internet que vous en ferez peut-être des clients ou alors juste des relais d'informations. En tout cas, c'est la communication la moins chère du monde, puisqu'en développant moins de code, vous augmenterez votre visibilité.

Le mot final : envisagez sérieusement de ne plus développer pour IE6 en vous appuyant sur des chiffres. Si votre contexte vous permet l'abandon de IE6, vous rendrez service à vous même, vos pairs et vos utilisateurs.

Il y a deux semaine, je présentais avec Aurélien Lévy.

Voici le résumé des points abordés pour ma partie avec quelques liens externes et de bonnes ressources. En gros, c'était mon bloc notes pour me rappeler toutes les nouveautés.

HTML5

• Philosophie Design principles
• Définition du parser, des nécessités user agent VS auteurs
• Nouveaux éléments
  • doctype et charset : faciles à retenir
  • nav, header, footer, section, aside, article : pour mieux structurer le contenu
  • video, audio, canvas : pour rajouter des contenus dynamiques
  • web forms (url, mail, date, range, search, color), required, placeholder, autofocus : plus de contrôle sur les formulaires
• Nouvelles API
  • localStorage, sessionStorage, sql storage : stockage côté client façon clef => valeur ou SQL
  • app cache (manifest) : permet de stocker l'appli offline, couplé au stockage permet de faire du offline complet
  • getElementsByClassName : une nouvelle collection pour traverser facilement le DOM
  • Drag & Drop : bah euh, glisser déposer quoi :)
  • postMessage : permet de communiquer entre deux applis tournant sur des domaines différents, permettant ainsi des "mashups" plus sécurisés.
• Presque lié à HTML5 mais dans d'autres specs
  • XHR cross domain : permet de faire des requêtes Ajax sur d'autres domaines sans passer par un proxy côté serveur
  • Selectors API : permet de sélectionner des éléments à partir d'un sélecteur, comme le font les librairies JavaScript
  • Geolocation API : donne accès à la position géographique
  • Web Workers : lancer du JavaScript dans un autre thread pour faire des traitements lourds qui ne bloque pas l'interface
  • Ecmascript 5 (pdf) (JSON.parse) : plein de nouveautés mais surtout un moyen de parser du JSON nativement et en toute sécurité.
• Ce qui Marche dans IE8
  • JSON.parse
  • Drag & Drop vu que la spec s'est inspirée de ce que IE avait déjà implémenté depuis IE5
  • localStorage, sessionStorage
  • postMessage
  • XDR, c'est XHR cross domain mais avec un objet nommé autrement (mais la même API)
  • Selectors API mais qui ne fonctionne qu'avec les sélecteurs CSS connus par IE8 évidemment.

CSS3

• Petit rappel : CSS 2 n'est pas encore totalement exploité (display: table, inline-block, @font-face, text-shadow, sélecteurs, generated content) ni une spec finale
• CSS 3 est découpé par modules qui sont plus ou moins finalisés et implémentés.
• Candidate Recommandation
  • Media queries : écrire des règles qui ne sont exécutées que si l'appareil/navigateur a certaines propriétés (couleurs, taille, ratio, etc)
  • Marquee : oui oui, le défilement comme <marquee>, très utilisé dans les pays asiatiques visiblement.
  • Basic UI : indique de nouveaux pseudo-sélecteurs et propriétés pour enrichir l'interface utilisateur (::valid, ::required, etc)
• Last Call
  • Selectors introduit de nouveaux sélecteurs plus fins
  • Multi colonnes Colonnage simple sans ajouter d'éléments
• Working draft utilisables
  • Background et border Rajoute beaucoup de possibilités : bords arrondis, bordures avec images, plusieurs arrière plans, ombre
  • Couleurs : Transparence partielle avec RGBA, d'autres espaces de couleurs avec HSL et HSLA, opacity pour la transparence
• Working draft en cours de rédaction
  • Template layout nouveau moyen de faire des layout avec une syntaxe orientée "ASCII art" : display: "aaaaa" "bccdd"
  • Grid positionning nouveau moyen de faire des layout basés sur une construction via des grilles, proche de l'impression papier
  • Transforms 2D/3D permet de modifier l'aspect d'un élément en le tournant, tordant, déplaçant dans un espace 2D ou 3D.
  • Transitions permet de passer d'un état à l'autre d'une propriété avec une transition plutôt que brutalement
  • Animations permet de définir des animations à effectuer.

Ressources externes

• CSS3 info : beaucoup d'exemples de fonctionnalités très simples
• Hacks Mozilla : des exemples plus avancés et concrets d'utilisations de CSS et HTML5
• HTML5 doctor : articles et tutoriaux sur HTML5, les techniques, l'état de l'art, etc.

WebKit ?

WebKit est souvent pris pour plusieurs choses à la fois. On pense que c'est un navigateur, on pense que ce sont les versions de développement de Safari ou tout autre idée répandue. En réalité, ce n'est qu'un moteur web. Tout ceci est bien résumé sur la page d'accueil du projet ou sur Back to the basics. Là où ça devient un peu plus confus, c'est que c'est aussi le nom d'un framework de Mac OS X. Ainsi, il est possible simplement d'afficher du contenu web dans son application en utilisant ce framework. On passe au niveau d'incompréhension supérieur : les nightlies. Régulièrement, des compilations nocturnes sont mises à jour. Il y a le source dans une archive tar.gz. Afin que de nombreuses personnes testent, il y a aussi des versions compilées pouvant tourner avec Safari Mac ou Safari Windows. Elles ne font que lancer le navigateur Safari installé sur votre machine avec une autre version du moteur.

Une autre particularité du projet est l'absence de versions à proprement parlé. Chaque éditeur souhaitant utiliser WebKit choisit ce qu'il souhaite intégrer.

Pourquoi Firebug et Web Inspector ?

Firebug est un très bon outil, pourquoi en apprendre un autre ? Tout simplement, les fonctionnalités, bugs et autres particularités des navigateurs nous obligent à avoir des outils pour analyser nos pages sous chaque navigateur. IE8 intégrera de nouveaux outils annoncés plus adaptés, Opera intègre déjà DragonFly. Et WebKit possède le Web Inspector depuis Safari 2. Une mise à jour a eu lieu avec Safari 3 puis avec Safari 3.1. Mais tout cela restait bien fade par rapport à ce qui arrivera dans la prochaine version majeure de Safari (Safari 4 en bêta depuis quelques jours). Il est intéressant de tester ses pages avec le Web Inspector dès aujourd'hui. Safari représente déjà près de 7% aux États-Unis, cela est appelé a augmenté naturellement par la part de marché croissante des Mac. L'iPhone représente une partie non négligeable du trafic provenant de mobiles. Chrome est désormais sorti de beta. Et il y a bien d'autres logiciels qui embarquent ou embarqueront WebKit.

Fonctionnalités

Pour les fonctionnalités, je vais avoir du mal à retranscrire la présentation, vu que c'était plutôt "hands-on" (et brouillon aussi). Je vous invite à consulter la documentation de Firebug et la présentation des dernières nouveautés du Web Inspector (et ma traduction).

Ce qu'il faut retenir, c'est qu'il n'y a pas que l'onglet HTML de Firebug. Il est bien utile mais l'onglet Réseau (ou Resources côté WI) peut vous aider à améliorer les performances de votre site. Par exemple, on peut regardez quelles ressources prennent vraiment du temps à être téléchargé, quels sont les headers envoyés, reçus. Abusez des profilers si vous utilisez JavaScript. Cela vous permettra de trouver les fonctions les plus lentes ou trop souvent appelées dans votre code. Sans oublier le Débugueur. Positionnez des points d'arrêt, regardez l'état des variables à cet instant, parcourir la suite du code, etc. Autant d'infos précieuses pour comprendre le fonctionnement réel de votre code (ou le code d'un autre site). Et bien entendu, la console permet d'essayer des morceaux de code, d'étudier la page, elle est également disponible lorsque le débugueur est utilisé.

La Console API est tout simplement géniale. Fini le débug avec alert(). Utilisez console.log, console.warn, console.group ou console.assert pour suivre le déroulement de votre application. Vous pourrez les enlever très facilement de votre application en environnement de production et cela vous fera gagner un temps précieux en développement. Contrairement à alert() qui est bloquant, les messages de l'API console ne vous gêneront pas dans vos tests. Abusez-en !

Dans les astuces peu documentées, je rappelle souvent le mot clef debugger; en JavaScript qui permet de mettre en pause l'exécution du script, comme un point d'arrêt classique.

Autre astuce : $0 dans la console permet d'accéder au dernier élément inspecté. On peut ainsi par exemple rapidement faire $0.style.display = 'none'; . $1 permet d'accéder à l'élément inspecté avant $0 et ainsi de suite. Cela n'est pour l'instant valable que dans Firebug.

Contribuez !

Hormis les outils de IE8, tous les autres sont libres, même DragonFly. Ce sont vos outils de tous les jours, ne les négligez pas. Si quelque chose vous gêne, n'hésitez pas à remonter l'info. Il y a bien entendu les bug trackers mais vous pouvez aussi me remonter l'info si vous préférez parler directement à quelqu'un (en tout cas pour le Web Inspector).

Un exemple concret de retours dont nous avons besoin : beaucoup de gens se plaignaient que les styles n'étaient pas éditables. Cela fait longtemps qu'ils le sont et nous ne comprenions pas pourquoi nous avions ces retours. Après quelques discussions, nous nous sommes rendus compte que les gens ne comprenaient pas ce qu'était les "Computed Styles", premier onglet de style ouvert. Depuis ces discussions, cet onglet est toujours présent mais replié. Nous ne pouvions pas découvrir ce problème sans retours.

En plus de cela, si vous souhaitez vous impliquer, sachez que le Web Inspector est intégralement réalisé en HTML/JS/CSS (tout comme DragonFly). Il est donc très facile pour un développeur Web de s'essayer au développement de ces outils.

Quelques URLs utiles :

• Bugs Firebug
• Nouveau bug Firebug
• Bugs Web Inspector
• Nouveau bug Web Inspector

Du 13 au 15 novembre prochains aura lieu la troisième édition de Paris Web. Bon j'aurais du vous en parler plus tôt vu que la période de tarifs réduits est terminée. Mais bonne nouvelle : ça reste plus que raisonnable même à plein tarif.

Au programme, un beau panel. On peut citer Chris Wilson, Daniel Glazman, François Yergeau, Nicole Sullivan, Christian Heilmann, Charles MacCathieNeville, Aaron Leventhal. Et je ne cite là que les noms connus internationnalement. Il reste encore plein de personnes plus intéressantes les unes que les autres.

De mon côté, j'animerais un atelier le samedi sur Firebug et Web Inspector :

Les documents que nous développons sont de moins en moins statiques. Une fois le code écrit, il faut comprendre l’interprétation qu’en font les navigateurs.

Quelles règles CSS s’appliquent à cet élément ?

Quel bug s’est glissé dans mon code JavaScript ?

Pourquoi cette action est lente ?

Nous découvrirons et utiliserons ces deux outils pour répondre à ce genre de questions et plus. Nous parlerons aussi de la Console API et des outils en ligne de commande.

J'aimerais aussi parler un petit peu des nouveautés de WebKit, on va voir sous quelle forme ce sera.

En plus des conférences et des ateliers, il y aura un petit pot libre.

Je vous attends donc tous en grand nombre à cette conférence atypique, organisée par des bénévoles mais de qualité professionnelle. Et si vous comptez passer, laissez un petit commentaire ici histoire de.

Présentation

Comme promis, on va parler de quelque chose de bien plus intéressant pour accélérer vos applications web. Une attente de longue date, la fameuse et célèbre Selectors API ! C'est l'équivalent de $$ en Prototype et Mootools, $ en jQuery, YAHOO.util.Selector.query en YUI et... document.querySelectorAll pour base2. ^[1] Pour ceux qui connaissent, cela permet donc de sélectionner un liste d'éléments qui correspondent à un sélecteur CSS.

L'exemple du billet précédent devient donc document.querySelectorAll('.post'). Une différence à noter entre ces deux méthodes : querySelectorAll retourne une liste statique, un tableau en quelque sorte.

Regardons un peu les performances :

var start = new Date(); for (var i = 0; i < 1000; i++) var list =document.querySelectorAll('.post'); new Date() - start
104
var start = new Date(); for (var i = 0; i < 1000; i++) var list =document.getElementsByClassName('post'); new Date() - start
2

C'est sans appel, pour un sélecteur simple, il vaut mieux utiliser une méthode spécialisée. J'ai fait quelques autres tests. De manière générale, si vous voulez traversez simplement le DOM, tenez-vous en aux autres solutions. Cette méthode sera peut-être optimisée plus tard, ce n'est que la première implémentation.

Évidemment, le navigateur ne reconnaîtra que les sélecteurs qu'il connaît. Pas de problème avec Safari 3.1 puisqu'il connaît tous les sélecteurs disponibles à ce jour (on en reparlera plus tard, peut-être). Par contre, avec IE8, ce sera plus compliqué. Oui oui, IE8 implémentera cette API ! Et comme cette API a été bien conçue, le navigateur est censé renvoyer une exception lorsqu'il ne connaît pas un sélecteur. Le monde est presque parfait !

Les librairies

• Prototype : dans la version de dev (un appel à un div vide puis le vrai appel)
• YUI : rien
• mootools : rien
• base2 : Oui, en dev.
• jQuery : rien.

Le piège.

Le comportement de cette API est pour l'instant trompeuse. Lorsque l'on utilise cette méthode sur un élément, elle va chercher tous les éléments du document qui correspondent puis ne retourne que ceux qui sont des enfants de l'élément. Le comportement des librairies (et qui me semble plus naturel) est d'appliquer le sélecteur à partir de l'élément en question. John Resig en parle bien mieux que moi

Les petits plus

Que peut-on faire de marrant avec cette API ? On peut par exemple récupérer tous les liens présents sur la page qu'a visité l'utilisateur. Un simple document.querySelectorAll(':visited') fera l'affaire.

On peut aussi récupérer la liste de tous les éléments qui sont actuellement survolés par l'utilisateur. document.querySelectorAll(':hover') vous donnera satisfaction.

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.

Le web continue à se remuer après l'annonce de Microsoft. Anne van Kesteren explique d'ailleurs très clairement le problème que ces modes causent. Certains prépare des solutions de boycott, d'autres cherchent une solution alternative pour coller aux besoins de l'équipe IE tout en favorisant les standards. La solution de David Baron est ma préférée. Comme je le disais, la principale inquiétude de Microsoft tourne autour des Intranet. Laissons donc le reste du web bénéficier d'un vrai rendu standard. Les administrateurs des réseaux d'entreprises choisiraient quels sites doivent être vus avec un autre moteur que celui de base. Ce n'est pas aussi bien que des modes de rendus très proches qui évoluent ensemble mais on ne peut demander à Microsoft de recommencer le travail sur IE8 depuis le début.

Je suis d'ailleurs tombé sur le meilleur résumé possible de toutes ces discussions.

Depuis 3 semaines, le site de la communauté française Django tourne sur Webfaction. Comme je me suis occupé de la migration, David ayant une todo-list longue comme le bras, je vous propose un petit howto d'une migration Django, SVN et Trac.