Hanblog

French version

One month without news is bad. So we resume with only two weeks.

Changes of the week

Everything mentioned below should work with the latest nightly available at the moment (37469).

Styling placeholder (37123, 37217)

WebKit supports a placeholder attribute on input elements. This attribute allows you to display a tooltip in the field when the user hasn't enter any content. By default, this tooltip is printed in light gray. Now, we can play with his style using the -webkit-input-placeholder pseudo-element. See the example.

Debugging before onload fires (37313)

Before this fix, it was impossible to debug a part of code running before the resource finished its loading. It wasn't really handy for a tool like the Web Inspector. Fixed !

Origin header for POST requests (37317)

Beginning of implementation for the Access Control for Cross-Site Requests specification. An Origin header, which only contains the domain of the originating page, is added. This allows application to check if the request comes from an authorized domain. Unlike the Referer header, this one doesn't reveal the complete path of the originating page.

Exact line search (37389)

Like Firebug, it's now possible to search for a particular line in the Resources panel. We can use two syntaxes : #123 or line:123. We can add a keyword to only match lines with this keyword.

Fixing SunSpider (37389)

As David Mandelin mentioned on his blog, the regexp-dna test on SunSpider was incorrect. An option only supported in Gecko was in the test and so, this engine was disadvantaged. Eveyrthing is fine now, all the engines do the same test.

News of the week

While I wasn't giving news, three new posts were added to the Surfin' Safari blog:

• Introducing Squirrelfish Extreme, the latest evolution of the JavaScript engine.
• Full pass of Acid3, the last condition (smooth animation) is now ok.
• Web Inspector redesign, a summary of all the evolutions for the last nine months.

This is everything for this week. Of course, this is just a selection I've made. If you've noticed any other interesting changes, please let me know. Same thing if I got something wrong.

French version

After a few weeks off, let's get back with webkit news. By the way, the english versions are now aggregated on Planet Webkit.

Changes of the week

Everything mentioned below should work with the latest nightly available at the moment (36135).

DOM properties and local variables editing (35835)

Double clicking a property in the sidabar of Elements or Scripts panels now allows you to change the value of this property. You can even enter JavaScript as shown in this screenshot.

console.count support (35842)

Still a Firebug compatibilty stuff. This method allows you to count how many times a specific code has been called.

Editable Metrics tab (35876)

Like Firebug, it is now possible to edit dimensions, padding, borders, margins and position of a box.

Canvas Text support (36060)

Canvas, the element allowing you to draw in 2D now has an API to draw text. You can use the two tests to learn it.

Chrome consequences

Obviously, you haven't missed Google's announcement this week. A new browser using WebKit. And the two projects are working together as you can see with the following commits.

• 36074 New constants for Skia, V8 and Chromium.
• 36095 V8 benchmarks are integrated into WebKit.
• 36097 Little anecdote, some Google developers gave patches under fake names to stay under the radar before the announcement.

This is everything for this week. Of course, this is just a selection I've made. If you've noticed any other interesting changes, please let me know. Same thing if I got something wrong.

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.

Changements de la semaine

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

Implémentation des CSS Animations (35545, 35568, 35580, 35646)

CSS Animation est une spécification en cours d'écriture par Apple. Comme sa copine, CSS Transition, elle permet d'obtenir des effets animés en CSS. Là où les transitions ne sont que des effets à chaque changement d'une propriété, les animations sont appelées explicitement pour provoquer un changement de valeur. Il y a un système de keyframe pour contrôler précisément le déroulement de l'animation. Voyez les quelques exemples pour plus de détails.

Édition rapide de valeurs numériques (35561)

Pour les propriétés CSS acceptant des valeurs numériques, il est désormais possible d'augmenter ou de diminuer cette valeur avec le clavier. À noter, les raccourcis claviers pratiques modifiant la valeur : avec Alt, on saute de 0.1, avec Shift ou Page Up de 10, avec Shift et Page Up de 100.

Heavy view du profiler (35625)

Ok, ce n'est pas une nouveauté révolutionnaire, mais ça me permet de parler du nouveau profiler. Celui-ci permet de récupérer des informations détaillées sur le temps d'exécution du JavaScript dans votre page. Par rapport à celui de Firebug, il affiche les résultats sous forme d'arbre, permettant de regarder plus en détail. Deux types de vues sont disponibles Tree ou Heavy chacune ayant son intérêt. Il est aussi possible de réduire le bruit pour se concentrer sur une partie du code. Il réagit aux commandes console.profile et console.profileEnd, tout comme Firebug.

Améliorations du moteur Squirrelfish (35593, 35639)

Ce moteur a été annoncé il y a deux mois et depuis, il est en constante amélioration. Je ne pourrais pas du tout expliquer ce qu'ils font mais les chiffres parlent d'eux-mêmes : 2.6% et 2.5% d'améliorations pour le test SunSpider

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 ?