jy[B]log

Les nouvelles propriétés CSS qui arrivent dans nos navigateurs permettent de faire des choses plus sophistiquées mais de façon plus simple qu'avant.

J'avais déjà montré cette facilité en appliquant des styles d'ombrages et de rotation sur la page d'accueil de jelix.org. Mais il n'y a pas que les sites web qui vont pouvoir profiter de ces avancées, il y a aussi Firefox.

Comme vous le savez certainement déjà, Firefox utilise un langage XML, le XUL, pour son interface graphique et CSS pour le design de cette interface. Je vais prendre un exemple de l'utilisation des nouvelles propriétés CSS dans Firefox : la barre de boutons de la boite de dialogue des extensions, sous MacOSX.

Dans Firefox 3.0, ça donne ça :

C'est assez sobre. Pour les arrondis sur les boutons droite et gauche, border-radius^[1] est utilisée, et sur tout les boutons, il y a une simple image de fond avec un léger dégradé.

Durant le développement de Firefox 3.5, est arrivé la propriété border-image (Voir un de mes billets sur ce sujet). Un contributeur s'est dit, "utilisons là", pour rendre ces boutons plus jolis. Et les boutons sont devenus ceci, comme on peut le voir dans Firefox 3.1 beta3:

Comme vous le voyez, avec border-image, on peut faire des bordure plus sympa et assez facilement en CSS. D'ailleurs l'auteur en a profité pour ajouter des "effets" selon l'état du bouton (voir par exemple le bouton "extension" sur lequel j'ai le bouton de la souris enfoncé). Le seul souci de cette approche est que ça utilise pas mal d'images. Déjà, il y a trois types de boutons (gauche, milieu, centre), mais en plus il y a plusieurs états du boutons : relâché, sélectionné, enfoncé, actif etc... Voici par exemple trois de ces images pour le bouton de droite :

Pour réaliser des bordures complexes, on n'a toutefois pas le choix.

Mais que remarque-t-on sur ces images ? En fait elles ne font que reproduire des effets d'ombres.

Des ombres ? Ça tombe bien, il y a une autre nouvelle propriété dans Firefox 3.5 pour faire des ombres : box-shadow. Et si on l'utilisait ? C'est ce que s'est dit un contributeur. Hop, quelques lignes de css à modifier, suppression de toutes ces images (70ko en moins) et le résultat que vous pourrez admirer dans Firefox 4^[2] :

On obtient quasiment la même chose qu'avec la technique du border-image précédente, mais sans images donc plus léger, avec une manière plus simple de créer et modifier le design.

