jy[B]log

Allez ! Hop Hop Hop ! Testeurs de tout poils, courrez télécharger Firefox 3.0RC1 ! Dernière ligne droite pour cette version dont le développement dure depuis plus de deux ans. Pleins de nouveautés, tant pour les utilisateurs, que pour les développeurs.

Si vos extensions favorites ne sont pas à jour, harcelez leurs auteurs !

Firefox 3.0 est une belle avancée. Avec quelques bémols :

• gecko 1.9 ne passe pas le test acid3 (mais l'utilisateur "normal" s'en fout comme de sa première chaussette)
• il y a un bug super génant (au moins sous linux) : le scroll de certains sites est affreusement lent, et il semble que ce soit du à certaines utilisations des bordures en CSS (je n'ai plus le numéro du bug en tête, surtout qu'en fait il y en a plusieurs). Et ce bug m'embête profondement, puisqu'il apparait en particulier quand je vais sur linuxfr.org. Je sens que les trolleurs vont s'en donner à coeur joie sur ce site...

Bon mais cela reste une très très bonne version.

Et ce n'est pas tout : Firefox 3.1 est prévu pour la fin de l'année (oui, si vite), avec, si tout va bien plein de petits trucs sympas (mais à prendre avec des pincettes, rien n'est figé) :

• XmlHttpRequest cross site
• binding JSON-DOM
• encore des améliorations sur les performances
• encore des améliorations sur la barre url
• la balise <video>
• et des améliorations spécifiques pour la version mobile de Firefox !

Et mon petit doigt me dit qu'il y aurait aussi des améliorations dans CSS. Par contre on ne sait pas encore lesquelles seront incluses dans Firefox 3.1. Ce qui est sûr, c'est qu'ils y travaillent en ce moment et il y a des patchs en cours de réalisation, voir presque prêt, dont par exemple :
** les bordures en images
** le text-shadow
** les pseudo-classes :nth-*(), :first-of-type, :only-of-type, :last-of-type...
** @font-face
** media queries CSS3
** ...

Que du bon !

La documentation sur un outil de développement comme un framework est souvent un problème. D'une part parce que, bien souvent, le développeur n'aime pas écrire de la doc, mais aussi parce que soit la rédaction de la documentation n'est pas aisée, soit elle n'est pas disponible dans un format autonome et imprimable.

Lire la suite

Ça fait plusieurs semaines que mes confs sont inscrites au tableau, mais il n'est jamais trop tard pour vous le dire, surtout que je viens de voir que la concurrence sera là aussi^[1]. Les visiteurs pourront donc assister à une conf sur Copix, et à une conf sur Jelix (en plus d'un atelier sur Jelix). Ils pourront donc comparer les deux frameworks PHP dans leurs dernières moutures.

C'est quand même drôle d'avoir ces deux confs, quand on connait les liens qu'il y a entre les deux projets :-). Pour rappel, j'étais l'un des deux core-developer de Copix 2, et Jelix est un fork de Copix, bien que dés le début du projet, le noyau de Jelix n'avait déjà presque plus rien en commun avec celui de Copix. Et puis dans les versions actuelles, il n'y a seulement quelques lignes de codes dans Jelix qui proviennent encore de Copix 2.

Cependant, il n'est pas certain que je puisse mettre le bazar^[2] assister à la conf Copix, je serais probablement encore dans le train qui m'emmène à Mont de Marsan.

Bon sinon, je présenterai aussi Etna, l'éditeur XML wysiwyg que je développe chez Disruptive Innovations, avec une beta de la version 0.4, qui aura donc un nouveau validateur RelaxNG tout beau tout neuf et surtout moins buggé, et un joli noyau Gecko 1.9, entre autre.

Le reste du temps, on me trouvera au stand Mozilla bien sûr

Ce matin, le facteur m'apporte un colis. Éxpéditeur: spreadshirt. Bizarre, je n'ai jamais rien commandé chez eux.

