Mot-clé - safari

Fil des billets

mardi 3 juin 2008

Nouveautés Safari 3.1 : Selectors API

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.

Notes

[1] Oui, cette librairie est tellement bien qu'il n'y a pas besoin d'apprendre autre chose que les standards

lundi 7 avril 2008

Mon premier bug chez Webkit

Depuis un petit moment, je suis de plus en plus près le projet Webkit, le moteur derrière Safari.

Ayant remarqué un bug dans la gestion des évènements sur une interface que j'utilise quasi-quotidiennement, je me suis décidé hier à en faire un joli rapport de bug. J'ai aussi pu traîner un peu sur le salon IRC #webkit et l'accueil était plutôt agréable. J'ai pu poser quelques questions et apprendre qu'un nouveau moteur Javascript est en cours d'écriture, que le WebInspector était en cours de refonte.

En écrivant le test minimal pour le bug, j'ai aussi remarqué que la taille minimum d'un élément <select> sur plusieurs lignes est de 4 lignes. Au premier abord, on peut se dire que ce n'est pas normal par rapport à la spécification. Mais c'est un bon point ergonomique puisqu'il est plus facile d'avoir du contexte sur 4 lignes et qu'il est impossible de présenter une barre de défilement sur 2 petites lignes. Un comportement à retenir si l'on souhaite utiliser de petites listes de sélection.