Mozilla et Khronos annoncent la création d'un standard ouvert pour définir une API 3D en javascript, sur l'élément canvas en particulier. (voir le billet de Tristan pour plus d'info).

Comme à l'époque de l'apparition de canvas, resurgissent les questionnements sur l'utilité d'une API^[1] face à des formats existants comme SVG pour la 2D, et X3D/WRML pour la 3D. Pour quoi faire une API alors que des formats existent ?

Réponse : parce que ce n'est pas du tout fait pour le même usage.

Un document (SVG,X3D ou autre), c'est statique. Je peux le trimballer où je veux. D'ailleurs, je n'ai pas à le "programmer". Je sors un outils comme Inkscape pour faire un joli dessin ou logo avec ma souris, je l'enregistre au format SVG, et je peux alors le lier dans une page web, l'utiliser comme îcone d'un programme (dans le bureau KDE par ex). Comme c'est du vectoriel, je peux l'afficher en gros, en petit. Je peux l'envoyer par mail, le compresser, le détruire. Bref. C'est un document comme n'importe quel document, et c'est utilisable en dehors du contexte web.

Canvas, c'est comme si vous aviez un tableau blanc dans votre page web. Et avec son API 2D et bientôt 3D, c'est comme si vous disposiez de crayons de couleurs et autres outils de dessin.

Ainsi, avec canvas et ses API, je ne peux pas faire la même chose qu'avec un document. Ce que je dessine avec mes crayons de programmeur, je ne peux pas le trimballer où je veux. Je ne peux pas en faire un document.

Par contre je peux faire d'autres choses que je ne peux faire avec un document. Je peux faire des animations, sans être limité à la structure d'un format d'un document. Je dessine ce que je veux, d'une manière simple, et surtout dynamiquement. C'est donc idéal par exemple pour représenter à l'écran des choses qui bougent tout le temps. Il est impossible par exemple d'utiliser un document SVG pour dessiner une scène 3D dans laquelle le point de vue change tous le temps (comme dans un jeu comme Quake). Ce serait en tout cas absolument inefficace. Essayez donc de réaliser la même chose que cette démo 3D, avec du SVG ou X3D. Bon courage ! D'ailleurs, la future API 3D va être utile pour ce genre d'application : les performances seront bien meilleures qu'avec l'api 2D actuelle de canvas, et la programmation sera simplifiée.

Il n'y a pas, bien sûr, que les jeux où canvas est utile. Représenter des graphes de statistiques dynamiquement, manipuler le rendu d'autres éléments HTML, comme dans une des démos de Paul, faire des éditeurs de dessins, ou l'utiliser comme surface de rendu d'un éditeur de texte et j'en passe et des meilleurs... L'utilisation de canvas va bien au délà de ce qu'on peut faire avec un document SVG/X3D.

À contrario, utiliser canvas pour afficher simplement un logo, aussi complexe qu'il serait, est assez ridicule, vu le nombre de lignes de code qu'il faudrait taper. Utiliser un document SVG est plus pertinent. Mieux que du PNG d'ailleurs, puisqu'on peut utiliser le même document pour afficher le logo en taille différente, ce qui permet de diminuer les temps de téléchargement (le SVG est placé dans le cache du navigateur). C'est d'ailleurs je pense l'une des raisons de l'implémentation de SVG dans les navigateurs modernes destinés aux mobiles et cie...

Bref, les usages de SVG/X3D et de canvas ne sont pas les mêmes, et n'ont d'ailleurs pas les mêmes résultats. C'est comme si on comparait un 4x4 et une voiture de sport. Ces deux types de véhicules permettent tout deux de se déplacer. Ils ont 4 roues, un volant, un moteur. Mais on ne les utilisent pas forcement pour les mêmes raisons et de la même façon. Si on veut faire une course sur circuit, on utilisera une voiture de sport. Mais si on veut rouler sur des chemins accidentés, on utilisera un 4x4.

Comme vous le savez certainement, un nouveau projet est sorti des laboratoires de Mozilla : Bespin. C'est un éditeur de code en ligne. En découvrant ses entrailles, j'ai été bluffé par le fait qu'ils utilisent l'élément canvas pour faire le rendu.

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)

Après les améliorations qui viennent d'être apportées sur le moteur Javascript qui fait repasser Gecko 1.9.1 devant Webkit au niveau des performances de l'execution des scripts JS, voici que Neil Deakin (développeur Mozilla de son état), vient de terminer l'implémentation de l'API drag and drop de HTML5.

On peut donc apporter des fonctions de drag'n'drop dans une page web, tout aussi facilement que ce que l'on peut faire avec des bibliothèques comme jQuery. Sauf qu'il n'y a plus besoin de charger des kilos de scripts JS :-)

Bon bah ça y est, plus besoin de recourir à des divs dans tout les sens pour utiliser des images pour décorer les bordures des éléments HTML. Le support du style CSS3 border-image vient d'être intégré dans la version de développement de Firefox 3.1 :-) Voir une présentation de border-image sur css3.info. Comme la spécification au W3C est encore en brouillon, il faut utiliser -moz-border-image.

Firefox rattrape son petit retard sur l'implémentation de styles CSS3 par rapport à d'autres navigateurs :-)

Pendant qu'on en parle, au niveau du test acid3, il en est à 81/100.

PS : un post de John Resig qui explique un peu le fonctionnement

Firefox 3 est sorti, le record de téléchargement en 24 h a été officiellement établi. Mais ce n'est pas pour ça qu'il faut se reposer sur les lauriers. Après tout, la version 3.1 est prévue pour la fin de l'année, avec des choses sympas comme la balise <video> ou le style border-image. D'ailleurs, le trunk était à peine ouvert pour le développement de la 3.1, que pas mal de patchs ont été intégré, comme le support complet des sélecteurs CSS3, le support de text-shadow, des corrections pour le test ACID3 (ils en sont à 80% contre 70% pour Firefox 3), et plein d'autres "bug fix".

Mais ce n'est pas tout, il faut bien s'amuser aussi un peu, et donc certains expérimentent des petites choses. Roc par exemple, vient de faire un patch pour pouvoir utiliser du SVG avec background-image. Mais aussi <canvas> avec background-image.

 background: url(#truc);

où truc est l'id d'un morceau de SVG ou d'un canvas dans le document. Cela permet de faire des petites choses comme ça. Et bien sûr, on peut appliquer les autres styles background : background-position, background-repeat etc..

Pour l'instant, pas sûr que ce soit intégré dans Firefox 3.1. Patience donc :-)