J'ouvre, et j'éclate de rire. Il y a une carte de félicitation, et ça :

Une grenouillère pour Maxime, de la part de bast, BaGron, bballizlife, brunto, gunt et Torgan, qui sont tous contributeurs sur Jelix.

Ma femme et moi, on vous dit un grand merci les gars, c'est super sympathique de votre part !

Ce qu'il y a bien dans Mysql 5, c'est qu'on peut enfin commencer à utiliser triggers, procédures stockées et vues. Ça permet d'alléger le code PHP des applis web, et de garder une meilleure cohérence dans les données (et de meilleurs perfs dans le traitement des données je pense).

Bref, j'aimerai bien commencer à pouvoir faire des vrais schemas de bases de données dans les applis web (et dans certaines briques de jelix), quand je n'ai que mysql sous la main.

Seulement voilà, je ne suis pas sûr que Mysql 5 soit dispo chez tout les hébergeurs. Aussi, si vous pouviez me dire les versions de mysql, php, et posgresql que propose votre hébergeur (en donnant son nom), ce serait sympa

Attention, n'allait pas seulement voir dans le phpmyadmin de votre hébergement. En effet, par exemple, je sais qu'OVH propose depuis peu du mysql 5, mais seulement pour les nouveaux inscrits, les bases sur mysql 4 des "anciens" n'étant pas migrées automatiquement.

PS: si vous avez votre propre serveur dédié, ça m'interresse aussi, indiquez alors "hébergement perso" comme nom d'hebergeur

J'adore Linux, mais je trouve que les distribs imposent parfois des trucs qui m'embètent à un point inimaginable (je reste poli). Trois exemples :

• updatedb : ce processus est lancé à chaque fois que j'ouvre une session (tout les jours quoi). Et vas-y que ça monopolise les accés disques, et vas-y que ça me fait freezer toutes les applis qui veulent accéder au disque. C'est probablement le truc qui m'irrite le plus. Impossible d'utiliser la machine correctement pendant que ce truc fonctionne. Et le comble, c'est qu'il est censé permettre des recherches plus rapide dans les fichiers puisqu'il les indexe justement. Au boulot, sur ma bécane super top moderne, ça va encore, mais sur mes bécanes à la maison, plus vieilles, c'est l'horreur.
• le support corrects des portables : j'ai toujours eu des ennuis avec linux sur les portables, et ça ne s'améliore vraiment que lentement. Je ne comprend pas pourquoi, alors que l'informatique nomade est quand même en plein boom. Y a toujours des trucs qui bugs dans tout les sens, en particulier en ce qui me concerne la mise en veille. Malheur à moi si je rabat l'écran sans éteindre d'abord la machine : ça plante méchament, la dalle de l'écran passe par des couleurs toutes bizarres, et galère pour rebooter. Et c'est pas la seule machine sur laquelle ça délire à ce point là.
• autre débilité : le check des disques au démarrage (fsck). Je ne sais pas qui a eu l'idée d'une fréquence de check des disques tout les 32 redémarrages chez Debian et Ubuntu, mais ce type ne doit pas vraiment utiliser de machine "normalement". Ce nombre est ridicule, d'une part parce que les disques sont tout de même relativement fiables de nos jours, et d'autre part ces checks prennent un temps absolument faramineux à cause du volume toujours croissant des disques. Et donc régulièrement il faut attendre 5 à 10 min que la machine démarre. C'est d'autant plus ridicule sur les portables quand ils ne sont pas branchés sur le secteur : ça pompe une energie folle. Vous n'avez pas intérêt à ce que ça arrive alors que vous n'avez plus beaucoup de batteries et un truc urgent à faire (mais malheureusement, de par la loi de Murphy...)
• Et je ne parle pas non plus des durées des batteries sous linux, alors que sous windows, j'ai bien à l'aise 1.5 à 2 fois plus de temps sur mon portable actuel.

