Anthony Ricaud

Certes je n'aime pas les librairies JavaScript en général. Beaucoup de code téléchargé, parsé, exécuté pour n'utiliser la plupart du temps qu'un ensemble très réduit de fonctionnalités. Mais bon, mettons ça de côté aujourd'hui car il faut l'admettre, elles rendent tout de même de bons services.

On va quand même garder un point qui m'embête : ces librairies cachent souvent la complexité du code qu'elles exécutent. Pour démontrer cela, mettons nous en situation ! L'exemple sur la page suivante contient 1729 paragraphes de deux mots. Pour une raison évidente^[1], nous voulons cacher le deuxième mot de chaque paragraphe. Pour cela, nous utilisons jQuery de deux manières différentes.

La méthode toggle

$('span').toggle();

Que fait réellement cette simple ligne ? Elle va récupérer tous les éléments <span> de la page puis leur appliquer la méthode toggle. Pour chaque élément trouvé (1729 je rappelle), elle va vérifier s'il est affiché ou non et lui appliqué un style en conséquence. C'est tellement long que votre navigateur risque de bloquer sur la page de test.

La méthode classe

$('div').eq(0).toggleClass('hidden');

Jeu de mot pas terrible mais qui résume bien la situation. Ce code récupère tous les éléments <div> de la page et ne travaille que sur le premier. Sur ce <div>, elle va regarder s'il a la classe hidden et en fonction, lui ajoutera ou enlèvera cette classe. Voilà, c'est tout ce qu'elle fait. Ensuite, c'est le navigateur qui travaille comme un grand grâce à la règle .hidden span {display:none;}. Évidemment, le moteur CSS de votre navigateur fera ça bien plus rapidement.

Conclusion

Évidemment, mon exemple avec autant d'éléments est grossier. Mais tout de même, la différence est fondamentale. Permettez-moi une analogie entre un accès DOM et un accès disque, c'est à dire les parties les plus lentes des deux algorithmes précédents. Dans le premier cas, un premier accès en lecture (récupérer tous les spans) puis 1729 accès en lecture (est-il affiché ?) et 1729 accès en écriture (réglons son affichage). Dans le deuxième cas, nous avons un premier accès en lecture (récupérons tous les divs) puis un accès en lecture (est-ce que la classe est présente ?) puis un accès en écriture (ajoutons ou enlevons la classe). Le calcul est vite fait...

De manière générale, rappelons qu'il faut le moins possible toucher au style d'un élément. Si vous devez accéder plus de deux fois à l'attribut style, il sera plus profitable de passer par une règle CSS. Le moteur CSS sera toujours plus rapide que vous. De plus, vous permettez aux intégrateurs de pouvoir styler votre page en ne changeant que quelques classes. Et votre code d'affichage reste cantonné aux fichiers CSS, merci la maintenabilité.

Changements de la semaine

Tout ce qui est mentionné ci-dessous doit normalement fonctionner dans la dernière nightly disponible (35806).

Implémentation des CSS Animations (35666)

J'avais annoncé un peu rapidement cette implémentation la semaine dernière. Par rapport aux deux spécifications, il manquait les événements associés.

Compatibilité avec l'API de Firebug (35676, 35786, 35787)

De nouvelles commandes sont disponibles dans la console. $, $$, $x, keys, values, profile/profileEnd, clear. Vous trouverez les descriptions de ces fonctions dans la documentation de Firebug. Sans oublier l'ajout de console.dir pour lister les propriétés d'un objet.

Tests SVG (35675, 35679, 35680, 35682, 35683, 35695, 35700)

Je ne suis pas familier avec SVG mais environ 80 tests ont été ajoutés pour s'assurer du bon comportement du moteur. En particulier, les éléments line, radialGradient, image, marker, mask, cursor, pattern et rect sont concernés. Quelques corrections ont eu lieu à cette occasion.

Inspecteur redimensionnable et fermable en mode "dock" (35719, 35720, 35722)

Lorsque l'inspecteur est intégré à la page, il est désormais possible de le redimensionner et de le fermer. J'attendais cela depuis longtemps. Il utilise d'ailleurs ce mode par défaut désormais. Et pour compléter cela, il se rappellera dans quel mode vous l'avez laissé.

Amélioration du chargement (35799, 35801)

Afin d'avoir toujours de meilleures performances, quelques ajustements ont été faits :

• Les feuilles de styles ont une priorité plus importante puisque le moteur ne fera pas de rendu tant qu'il n'a pas téléchargé toutes les feuilles.
• Pour chaque nouveau domaine, la connection est établie dès que possible, afin de réduire la latence due à l'établissement de cette connexion.
• Dès que le document et les feuilles de styles ont été parsées, plus la peine de maintenir de queue de téléchargements, on peut télécharger des documents de n'importe quelle priorité
• Pour ne pas retarder le rendu initial, les ressources dans <body> ne sont pas téléchargées tant que le rendu n'a pas commencé. Cela améliore de 25%, soit 5 secondes, le rendu initial de CNN avec une connection limitée à 300kb/s, intéressant pour les mobiles.

Voilà pour cette semaine. Évidemment, ce n'est qu'une sélection que j'ai faite. Si vous avez remarqué d'autres changements intéressants, n'hésitez pas à les mentionner. Idem si je me suis trompé dans une explication.