Hanblog

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.

On reprend le rythme doucement, après quelques semaines sans nouvelles. Au passage, les billets en anglais sont désormais recensés sur le Planet Webkit.

Changements de la semaine

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

Édition des propriétés DOM et des variables locales (35835)

En double cliquant sur une des propriétés dans la barre latérale dans le panneau Elements ou Scripts, vous pouvez changer la valeur de la propriété associée. Vous pouvez entrer du javascript comme le montre la capture suivante

Support de console.count (35842)

Toujours pour la compatibilité avec Firebug, une nouvelle méthode s'ajoute à la liste. Elle permet de compter le nombre de fois qu'une ligne a été appelée.

Onglet Metrics éditable (35876)

Tout comme Firebug, il est maintenant possible d'éditer les dimensions, padding, bordures, marges et position d'une boîte.

Support de Canvas Text (36060)

Canvas, l'élément qui permet de faire du dessin en 2D s'est vu ajouté une API pour dessiner directement du texte. Deux tests peuvent vous servir d'exemples.

Conséquences de Chrome

Évidemment, vous n'avez pas manqué l'annonce de Google cette semaine. Un nouveau navigateur utilisant WebKit. Et les deux projets s'entendent, j'en veux pour preuve ces quelques commits.

• 36074 Nouvelles constantes pour Skia, V8 et Chromium.
• 36095 Les benchmaks de V8 sont intégrés à WebKit.
• 36097 Petite anecdote, certains développeurs de Google fournissaient des patchs sous des pseudonymes pour ne pas éveiller l'attention avant l'annonce.

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.

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.

Depuis le temps que je suis le projet WebKit, je me suis dit que ce serait intéressant d'en faire un résumé, à la manière de Laurent Jouanneau pour Mozilla. C'est donc le premier billet de la série que j'espère longue et intéressante.

Changements de la semaine

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

Amélioration du parser CSS (35403)

Toujours une bonne chose d'améliorer le respect des standards. Au menu :

• Si la dernière accolade d'un fichier est oubliée, la règle sera tout de même considérée comme bonne;
• Une règle finissant par "!important fail" ne sera plus considérée comme juste;
• Si une règle @import n'est précédée que de règles @ invalides, elle sera valide;
• Un bloc @media ne sera pas entièrement rejeté s'il y a une erreur avant l'accolade de fermeture;
• D'autres améliorations mineures.

Support des blocs pour les variables (35414)

Le CSS WG travaille (entre autre) sur des variables en CSS. Pour supporter cet effort et permettre de choisir la meilleure syntaxe, des tentatives sont faites dans WebKit.

Cette semaine, ce sont donc le support de blocs en tant que variables. Voyez l'exemple fourni par un test pour mieux comprendre.

Ce sont bien évidemment des tests et ne représente en rien la syntaxe finale. Il y a d'ailleurs d'autres expérimentations en cours, sur l'utilisation du mot-clef var.

Support de console.group (35421)

Commençons d'abord par expliquer que l'inspecteur web (l'équivalent de Firebug en gros) est en cours de refonte. Il n'a quasiment rien à voir avec celui de Safari 3.1. Essayez-le, vous verrez.

L'un des chantiers est de supporter la même Console API que Firebug pour simplifier la vie des développeurs.

Cette semaine, la nouveauté est donc le support de console.group et console.groupEnd. Il est à noter que ce travail a été réalisé par Keishi Hattori, l'un des étudiants participant au GSoC de WebKit.

Support de XMLHttpRequestUpload (35435)

Encore une spécification en chantier et une implémentation de test. Visiblement l'implémentation a plus de détails que la dernière spécification que j'ai pu trouver.

L'idée ? Ajouter des événements permettant de mieux connaître l'état de la requête XHR. Cela permet par exemple de faire des formulaires d'upload avec une barre de progression.

L'exemple joint montre les nouveaux événements et propriétés disponibles.

Possibilité de désactiver des propriétés CSS (35514)

Encore la refonte/amélioration de l'inspecteur. Une fonctionnalité bien utile pour analyser le design de sa page, faire des expérimentations, etc.

Nouvelles de la semaine

Ariya Hidayat s'est amusé à rajouter un aperçu en direct du contenu des onglets dans Arora (un navigateur basé sur QtWebKit).

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.

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.

Hier soir, je tente de retrouver une artiste que j'avais revue peu de temps sur Taratata. Après avoir décrit la demoiselle comme brune avec une voix grave, un énergumène (chanceux) faisant partie de mes compagnons de discutaille électronique trouva Tanita TIKARAM et Twist In My Sobriety. Cette petite recherche m'a amené sur le site de Taratata et sa page artistes. Et là c'est une jolie découverte. J'ai l'impression qu'ils ont triés toutes les émissions depuis le début de l'emission pour en extraire tous les artistes. Je retombe par exemple sur les Faboulous Troubadors, dont le CD m'avait été offert par un cousin il y a une petite dizaine d'années.

Autre petit lien sympathique, trouvé sur le blog de Last.fm : Comment In Rainbows a détruit les classements. En gros, depuis sa sortie le 10 octobre, tous les pistes de l'album gardent les premières places à quelques exceptions près depuis peu. Ça prouve bien que c'est le meilleur groupe du monde.

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 ?

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.

Lundi soir, petit contretemps, le disque dur de mon Macbook affiche quelques erreurs qu'un fsck n'arrive pas à corriger. Pas envie de fouiller pendant des heures et en plus, ça devenait un peu le souk, donc on va repartir sur de bonnes bases. Réinstallation complète. L'occasion de mettre par écrit les quelques petits trucs que j'avais pu glaner au fur et à mesure de ma découverte du système. Ça pourra peut-être servir à d'autres même si c'est centré sur mon utilisation.