jy[B]log

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 !

Daniel Glazman, aka glazou, vient d'être nommé co-chairman du CSS Working Group au W3C. Félicitation à toi Daniel !

J'ai comme l'impression que ça va bouger un peu plus du coté de CSS3 ;-)

Allons bon, Adobe sort le première version stable de AIR. Certains s'en félicitent, voir même ont fini par oublier un concurrent : XulRunner. Certains le croient mort. Moi-même il y a quelques mois, j'ai douté.

Mais d'ici quelques mois, il sera installé sur des centaines de milliers, non, que dis-je, des millions de machines (20% de part de marché des navigateurs, ça représente bien des millions d'internautes n'est-ce pas ?). Sans même que les utilisateurs "lambda" le sachent. Car il sera installé sous un autre nom : Firefox 3.

En effet, Firefox 3 est basé sur XulRunner. Et Firefox 3 pourra lancer des applications XulRunner. Ainsi, pour lancer une application avec XulRunner, on fait ça (dans une console, dans un raccourci sur le bureau ...) :

  xulrunner.exe application.ini

Maintenant avec Firefox 3, on peut faire ça :

  firefox.exe -app application.ini

À cela il faut rajouter Prism, qui est une application, basée elle aussi sur XulRunner, permettant de lancer une application web de la même manière qu'une application desktop.

Est ce que Adobe AIR aura le même taux de pénétration ? Rendez-vous à la fin de l'année.

Note : application.ini est un fichier qui contient des infos sur l'application à lancer.

PS: à moins qu'ils décident, chez Mozilla, de supprimer cette option -app pour diverses raisons... Mais dans ce cas, on pourra toujours fournir les applications sous forme d'extensions ;-)

David Baron vient d'intégrer dans les sources de Firefox 3 des corrections sur les sélecteurs de pseudo classes (genre :empty, :only-child, :last-child etc..). Avant, par exemple, il y avait un bug avec :empty : la sélection se faisait bien au chargement du document, mais si un élément non vide devenait vide ou l'inverse, la sélection ne se faisait plus. Et je vous parle de :empty parce que ce bug m'empêchait d'utiliser ce sélecteur dans Etna, mon éditeur XML wysiwyg, et m'obligeait du coup à des petites acrobaties dans le code qui me déplaisaient.

Ainsi, grâce à cette correction, le support des sélecteurs CSS3 dans Firefox 3.0b4 sera largement amélioré, la suite des tests de css3.info en atteste. Voici un comparatif :

En fait, il ne reste plus que 7 sélecteurs à implémenter correctement : :nth-child(), :nth-last-child(), :first-of-type, :last-of-type, :only-of-type, :nth-of-type(), :nth-last-of-type(). Peut-être y'aura-t-il encore des améliorations sur ceux-là d'ici Firefox 3 final mais ce n'est pas encore sûr.

À noter que webkit (safari et Konqueror) ainsi qu'opera je crois, passent la suite de test complètement avec succés.