Alors je sais que tout ça peut se paramètrer, mais faut avoir fait lu 50 howto pour comprendre comment. C'est insupportable. Et je n'aime vraiment pas passer mon temps à ces conneries là.

Mise à jour 20/04 21h06. Je dément cette information ! Je n'ai plus Windows installé sur mon portable depuis des lustres Mais à l'époque où j'ai acquis la machine (d'occasion, il y a deux ans, avec Windows installé), j'ai pu constaté ces différences de durées de batteries entre Windows et Linux. Bon, mais c'est vrai que j'ai un windows 2000 en double boot sur mon desktop, pour certains tests

En fait, je m'en fous, mon fils fera ce qu'il veut de sa vie. Vie qui vient tout juste de commencer ce matin à 10h00 après que nous ayons passé une nuit blanche ma femme et moi Je suis donc papa pour la seconde fois, même si cette fois-ci, ce n'était pas la pleine lune. Le petit se porte bien, ainsi que sa maman. Sa grande soeur de 2 ans et demi est ravie. Que demander de mieux ?

Ah si, éspérer qu'il fasse ses nuits le plus rapidement possible

Mise à jour 17/04 14h15 : Trop fort, y a le wifi à la clinique ! (oui je suis indécrotable...) Enfin bref, ça me permet de lire vos commentaires et de mettre à jour ce billet : le prénom du petit est Maxime, et sa soeur s'appelle Chloe

Vous en avez rêvé ? Daniel et David vont l'ont fait : Les variables CSS. Pour l'instant, ce n'est que le brouillon d'un brouillon d'une future recommandation, mais les commentaires sont les bienvenu. Vous pouvez les faire sur le blog de Daniel ou ici, je transmettrai ;-).

