jy[B]log

Je suis sorti ravi des 3 jours de conférences de Paris Web 2008. Un succès sur toute la ligne de mon point de vue. Des conférences très intéressantes, faites encore et toujours par des personnes de qualité, Par exemple, "Accessibilité : des volontaires ?" faite par Stéphane Deschamps et Aurélien Levy fut grandiose, très démonstrative sur l'accessibilité.

Mais le must fut d'avoir pu rassembler des représentants de chaque équipe de développements des principaux navigateurs du marché :

• Chris Wilson, "Platform Architect " dans le projet Internet Explorer 8
• Julien Chaffraix, contributeur pour WebKit (Safari)
• Paul Rouget, tech evangelist chez Mozilla
• Charles Mac Cathie Neville pour Opera.

Je pense que c'est un événement très rare au monde de pouvoir les avoir tous autour d'une table ronde. J'ai trouvé Chris un peu sur la défensive, mais il y a de quoi, assailli de questions qu'il fut (sans parler de la barrière de la langue). Il faut dire que IE8 rattrape vite son retard, bien que technologiquement parlant, il sera encore en deça de la concurrence, Et il est attendu au tournant par les développeurs web. Chris est l'un de ceux qui poussent à l'implémentation des standards chez Microsoft. Aussi l'avenir de IE est prometteur pour le web.

Vivement Paris-Web 2009 !

PS: pour les slides des conférences, ils seront tous en ligne via le site de paris-web. Un peu de patience donc :-)

Au mois d'aout dernier, Schrep avait écrit un article sur son blog, répondant à certaines questions sur l'existance de cette nouvelle balise video, et surtout sur l'utilisation du format ogg theora par défaut.

Cet article vient d'être traduit en français sur framablog. À lire !

En résumé :

• La spécification de la balise video n'impose pas un format, tout comme la balise img. Et on se rend compte que seul quelques formats d'images sont vraiment utilisés. Il en sera certainement de même pour les formats video.
• Il faut cependant promouvoir un format libre, ne nécessitant pas de plugins propriétaires. En effet, ces plugins ne sont que très rarement présent sur les mobiles. Or ce genre de plate-forme est en pleine expansion. Et même sur les desktops, il y a des chances que ces plugins ne soient pas installés. (Note de moi même: flash fait quand même exception)
• ogg theora n'est pas très répandu, mais une fois Firefox 3.1 sorti et d'autres (200 millions d'utilisateurs), ça le sera très certainement, tout comme cela a été pour le H264, qui n'était pas très répandu il y a quelques années..
• utiliser un format libre, cela veut dire que n'importe quel navigateur, n'importe quel appareil, peut l'utiliser librement, pas de royalties. Cela veut donc dire aussi que quiconque embarque Firefox, Fennec, Gecko dans son appli ou son mobile, peut utiliser librement ogg theora, peut afficher de la video sans souci. Ce ne serait pas le cas si l'implémentation de Mozilla reposait sur des formats non libres, puisque cela voudrait dire utilisation de bibliothèques non libre, payement de royalties etc. Et cela rendrait Firefox non libre.
• pas de brevet logiciels à l'horizon sur ogg theora. Mais il peut exister des brevets "cachés". Cependant, c'est la même problématique que pour tout développeur de logiciels. Personne n'est à l'abri. Si cela arrive, Mozilla fera tout pour invalider ces brevets, ou pour utiliser librement le format ogg theora.

Le reste chez framablog

Daniel demande si on aimerait avoir des propriétés d'animations en CSS^[1]. Les développeurs de webkit proposent en effet une spécification pour pouvoir faire des animations en CSS.

Il faut savoir qu'en SVG, nous avons de quoi faire des animations. Une partie de ces balises et attributs proviennent d'ailleurs du langage SMIL, avec quelques trucs en plus.

Alors, pour faire des animations, CSS ou SMIL ?

Avantages de CSS

• ça a l'air plus simple à écrire, c'est moins verbeux.
• on peut utiliser la cascade CSS pour redéfinir des propriétés d'animations. Cette redéfinition peut être utile aussi dans les feuilles de style utilisateurs.
• en théorie, cela fonctionne pour n'importe quel langage XML, puisque CSS n'est pas dédié uniquement à (x)HTML, bien que SMIL 3.0 le permette plus ou moins, mais c'est plus intrusif.

Avantages de SMIL^[2]

• les séquences de transformation et d'animations peuvent être modifiées dynamiquement, de manière plus simple je trouve, puisqu'il suffit d'utiliser les fonctions DOM classiques. Tandis que pour CSS, faut se coltiner le DOM CSS qui n'est pas très pratique je trouve.
• SMIL est beaucoup plus riche et plus précis (en tout cas,par rapport à l'état actuel de la spécification de webkit)
• SMIL est du contenu XML, donc utilisable par autre chose qu'un navigateur graphique. Au niveau accessibilité donc, il apporte des informations, permettant de retranscrire l'animation oralement par exemple (même si ça doit être difficile à écouter :-))

Conclusion

Je pense que les animations CSS ont leur place, surtout pour les petites animations qui sont purement décoratives. Pour les animations qui ont plus de sens, une animation dans un tutoriel par exemple, montrant vraiment quelque chose d'informatif, on préférera SMIL. C'est un peu la même chose entre choisir background-image et l'élément HTML img pour afficher une image.

Donc je dis oui aux animations CSS :-)

