Anthony Ricaud

À propos Archives RSS

Mot-clé - webkit

Fil des billets

dimanche 3 août 2008

La semaine de WebKit - #1

Par Anthony Ricaud le dimanche 3 août 2008, 17:28 - Semaine Webkit

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.

mardi 3 juin 2008

Nouveautés Safari 3.1 : Selectors API

Par Anthony Ricaud le mardi 3 juin 2008, 02:14 - Informatique

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

jeudi 10 avril 2008

Nouveautés Safari 3.1 : getElementsByClassName

Par Anthony Ricaud le jeudi 10 avril 2008, 20:39 - Informatique

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

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.

3 commentaires

lundi 7 avril 2008

Mon premier bug chez Webkit

Par Anthony Ricaud le lundi 7 avril 2008, 09:40 - Informatique

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.

page 2 de 2 -