lundi 2 mars 2009
Par Anthony Ricaud le lundi 2 mars 2009, 01:07 - Informatique
Ci-dessous, une traduction du billet de Timothy Hatcher du blog Surfin' Safari. Quelques fautes et imperfections de traductions doivent s'être glissées, n'hésitez pas à me les signaler. Le billet original date du 30 septembre 2008 et ne parle pas encore de la beta de Safari 4.
mercredi 27 août 2008
Par Anthony Ricaud le mercredi 27 août 2008, 23:15 - Informatique
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.
$('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.
$('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.
É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é.
[1] parce qu'il faut bien un exemple à la con
dimanche 3 août 2008
Par Anthony Ricaud le dimanche 3 août 2008, 23:06 - WebKit
I've been following the WebKit project for 4 months now and I thought it would be interesting to extract cool news of the week here. This is the first post in this series and I hope it will be interesting and live long.
I'm French so my tailor is rich but my English is poor. Please correct me if you find mistakes.
Everything mentioned below should work with the latest nightly available at the moment (35531).
It's always good to improve standards compliance. The menu:
The CSS WG is working (among other stuff) on CSS variables. To support this effort and try to find the best syntax, there are some tries in WebKit.
So this week, we have support for CSS variable declaration blocks. See the example in a test to see how it works.
Of course, these are experiments and do not represent the final syntax. There are other experimentations going on, like the use of the var keyword.
Let's start by saying the Web Inspector (WebKit's equivalent to Firebug basically) is being refreshed. It has almost nothing to do with the one in Safari 3.1. Try it!
One of the novelty is to support the same Console API as Firebug to help web developers work.
This week, WebKit now supports console.group and console.groupEnd. I must point out this work was done by Keishi Hattori, one of the students participating in the Webkit GSoC .
Again, a work in progress specification and a testing implementation. The implementation has even more details than the latest spec I could find.
The idea ? Add events to allow better knowledge about the status of the XHR request. This could allow upload forms with progress bars.
The example shows the new available events and properties.
Also in the refresh project of the inspector. A useful functionality to analyse a web page design, try new things, etc.
Ariya Hidayat had some fun adding a live tab previews in Arora (a browser based on QtWebKit).
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.
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.
Tout ce qui est mentionné ci-dessous doit normalement fonctionner dans la dernière nightly disponible (35531).
Toujours une bonne chose d'améliorer le respect des standards. Au menu :
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.
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.
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.
Encore la refonte/amélioration de l'inspecteur. Une fonctionnalité bien utile pour analyser le design de sa page, faire des expérimentations, etc.
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.