PS : une autre conséquence de cette correction est que trois tests supplémentaires passent avec succés [au test acid3|http://acid3.acidtests.org/], avec un score de 64/100.

Je m'en fiche de plus en plus de IE. Vous savez pourquoi ? Parce que de moins en moins de monde va utiliser IE. Je predis que d'ici 2-3 ans, IE passera sous la barre des 50%. Peut-être pensez vous que je sois optimiste, mais plusieurs choses me le font penser :

1. Techniquement, IE7 est à la ramasse même si il y a eu quelques progrés. IE8 est loin d'être encore sorti. Les développeurs en ont marre de cette bouse et beaucoup font (inconsciemment ou pas) de la pub pour les autres navigateurs. Surtout que les dernières ou prochaines versions de Firefox, Safari et Opera ont des possibilités techniques vraiment attrayantes (et qui apportent un avantage concurrentiel, voir plus loin).
2. La montée en puissance des navigateurs alternatifs sur le desktop. Notamment Firefox avec ses 28% de part de marché en europe. Presque 1/3, c'est pas rien. Et ce n'est pas terminé.
3. La croissance fulgurante des appareils mobiles embarquant un navigateur (quand je dis appareil mobile, j'inclus téléphone, PDA etc..). L'extrême majorité de ces appareils n'embarquent pas IE, mais Opera, Safari (pour l'iphone) ou des navigateurs à base de webkit ou gecko. La raison : peu d'entre eux sont sous windows mobile, mais sur des systèmes alternatifs en particulier Linux. Linux qui ne cesse de croitre ses parts de marché sur le mobile...
4. À cela faut il ajouter dans les deux ans qui vont suivre la sortie du système d'exploitation Android de Google, spécifique pour les appareils mobiles, et qui embarquera non pas IE, mais webkit. Vu la puissance de Google, on peut parier sur une utilisation massive de ce système dans les prochaines générations d'appareils.
5. Et d'ici deux ans aussi, la sortie de Mozilla Mobile, qui sera disponible sur plusieurs plate-formes donc a de forte chance d'être utilisé massivement lui aussi. (Oui, la guerre qui vient de commencer sournoisement, ce n'est pas IE contre les autres, mais Gecko vs Webkit).
6. Autre argument à prendre en considération : Gecko, Webkit et opera implémentent ou vont implémenter des possibilités de HTML5, en particulier tout ce qui concerne l'exécution d'appli web en mode déconnecté (offline). Ce qui est très utile et important dans le monde du mobile, où on peut souvent être déconnecté d'un réseau. Ces technologies sont je pense des arguments qui peuvent faire poids dans le choix d'un navigateur, pour un constructeur de mobile. Étant donné qu'on ne sait pas encore si IE8 supportera ce genre de fonctionnalités...

Mes deux sous...

Le premier test acid se focalisait sur le modèle de boîte CSS. Le test acid2 se focalisait sur CSS en général, sur le support de PNG. Voici maintenant le test acid3, qui se concentre plus sur l'ensemble des technologies web, comme HTML, CSS, ECMAScript, SVG et XML. Les 100 tests sont réalisés aux travers de l'api DOM.

Dans les navigateurs que j'ai pu lancer :

• Firefox 2 (linux et windows) : 50/100
• Firefox 3b3 (linux) : 59/100
• Firefox 3b4 en cours de dev (linux) : 64/100
• Konqueror 3.5.8 (linux) : il plante (crash) lamentablement durant le test
• Opera 9.25.687 (linux) : 47/100
• IE6 (windows) : 13/100 (ridicule, mais logique pour un navigateur aussi vieux)

Notez toutefois que la suite de tests est en "rodage", comprendre par là qu'il y a peut être quelques bugs à corriger avant que cela devienne "officiel" (et donc les scores changer dans les navigateurs).

Mais quelle connerie !! Sous pretexte de ne pas vouloir casser les sites qui s'affichent bien dans IE6 et IE7, Microsoft va introduire dans IE8 l'utilisation d'une balise meta pour dire que la page respecte les standards, et donc que IE8 peut l'afficher selon les standards. Un truc dans le genre :

 <meta http-equiv="X-UA-Compatible" content="IE=8" />

Donc en clair, il n'y aura pas seulement 2 modes d'affichage, "quirks mode" (IE6 et -) et "standards mode" (IE7), mais un troisième mode "super standards".

Mais c'est vraiment n'importe quoi ! Et dans IE9, on aura quoi ? D'autant plus que cela pose une multitude de problèmes aux implémenteurs de IE (m'enfin ça c'est leur problème), mais surtout des problèmes incommensurables aux développeurs web ! Il va bientôt falloir faire une page pour chaque IE ??

Franchement, ils se foutent vraiment de la gueule du monde chez Microsoft.

Pour comprendre le pourquoi et le comment, lire par exemple ce billet, celui-là, celui-là, ou lisez aussi les 300 commentaires au billet de la team IE conçernant cette stupide "feature".

Mise à jour 24/01/2008: IE8 pourra switcher vers le mode standard avec le doctype HTML5, donc il n'y aura pas besoin de cette balise meta.

Pour faire des boutons, il y a une balise sympa en HTML : <button>. On peut s'en servir notamment pour les boutons d'envoi de formulaire :

 <button type="submit" name="validation" value="save">Enregistrer</button>

Comme vous le voyez, l'avantage par rapport à un <input type="submit">, c'est que l'on peut spécifier une valeur, que l'on recevra coté serveur. Et au niveau du libéllé, on peut en principe mettre n'importe quoi : du texte, d'autres balises HTML... C'est particulièrement sympa quand vous avez plusieurs boutons d'envoi :

 <button type="submit" name="validation" value="save">Enregistrer</button>
 <button type="submit" name="validation" value="prev">Prévisualiser</button>

Coté serveur, en PHP par exemple, on a juste à tester la variable $_POST['validation'] par rapport aux valeurs "save" et "prev", afin de savoir quoi faire.

J'avais donc choisi d'utiliser ces boutons dans jForms, le système de formulaire de Jelix. Et ça fonctionne parfaitement dans Firefox, Konqueror, IE7 et certainement Opera. Mais je viens de faire machine arrière, à cause de bugs dans IE6 que l'on m'a rapporté.

Le premier bug, c'est que IE6 n'envoie pas la valeur que l'on met dans l'attribut value, mais le contenu de la balise button. Elle a donc le même fonctionnement que input dans IE6. C'est un bug que j'ai pu contourner dans jForms. Mais IE6 n'avait pas fini de me donner du fil à retordre.

En effet, quand plusieurs boutons ont le même nom, il renvoi toujours le libellé du dernier bouton, quel que soit le bouton sur lequel on clique ! Je me suis alors dit, bon, je ne vais pas appeler les boutons avec le même nom, et je vais faire du bidouillage dans jforms pour que dans jelix, on ait les valeurs sous un même nom. Mais voilà, peine perdue : quand on clique sur un bouton submit, IE6 envoit non seulement le libellé de ce bouton, mais aussi les libellés de tout les autres boutons submit qui n'ont pas le même nom ! Il est comique IE6 n'est ce pas ?

Conclusion : la balise <button> est inutilisable à cause de IE6, car encore largement répandu. J'ai donc à regret mis des <input type="submit"> dans jForms :-(

Mise à jour 04/11 11h23 : Le problème que j'évoque dans ce billet n'existe plus depuis quelques heures. Merci à Nico de l'avoir signaler :-). Firefox 3 beta 1 ne bloquera plus l'accés aux sites SSL qui n'ont pas de certificat signé par une autorité de confiance. La page d'erreur s'affiche toujours, mais on a désormais un bouton (voir une capture d'écran) permettant d'ajouter le site dans une liste d'exception. Et l'on peut ensuite accéder au site normalement. Vous pouvez donc considérer le contenu de ce billet comme étant obsolète :-)

Ce n'est pas une nouvelle fraîche. Je l'avais déjà lu il y a plusieurs semaines sur la planete Mozilla, sans y attacher une grande importance (désolé, je ne retrouve pas le lien du billet en question). Mais voilà, j'ai voulu aller sur un site perso en SSL (https) avec la version alpha de Firefox 3, et je n'ai pas pu y accèder. Et ça m'agace au plus haut point. En effet, si le site utilise un certificat non signé par une autorité de confiance, Firefox affiche une belle page d'erreur expliquant que le site n'est pas sûr ! Il n'y a plus le simple popup d'avertissement. Il n'y a plus aucun moyen de passer outre cet avertissement. Firefox vous empêche tout bonnement d'aller surfer sur ces sites SSL.

Et là je dis : C'EST DE LA BÊTISE PURE ET SIMPLE !

Pourquoi ?

Premièrement, à cause de la conséquence : la plupart des sites SSL seront inaccessibles aux internautes lambda car la plupart des sites SSL utilisent des certificats non signés par des autorités de confiance.

Deuxièmement, parce que Mozilla semble imaginer que tous les propriétaires de serveurs font parti du Fortune 500 ! En effet, savez-vous pourquoi ces certificats ne sont pas signés par une autorité "de confiance" ? Parce que ça coute la peau des fesses (enfin presque ^[1]) ! 400 dollars par an chez Verisign ! Une véritable extorsion ! De là à penser que... Non rien. Enfin bref, toutes les associations, les propriétaires privés de serveurs, les petites entreprises etc, ne peuvent pas se payer ces certificats, donc font ce qu'ils peuvent pour avoir des accès sécurisés à leurs applications.

Troisièmement : cette précaution est complètement inutile. Elle emmerdera tout le monde (c'est à dire les internautes et les propriétaires de site en grande majorité honnêtes), tout en apportant rien. En effet, il y a deux solutions pour contourner cette interdiction :

1. Le site ne propose plus un accès en SSL. Pour la sécurité des échanges, c'est donc mort. Un comble quand on sait que Mozilla prône pour un web mieux sécurisé.
2. Le site en question propose, sur un espace non sécurisé (ah ah la bonne blague), la clé publique de l'autorité qui a signé le certificat, (la clé publique du certificat racine et cette autorité étant dans la majorité des cas le site lui même, et non une autorité reconnue comme "de confiance"). Un lien vers cette clé, un clic, et elle est installée dans Firefox. Cette autorité "factice" devient alors, aux yeux de Firefox (donc à vos yeux), une autorité de confiance. On peut alors se balader sur le site SSL. Conclusion : Mozilla voulait, par cette page bloquante, empêcher que l'internaute aille sur un site malveillant. Peine perdue. Certes, c'est plus long d'aller cliquer sur un lien qui installera un certificat, que de cliquer aveuglement sur un popup d'avertissement comme c'est le cas dans Firefox 2.0, mais le résultat est finalement le même (oui, il y a un soupçon de mauvaise foi dans mon propos).

Une autre solution à ce problème, qui serait avantageuse pour les petits hébergeurs, les associations etc, serait que Firefox inclus en standard, au même titre que les clés publiques de Verisign et cie, la clé publique du certificat racine de CAcert, un organisme qui signe gratuitement vos certificats. Mais bon, comme c'est gratuit, on vous dira que ce n'est pas une autorité "de confiance"...

D'un autre coté, on peut se demander si tout ça n'est pas la faute à SSL. On devrait peut-être tout bonnement le virer et le remplacer par quelque chose de plus simple. Ce protocole est franchement compliqué à utiliser, ne serait-ce que lors de la création d'un certificat, avec des lignes de commandes à rallonge et des fichiers de configurations obscures.

Note : Firefox 3.0 n'étant qu'à sa version alpha, on peut espérer qu'ils fassent machine en arrière. Mais bon.. MIse à jour : c'est fait, voir l'avertissement en début de billet :-)

La nightly de Webkit, le moteur de rendu de Safari entre autre, supporte la rêgle CSS @@font-face@@. Ce qui veut dire que l'on peut indiquer dans sa feuille de style l'url d'une font à utiliser : le navigateur télécharge alors la fonte et l'utilise là où c'est indiqué.

 @font-face {
    font-family: "Kimberley";
    src: url(http://www.princexml.com/fonts/larabie/kimberle.ttf) format("truetype");
 }

 h1 { font-family: "Kimberley", sans-serif }

C'est une propriété CSS2 qui est beaucoup attendu par les webdesigners, et Webkit est le premier à l'implémenter complètement (IE 4 le permettait mais seulement pour des fontes dans un format propriétaire). Une prochaine version d'Opera proposera très certainement aussi cette propriété. Quant à Firefox, ce n'est pas à l'ordre du jour (voir le bug correspondant), et en tout cas la version 3 ne supportera pas font-face.

À lire sur le sujet : un article récent d'Håkon Wium Lie, l'inventeur de CSS et travaillant pour Opera. Pour Håkon, la prise en charge des fontes téléchargeables dans CSS devient nécessaire. Voir aussi une interview sur CSS3.info.