Le blog d'un internaute aimant l'informatique libre, la musique et la rétro-informatique !
Assez récemment, le bogue 10713 qui s’occupe d’insérer la propriété qui permet de créer des ombres en utilisant des CSS a été marqué comme corrigé.
En dehors d’une amélioration d’apparence du test Acid3, on peut voir ce que donne des textes utilisant des ombres avec les CSS, comme avec cette page :
http://www.designdetector.com/demos/text-shadow-test.html
78 / 100 pour Acid3.
On peut espérer un petit 80 voire 85 / 100 pour la sortie de Firefox 3.1 en décembre prochain ?
Par le terme librissime, je pense surtout au zèle excessif dont fait parfois preuve la Free Software Foundation.
Considérant Firefox pas assez libre, un projet nommé IceWeasel a vu le jour en août 2005, qui se résume à peu chose à : code source de firefox avec un nom différent et une série d’illustrations différente.
Bref, pas grand chose au final. Cependant, IceWeasel désigne maintenant la version debian de Firefox, et non plus la version de la FSF. Il faut parler d’IceCat !!!
Bref, IceCat est actuellement version 2.0.0.13, et n’existe en version binaire que pour les processeurs i386 et supérieur. Pas de version pour les processeurs Intel et AMD 64 bits, et encore moins pour le PowerPC.
Il faut donc aller sur le site d’IceCat pour récupérer le code source. La compilation est « classique », mais change assez du modèle proposé par la Fondation Mozilla. Outre un .mozconfig d’une longueur et d’une redondance inutile, il faut entrer le duo magique :
./configure ; make
pour lancer la compilation du chat de glace. Au résultat ? Une version aussi utilisable qu’un firefox classique, mais plus correct aux yeux de la Free Software Foundation… Beaucoup de bruit pour pas grand chose au final 😉
Mais si cela peut faire plaisir, un peu de masturbation intellectuelle de ce style, hein…
M’étant abonné au bug qui permet de suivre l’évolution du support de la nouvelle masturbation intellectuelle des navigateurs web, j’ai nommé le test Acid3, j’ai pu constater ses dernières heures qu’au moins 3 bogues concernant le dit test avait été marqué comme « FIXED ».
Il s’agit des bogues 421765, 412567 et le 128585.
Ce qui donne maintenant un résultat de 76 / 100 pour la pré-alpha1 de Firefox 3.1, soit 5 tests de mieux que le futur Firefox 3.0 qui doit être publié dans le courant du mois. Toujours bon sur le plan du support des normes du W3C au final 🙂
Mettons à mort cette légende urbaine. Une question sur le site Yahoo Q/R concernant la différence de capacité annoncée pour un disque dur m’a fait émettre cette réponse :
Le problème vient d’une définition. L’ordinateur est la machine la plus c*nne de la création. Il ne sait manipuler que deux valeurs : 0 & 1. Donc, contrairement à l’humain qui compte en base 10 (0 à 9), l’ordinateur compte en base 2.
De l’unité de base, octet, on en déduit :
Le Kilo-Octet : 2^10 octets = 1024 octets.
Le Méga-Octet : 2^10 Ko = 1 048 576 octets
Le Giga-Octet : 2^10 Mo = 1 073 741 824 octets.Jusqu’en 1998, on parlait des mesures ainsi, jusqu’à l’invention d’appellation spécifique.
Hors, Giga signifie 1 milliard pour l’humain. Tu as une différence de 7,374% entre le Giga humain et le Giga informatique.
(500 * 7,374) / 100 = 36,87… Donc, la différence que tu observes entre ta taille « commerciale » et la taille réellement exploitable du disque dur. Le formatage n’enlève pas le moindre octet à la taille de support.
Et pour info : 500 milliards d’octets (taille commerciale) divisée par le taille informatique du GigaOctet à savoir 1 073 741 824, cela donne :
500 000 000 000 / 1 073 741 824 = 465,661287308
Donc, la preuve est faite : aucun octet n’est perdu par le formatage.
En effet, en 1998, il a été décidé que l’on parlerait d’unité spécifique, les KiO (pour KibiOctet), MiO (pour MibiOctet), GiO (pour GibiOctet)… Mais faire disparaitre plusieurs décennies d’habitude d’appellation… Bon courage ! 🙂
Non, je n’ai pas fait de faute de frappes dans le titre. Je parle bien de Firefox 3.1, dont la sortie est prévue pour décembre 2008.
Le support des CSS3 semble être assez intéressant, pour ne pas dire « parfait » sur le plan des sélecteurs.
En effet, jettant un oeil sur la page de suivi de modification du code de Firefox 3.1 (mozilla-central actuellement), j’ai pu lire ceci :
2008-06-02 20:17 -0700 L. David Baron – Implement :first-of-type, :last-of-type, and :only-of-type. b=128585 r+sr=bzbarsky default tip
2008-06-02 20:17 -0700 Daniel Glazman – Implement :nth-child(), :nth-last-child(), :nth-of-type(), :nth-last-of-type(). b=75375 r+sr=bzbarsky
2008-06-02 20:17 -0700 L. David Baron – Make nsPseudoClassList capable of storing integer pairs for :nth-*(). b=75375 r+sr=bzbarsky
Ce sont des sélecteurs liés aux CSS de 3ième génération. J’ai donc lancé le test du site CSS3.info, la capture d’écran étant suffisamment parlante.
Dommage cependant que certaines parties ne soient pas encore supportées, comme les ombres sur les polices, cf le bogue 10713 qui empèche d’avoir un bel affichage « ombré » sur le test Acid3 dont le résultat s’est légèrement amélioré récemment, passant de 71 à 73/100 🙂
Comme quoi, Firefox 3.1 prévu pour décembre ne sera pas qu’un simple « ravalage » de Firefox 3 🙂
Je me suis basé sur la révision 31787 de WebKit-Gtk pour rédiger cet article. Après avoir lancé une compilation en activant le support du SVG – avec un ./configure --enable-svg-experimental – puis une fois la compilation terminée avec le programme de test GtkLauncher.
Si au premier passage, le test n’est pas passé, au second lancement, celui-ci se lance, donnant un résultat presque parfait, n’affichant qu’une erreur : « Linktest failed ».
Au moins, cela laisse de l’espoir pour le futur d’Epiphany, dont la version 2.24.x (en clair, celle qui sortira avec Gnome 2.24 en septembre prochain) d’utiliser WebKit sans gros problème de rendu.
En l’espace de quelques heures, les équipes d’Opera et de Safari ont annoncé passé officiellement la totalité du test Acid3.
Webkit l’annonce en grande pompe :
With r31342 WebKit has become the first publicly available rendering engine to achieve 100/100 on Acid3. The final test, test 79, was a brutal torture test of SVG text rendering. Details of the bugs we fixed will follow. Indeed, we found a critical bug in the test itself that would have forced a violation of the SVG 1.1 standard to pass, so until a few hours ago it was not possible to get a valid 100/100. Acid3 test editor Ian Hickson has the details.[…]
Ce qui donne traduit :
Avec la révision 31342, Webkit a été le premier moteur de rendu disponible à atteindre les 100/100 sur Acid3. Le test final, le 79, était une torture brutale du rendu d’un texte en SVG. Le détail des bogues corrigés suivra. En effet, nous avons vu un bogue critique dans le test lui-même qui aurait forcé une transgression de la norme SVG 1.1 pour son passage, donc jusqu’il y a quelques heures il était impossible d’atteindre les 100/100. Le créateur du test Acid3, Ian Hickson a les détails.[…]
Pour être complet, des ajouts ont été faits pour rendre le passage « plus valide », et un autre annonçant qu’avec la révision 31356, la versions Windows est disponible.
Opera de son coté, a fait l’annonce aussi. Mais avec une subtilité intéressante ; l’annonce du passage est intéressante à lire :
Today we reached a 100% pass rate for the first time! There are some remaining issues yet to be fixed, but we hope to have those sorted out shortly.
We will release a technical preview version on labs.opera.com within the next week or so. For now, the screenshot above shows the Acid3 test as rendered in our latest WinGogi Desktop build. WinGogi is the Windows version of our reference builds used for the internal testing of Opera’s platform independent Core.
Ce qui donne traduit :
Aujourd’hui, nous avons atteint le score de 100% pour la première fois. Il reste quelques problèmes à corriger, mais nous espérons faire cela rapidement.
Nous publierons une version technique d’aperçu (Note du traducteur : une version alpha, donc) sur labs.opera.com d’ici la semaine prochaine environ. Pour le moment, la capture d’écran montre le test Acid3 affichée dans la dernière compilation de WinGogi Desktop. WinGogi est la versions Windows de nos compilations de référence utilisée pour les tests internes sur la plateforme Opera.
Donc, les deux déclarent passer le test Acid3, et un seul mot : félicitations. Cependant, dans un cas, on peut vérifier les dires avec une compilation téléchargeable, et sur l’autre, uniquement un communiqué.
Etant comme un certain apôtre, je ne crois que ce que je vois… Seul l’avenir nous dira quel sera le premier moteur STABILISÉ et donc rendu grand public qui passera Acid3. Je maintiens mon pronostic pour Safari et donc Webkit. Mais je peux aussi me tromper… Seul l’avenir nous le dira !
Certaines remarques sur le score passé par WebKit (la version de développement du moteur de rendu du navigateur d’Apple, à savoir Safari, logiciel libre) m’ont fait me poser des questions.
Un score de 95% (étant donné qu’il y a 100 « sous »-tests dans le test) pour une nocturne récente de la version MacOS du moteur, des versions très récentes (révision 31108 pour Windows et 31107 pour linux) donne des scores inférieurs quoique proche.
La seule différence entre les deux révisions datées d’hier ? Un bug de compilation sous Windows.
Révision 31108 sous Windows : 94%
Révision 31107 sous Linux : 90%
4 tests passés sous la versions Windows bloquent avec la version linux. Etrange, étant donné que c’est le MÊME code source utilisé pour le moteur sur les 3 plateformes. Et pourtant, je ne fais que suivre les infos proposées pour la compilation du code. L’utilisation d’autres options faisant planter la compilation avant son terme ! 🙁
J’avoue y perdre le peu de latin que j’ai jamais acquis. Des idées ?!
En tout cas, le score s’approcherait du mythique 100%, du moins si on en croit ce billet du blog des développeurs de Webkit…
Il y a une quinzaine de jours, j’avais fait un bilan des versions de développement de Safari et Konqueror 4.x (WebKit), Firefox 3 (Gecko 1.9), et d’Opera 9.5 (en préversion béta 2).
Après avoir compilé le code de WebKit pour GTK, à savoir la révision 31232 en date du 22 mars 2008, j’obtiens un score de 89%. Soit 2% de plus.
En ce qui concerne Gecko 1.9, en pré-béta5, le score s’améliore légèrement, en passant à 71%.
Enfin, le bon le plus spectaculaire est celui d’Opera. La version hebdomadaire de Pâques – il ne faut pas demander beaucoup plus à ce logiciel propriétaire 🙂 – le score atteint 77%, soit un bond de 10%.
Le classement final évolue légèrement :
1er : Webkit, passant de 87 à 89%
2ième : Opera 9.5 pré-béta2, et remonte d’une place, passant de 67 à 77%
3ième : Firefox 3.0 pré-beta5.
Score qui ne risque plus de trop évoluer pour Firefox 3, peut-être un ou deux pourcent de plus.
Ce billet complète le précédent. J’ai pu compiler sans trop de problème la révision 30885 du moteur Webkit, et les résultats sont explosifs… 87/100 !!!
Pour compiler le moteur Webkit, je me suis basé sur cette page : http://trac.webkit.org/projects/webkit/wiki/BuildingGtk. Le code source étant récupérable sur cette page : http://nightly.webkit.org/
A noter que le support du svg soit désactivé… En effet, voici ce que donne le bilan de la commande ./autogen.sh :
Build configuration:
Enable debugging (slow) : no
Code coverage support : no
HTTP backend : curl
Optimized memory allocator : yes
Features:
HTML5 cross-document messaging : yes
HTML5 client-side storage support : yes
HTML5 video element support : no
Icon database support : no
SVG support : no
SVG animation support : no
SVG filters support : no
SVG fonts support : no
SVG foreign object support : no
SVG as image support : no
SVG use element support : no
XPATH support : yes
XSLT support : yes
GTK+ configuration:
GDK target : x11
Hildon UI extensions : no
Quoiqu’il en soit, il semble être certains que la future version stable de Webkit passera lui aussi le test acid3… Du moins, c’est bien parti pour 😉