En gros, comment ça fonctionnera (en faisant l'hypothèse que la spec ne changera pas trop ) :

@variables {
 CorporateLogoBGColor: #fe8d12;
}

div.logoContainer {
 background-color: var(CorporateLogoBGColor);
}

Les variables sont définies dans un bloc d'une règle @variables. Ici la variable CorporateLogoBGColor est déclarée avec la valeur #fe8d12. Ensuite, pour l'utiliser dans les propriétés de style, on utilise l'instruction var() avec le nom de cette variable.

Alors attention, il s'agit bien d'une variable, et non pas d'une constante, puisque, cerise sur le gâteau, on peut modifier sa valeur via le DOM style. Vouloir modifier la variable CorporateLogoBGColor reviendra à faire ça :

 document.styleSheets[0].cssRules[0].variables.setVariable('CorporateLogoBGColor', '#000');

PS: je vais proposer à Daniel une manière plus simple de modifier une variable, par exemple :

 document.styleSheets[0].setVariable('CorporateLogoBGColor', '#000');

C'est toujours sympa de demander aux lecteurs ce qu'ils utilisent comme logiciels pour faire çi, ou pour faire ça, car ils vous font découvrir parfois des outils complètement inconnu. Après les bug trackers, je réitère donc l'expérience.

L'extension Sage pour Firefox est l'agrégateur que j'utilise pour me tenir au courant des nouveaux billets sur mes blogs préférés. Je la trouve très simple, très bien intégrée dans Firefox. Malheureusement, elle ne semble plus maintenu (depuis 14 mois), et il n'y aura donc apparement pas de version pour Firefox 3.0. Et j'ai fortement envie de passer à Firefox 3. Donc pour remplacer Sage, je cherche un autre agregateur.

Lequel me conseillez-vous ? Sachant que j'aimerais que celui-ci m'affiche le vrai billet (la page du site web) et non le texte contenu dans le fils RSS/ATOM (c'est toujours plus sympa de lire sur le site original). Je suis sous KDE, j'ai regardé akregator, mais ce n'est pas tout à fait ce que je cherche. En attendant, je vais un peu expérimenter l'agrégation dans Thunderbird.

Bon l'idéal, ce serait qu'un volontaire mette à jour Sage

Deuxième chose, je cherche un gestionnaire de photos, avec des fonctionnalités à peu prés identiques à Flickr, mais que je puisse installer sur mon site web (je ne préfère pas confier toutes mes photos à flickr). Que me recommandez-vous ? L'idéal serait qu'il soit accompagné d'une appli desktop ou d'une extension pour Firefox, facilitant l'upload des photos. Il faut aussi qu'il ait un design vraiment sympa et dépouillé, une gestion des droits, et qu'il soit le plus simple possible à utiliser.

Via John Resig, (Monsieur "jQuery"), j'ai découvert HotRuby qui est un projet permettant d'exécuter du ruby dans une page web.

Voici comment ça fonctionne

• inclure les fichiers js de hotruby
• mettre son code ruby dans une balise <script type="text/ruby"></script>
• Ce code est envoyé sur un serveur via xmlHttpRequest, et en réponse, le serveur renvoi une structure en javascript qui correspond à du bytecode Ruby
• Ce bytecode est alors executé par une VM programmée en javascript (la VM de HotRuby donc)
• Pour les détails, voir le billet de John

Et voila Astucieux non ?

Alors pour l'anecdote, il faut savoir que cette VM en javascript exécute le bytecode de Ruby 5 fois plus vite dans Firefox 3.0 que la VM native de Ruby ! Une VM en javascript qui exécute plus vite qu'une VM codée en C, c'est impressionnant !

Mozilla 2 (Firefox 4), comportera une machine virtuelle pour Javascript 2 (projet Tamarin, à partir de la VM libérée par Adobe). Ainsi, le javascript des pages web sera converti en bytecode pour Tamarin, avant d'être exécute par Tamarin. Supposons maintenant que par l'intermédiaire d'une extension, on puisse installer un compilateur d'un langage X qui génère du bytecode pour Tamarin, et donc qu'on puisse ensuite faire <script type="text/ruby"></script> ou <script type="text/python"></script>. On n'aurait plus besoin de passer par cette étape de xmlHttpRequest, donc par un compilateur exterieur

Bon, je rêve, pas dis que ce sera faisable dans Firefox 4, mais à mon avis, il manquera peu pour que ça puisse exister Quoique, c'est peut-être le but de IronMonkey... Je n'ai pas vraiment compris l'objectif de IronMonkey mais je crois qu'il s'agit de porter IronRuby et IronPython pour qu'ils génèrent du bytecode pour tamarin...

Hier j'ai sorti la version 1.0.3 de Jelix, avec son lot de petits bugs corrigés, mais aussi quelques améliorations, dont l'apparition d'une page de démarrage lorsque l'on crée une application (voir le mini tutoriel mis à jour pour l'occasion). Cette page n'affiche pas qu'un message de bienvenu, mais fait aussi un diagnostic de la configuration et de l'installation (comme la configuration de PHP), et préviens donc si il y a des choses qui risquent de gêner le bon fonctionnement de Jelix.

À part ça, ça avance un peu dans la future version 1.1. Les principales nouveautés que j'ai ajouté dernièrement, ce sont :

• les évolutions dans jForms, qui permettent je pense de commencer à montrer le potentiel de ce système de formulaire, dont :
  • le support de la balise <htmleditor>. Une simple balise, et vous avez un éditeur HTML wysiwyg dans votre formulaire. Actuellement, j'ai fait le choix que ce soit Wymeditor le moteur de cet éditeur, mais si vous en voulez un autre, il n'y a pas de souci. Quelques lignes dans le fichier de configuration de jelix et tout votre site utilise fckeditor ou tinymce ou ce que vous voulez. Voir la documentation sur la balise htmleditor. Bien sûr, coté serveur, jForms nettoie le HTML de manière à éviter les problèmes de sécurité comme XSS et cie.
  • le support de la balise <captcha>. Là encore, pour avoir un captcha de type "test de turing" (les captchas de type image viendront plus tard), il suffit juste d'ajouter cette balise et jForms s'occupe du reste (choix de la question, génération du champs de saisie, vérification coté serveur de la réponse etc).
• jAcl2, un nouveau système de gestion de droits, qui s'inspire de jAcl, mais en plus simple.

Le développement de Jelix 1.1 ne va pas aussi vite que je le voudrais (en tout cas, en ce qui me concerne, car il y a pleins de nouveautés qui vont débarquer grâce aux contributeurs ). En effet, je bosse aussi sur des petits projets annexes comme le module jcommunity qui apporte tout ce qu'il faut sur un site pour que les gens puissent s'inscrire, s'identifier, avec gestion des mots de passe perdu, gestion de leur profils etc. Et puis je travaille aussi sur un autre projet perso (basé sur jelix bien sûr) mais je vous en dirais plus plus tard ;-).

Ça fait longtemps que je n'ai pas parlé des avancées sur Etna. Donc voici quelques nouvelles.

Le nouveau validateur RelaxNG en C++ est presque terminé. Je suis en train d'implémenter nos extensions relaxng, mais d'une manière qui va être plutôt sympa : sous forme de "plugin" pour le validateur. En effet, je suis en train de rendre le validateur extensible. Ainsi un développeur pourra apporter le support de ses propres extensions RelaxNG, via un simple composant XPCOM.

Bon par contre, entre temps, une envie m'a pris de modifier l'encodeur^[1] XHTML/XML de Gecko. En effet, celui-ci ne permet pas le "pretty printing", comprendre, il ne permet pas de générer le XML de manière lisible, comme le fait l'encodeur HTML. Et c'est bien sûr une chose dont j'ai besoin dans Etna.

Bon, ça ne semble pas si intéressant que ça me direz-vous. Mais en fait si. Car cette modification va avoir quelques répercussions...

Il faut savoir que l'encodeur XML est aussi utilisé pour encoder les documents XHTML qui sont servis avec le type mime application/xml+xhtml. Par contre, pour les documents XHTML servi en text/html, c'est l'encodeur HTML qui est utilisé. En sachant ça, vous comprenez qu'en ce moment, dans Gecko, l'éditeur HTML a un support plutôt bancale de XHTML. En sortie, soit on a du HTML bien présenté, mais forcément, ce n'est plus du XHTML (voir du XHTML invalide), soit on a droit à du XHTML mais présenté brut de fonderie donc on peut avoir des lignes de textes qui font des centaines de caractères si il n'y a pas de saut de ligne dans les noeuds textes. Dans NVu, Daniel avait patché l'encodeur HTML pour que la sortie XHTML soit un minimum potable (patch non porté dans le gecko officiel), mais il était insuffisant (faute de temps) : aucun support des namespaces.

En clair, avec les modifications que je vais faire dans les encodeurs XML et HTML, je vais à la fois permettre d'avoir du pretty printing sur les fichiers XML en général, mais aussi corriger les problèmes de "sérialisation" des documents XHTML. Cela va avoir donc pour effet d'améliorer le support XHTML dans l'éditeur de Gecko.

Qui va en bénéficier me direz vous ? Tout ces petits programmes comme wymeditor, tinyMCE et consorts, qui permettent l'édition WYSIWYG du HTML dans les formulaires, et qui sont actuellement obligés de faire des hacks pourris mais hélas nécessaires quand ils veulent du XHTML, pour transformer les chaînes HTML que leur donne Gecko en XHTML valide.

Bon par contre, je n'ai pas encore terminé, et il ne faut pas s'attendre à ce que ce soit dans Firefox 3 (trop tard). Le ticket correspondant dans bugzilla : 422403.

Franchement, le site www.voyages-sncf.com est une m**** sans nom. Je suis furieux. J'essaie depuis 10 minutes de réserver un billet, sans succès. Ça affiche n'importe quoi. Quand on utilise les boutons back du navigateur (parce que bien sûr, ils fournissent un lien "suivant", mais pas de lien "précédent" pour une longue liste d'horaire), ça déconne à plein tube, genre ça ré-affiche la page sur laquelle on était (alors qu'on veut retourner à la précédente !), ou alors ça affiche une page sur laquelle on est jamais allé. Et quand on a le malheur de faire un forward, je n'en parle pas. C'est le délire complet.

Et le pire, ça fait des années que ce site est pourri, malgré les versions successives.

Et je ne parle pas du nouveau sncf.com, tout en flash dans tout les sens. Imbitique.

PS: exemples

• je viens par exemple de tenter de choisir un "aller". Je clique sur le bouton "choisir cet aller", et il me renvoi sur la page d'accueil !
• je retente. Obligé de resaisir les données bien sûr. Je clique à nouveau sur le bouton "choisir cet aller". Et là il me dit que "Aucun train ne correspond à vos souhaits de voyage. Merci de les modifier à l'aide du moteur de recherche". Pourquoi ils m'ont proposé cet aller si il n'est pas disponible ??

PS2: je viens de découvrir que les défauts sont même signalés sur wikipédia. Je suis rassuré, je ne suis vraiment pas le seul à le penser.

Pour le projet Jelix, j'utilise Trac pour le suivi et la gestion des bugs (il est hebergé sur http://developer.jelix.org/). Au départ, je l'avais trouvé sympa : simple à utiliser, avec des rubriques utiles comme la gestion et la visualisation des roadmap, la timeline pour être au courant de toutes les dernières modifications, le wiki intégré, la navigation dans les sources plus "sexy" que websvn.

Par contre à l'usage, Trac commence sérieusement à me gonfler :

• Contenu des tickets vraiment minimal. Certes on peut ajouter des champs via le trac.ini (très facile), mais on ne peut définir aucune règle de gestion, sauf à développer un plugin (et le python n'est pas encore ma tasse de thé), ou alors à faire du javascript dans tout les sens pour cacher la misère (le plugin des dépendances de tickets est un bel exemple en la matière).
• Les plugins parlons-en : du fait du minimalisme dans les tickets, on est obligé d'en installer un minimum afin d'avoir un truc décent. Par exemple, pour pouvoir créer des dépendances entre tickets (tel ticket bloque tel autre ticket), pouvoir gérer certaines choses "basiques" (liste des composants des versions etc), Ou encore avoir une authentification un peu mieux foutu. Cependant, le problème avec les plugins, c'est que la plupart sont soit incomplets, soit buggés, soit obsolètes ou utilisables seulement pour une version supérieure (et instable) de trac.
• Il en découle un autre problème : la complexité de mettre à jour trac ou d'installer les plugins. Faut avoir les droits d'admin pour installer trac, modifier la conf apache et cie. Il y a des dépendances de partout. Il faut taper des lignes de commandes dans tout les sens, dont on ne se rappelle jamais la syntaxe. Bref, par rapport à une appli PHP traditionnelle, c'est l'horreur.
• Impossible de rajouter des informations sur les pièces jointes. La gestion des pièces jointes est finalement trop pauvre pour mes besoins.
• L'affichage des pièces jointes : buggé tout simplement. Quand on attache un patch par exemple. Pour certains, on peut les visualiser directement dans trac (avec coloration syntaxique et tout), pour d'autre, obligation de les télécharger pour les voir. Je soupçonne un problème de reconnaissance du mime type du fichier lors de l'upload, ou un truc dans le genre. Toujours est-il que c'est très énervant.
• Bon et puis c'est pas super réactif, dû peut-être au fait que c'est en Python (pas taper ), mais aussi certainement dû à la base de donnée : les concepteurs de trac sont vraiment des newbies en modélisation de base de données. Le schéma fait vraiment peur à voir. Un exemple : ils ne connaissent pas varchar, et vas-y que je te met tout les champs textuel en type "TEXT", des champs contenant uniquement des valeurs numériques en type "TEXT" également... Bien sûr, j'ai tenté d'améliorer tout ça, en changeant certains types, en ajoutant des indexes (primaire ou pas) là où il devait y en avoir etc.. Mais ça n'a que vaguement améliorer les choses.
• Je ne parle pas des templates super lourdingues à modifier. J'en ai passé des heures à intégrer le design "jelix.org"...

J'utilise une version 0.10, je sais que la 0.11 est en préparation et corrige certains points (le langage des templates, l'admin par ex). Mais j'envisage sérieusement de changer de gestionnaire de projet. J'en ai déjà regardé quelques-uns : Bugzilla, Mantis, Redmine. Cependant, ils ne me conviennent pas forcément.

• La gestion des tickets dans bugzilla est tout à fait ce qu'il faut. Mais l'interface est austère, et il n'y a pas de rubriques annexes comme la vue des roadmaps, de la timeline, la navigation dans les sources, ni de wiki intégré.
• Redmine : ça a l'air sympa, mais un peu simpliste quand même. Et j'ai eu des retours comme quoi c'était plutôt lent, même sur une machine dédiée (rails oblige ?)
• Mantis : l'interface est tout simplement une horreur. Pas seulement le design, mais aussi la façon dont elle est organisée. Et c'est lent.

Je suis en train de regarder une autre solution, mais je vous en dirais plus un autre jour.

Mise à jour : autres produits vus

• phpBugTracker : trop simpliste, moche
• Jira : ça a l'air complet et semble y avoir tout ce qu'il faut. Mais faut installer un serveur java, et puis c'est pas libre, bien que la licence soit gratuite pour les projets libres.

Mise à jour 15h12 : Arg, Ian indique qu'un bug a été découvert dans Acid3, et du coup Opera est redescendu à 99/100 La course continue !

Mise à jour 15h00 : Webkit a "un peu" triché au niveau de son score 100/100. L'une des étapes de Acid3 test les animations SVG. Or pour ce test, Webkit a juste implémenté une interface pour que le test passe. Et donc en fait, les animations dans SVG ne sont pas implémentées ! Plus d'explications sur ce blog, où son auteur a fait passé la suite de test SVG au moteur webkit... Avec peu de succés... En fait Webkit n'implémente pas beaucoup plus SVG que Firefox 3... Alors qu'Opera a une très bonne implémentation de SVG.

...Webkit ! Ou Opera ! Incroyable ! Le même jour ! Je ne pensais pas la course si serrée.--

Bon, mais, pas tout à fait en fait. Les bureaux d'Opera sont situés en Europe. Ceux de Apple/webkit, aux États Unis si je ne me trompe pas. Si on pose l'hypothèse que les heures de publications des billets correspondent aux fuseaux horaires de ces deux endroits, alors c'est Opéra qui a gagné !

Mais, mais... C'est Webkit qui fournit le premier une version dispo au grand public..

Bon, allez, pas de jaloux, ils sont tout les deux sur la première marche

Conçernant Firefox 3 : il ne passera jamais le test acid3. Le compteur restera bloqué aux alentours de 71/100. En effet, la sortie de la version stable de Firefox 3 approchant à grand pas, ce n'est plus le moment (depuis un bout de temps d'ailleurs), d'aller modifier en profondeur Gecko. Les développeurs se concentrent en ce moment sur la correction des bugs critiques. En effet, ce qu'il manque pour passer le test acid3 complet, ce sont des choses comme l'implémentation des animations SVG, l'implémentation des fontes téléchargeables etc. Et ce sont des gros morceaux à coder, pas le temps pour le moment donc. Il va donc falloir attendre au moins la version suivante de Firefox (3.5, ou 4, on ne sait pas encore).

Bon, heureusement pour Mozilla, il y a Internet Explorer qui occupe toujours la place du dernier

Félicitations aux développeurs de Webkit et Opera !