Ce week-end, l'implémentation des propriétés de transformations CSS ont été incluses dans la version de développement de Firefox 3.1 (proposé par David Hyatt dans webkit il y a un an, et en partie au CSS working group, il y a 10 ans).

La propriété transform permet d'appliquer des transformations sur un élément : rotation, décalage, zoom, déformation, perspective. Je me suis amusé donc à faire quelques essais.

Je veux placer ce titre verticalement à gauche de la page :

Voici alors les styles appliqués :

 position: absolute;    /* pour sortir l'élement du flux normal */
 top:0; left:0;   /* on le place tout en haut à gauche */

 /* on fait une rotation de -90 degré, suivi d'une translation vers la gauche de 10em 
   10em étant à peu prés la longueur du texte */
 -moz-transform: rotate(-90deg) translate(-10em,0);

/* le centre de rotation se situe en haut à droite de la boite h1 */
 -moz-transform-origin: top right;

Et le résultat :

Imaginons maintenant que je veuille mettre une belle icône "nouveau" sur un article, en travers du titre de cet article. Plutôt que de faire une image comme on doit le faire dans les navigateurs actuels, faisons tout ça en CSS/HTML. Le HTML est le suivant:

 <h2><span>Nouveau ! </span>Lecteur MP3 Syno XZ-789</h2>

Appliquons maintenant le style de transformation :

 -moz-transform: rotate(-20deg);
 -moz-transform-origin: center center;

On obtient ceci :

Habillons le maintenant en utilisant border-image et cette image

 border-width: 15;
 -moz-border-image: url(etoile.png) 15 15 15 15 round round;

Et voici notre super logo :

Vous remarquerez qu'il apparaît de fines lignes blanches en pointillé, je suppose que c'est un bug qui j'espère n'existera plus dans Firefox 3.1 :-)

J'ai essayé rapidement aussi d'avoir des en-tête de colonnes obliques dans un tableau :

Mais ça ne donne pas un résultat vraiment interressant. Déjà la taille des colonnes restent les mêmes, mais aussi les bordures entre cellules ne sont pas prisent en compte...Il faudrait que je triture un peu plus la feuille de style je pense...

• Annonce de l'implémentation sur Mozilla Web-tech
• Brouillon des spécifications par l'équipe de webkit
• CSS3 transform au W3C (pas encore de spécification à ce jour)

Si vous pensiez qu'Openweb, l'un des tout premiers sites francophones sur les standards, était mort, vous êtes dans le faux.

L'équipe s'est plus ou moins renouvelée depuis quelques mois, et quelques nouveaux articles ont été publié. Mais ce n'est pas fini.

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 !

En ce moment, entre les moteurs de rendu web, c'est la course à celui qui passera les tests acid3 au complet le plus tôt possible.

Je viens de voir par exemple que la nightly de Webkit a un score de 86/100 ! Alors qu'il y a quelques jours il n'en était qu'à 79/100 apparement. La nightly de Firefox (future beta4) en est aujourd'hui à 67/100. La beta 3 ayant un score de 59/100.

Quant à IE, son score actuel est... Non rien...

C'etait Laurent, du stand Mozilla, en direct du Fosdem. À vous les studios

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 :-(