Aller au contenu | Aller au menu | Aller à la recherche

jeudi, juin 24 2010

Pourquoi Firefox n'aura probablement jamais 100 au test acid 3

Parce que. Je vous l'ai déjà dit, ce test est débile ! :-)

Ok, plus sérieusement, et ça fait un bon moment que je voulais en parler (je sais je lag), la raison est toute simple : les trois derniers points à passer concernent le support des fontes SVG. Et Mozilla n'envisage pas de les implementer, au moins dans un avenir proche. Des développeurs, dont Roc, de Mozilla, en donne les raisons, sur son blog et dans les commentaires du bug. En gros :

  • Globalement les fontes SVG n'apportent techniquement rien par rapport aux fontes TTF ou WOFF
  • On peut faire des glyphes multi coloré et animé avec les fontes SVG, mais en fait, la spécification sur ces points est un cauchemar. D'ailleurs Opera et Webkit n'implémentent pas ces choses, et ont apparement un support très minimal des fontes SVG (juste pour passer le test acid3 ? ;-) )
  • Les autres types de fontes ont plus d'avantages :
    • techniquement plus riche ("Hinting, rasterization with subpixel antialiasing, far richer support for glyph selection and text shaping") puisqu'elles permettre de créer des glyphes pour des caractères aussi complexes que les caractères arabes par exemple
    • énormément plus de fontes déjà disponibles
    • plus compacte
    • support beaucoup plus large dans les logiciels (outils auteurs etc)

En conclusion, le support des fontes SVG ne leur semble pas très important pour le web, et pas très utile en fait.

Bien entendu, les supporters des fontes SVG pensent le contraire, et ne sont pas d'accord avec les arguments de Roc et cie. Honnêtement, je ne suis pas assez calé en typographie et sur les formats de fontes pour vous dire qui a raison et qui a tord.

Le fait est que Mozilla ne veut pas implémenter un truc qui leur semble peu utile et qui servirait juste pour avoir un meilleur score à un test. Ils préfèrent dépenser leur énergie à des choses plus importantes. Techniquement, je trouve que ça fait sens, très pragmatique, mais au niveau marketing, c'est sûr, c'est dommage.

Cependant, rien n'interdit à quiconque de proposer un patch. Si il est bon, il n'y a pas de raison (à mon sens) qu'il soit rejeté. Qui veut faire passer Firefox à 100 au test acid3 ?

Mise à jour 25/01/2011 : Alexander Limi, un des développeurs de Firefox, confirme le fait que Firefox n'aura pas 100%. Il rapport aussi, des propos de Boris Zbarsky (un des core-developers de Mozilla), expliquant que le support des fontes SVG dans les autres navigateurs est très minimes et tout juste suffisant pour afficher un score de 100% au test Acid3 (ce qui confirme les propos de Mitch 74 dans son commentaire plus bas).

jeudi, mars 26 2009

Différences entre documents et API

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.

Notes

[1] API= Application Programming Interface; C'est un ensemble de fonctions à utiliser dans un programme pour réaliser diverses tâches

dimanche, novembre 23 2008

Ma présentation à ParisWeb 2008

Je viens de mettre en ligne les slides de ma présentation à Paris Web 2008. Elle contient un peu plus de précisions et de liens par rapport à la version présentée en live.

lundi, octobre 20 2008

Animations CSS, ou SMIL/SVG ?

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

Notes

[1] Pour ceux qui n'ont pas trop suivi, il est en plein meeting du CSS Working Group au W3C à Mandelieu

[2] je ne suis pas un expert sur SMIL et les animations SVG, donc j'ai pu raté des avantages ou inconvénients sur ces langages

mardi, juillet 8 2008

canvas et svg utilisés pour le background

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);

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

jeudi, février 8 2007

En vrac

  • Dans le cadre de l'adaptation sur Gecko 1.9 (trunk Mozilla), d'Etna, l'éditeur XML wysiwyg que je développe chez DI, je suis donc tous les jours les évolutions du futur moteur de Firefox 3. Je peux vous assurer que ça va vraiment dépoter. De nombreuses refontes internes, meilleure prise en charge des standards (CSS avec test acid2, SVG avec les filtres et pas mal d'autres améliorations, DOM etc.), meilleures précisions dans l'affichage, meilleures perfs, moins de leaks...
  • À propos de Gecko 1.9, la version 1.9a2 est sortie
  • Comme tous les ans, je prévois d'aller à fosdem, le meeting de logiciel libres. J'y vais bien sûr avec la double casquette Xulfr/Mozilla-europe, pour assister aux confs Mozilla et tenir le stand Mozilla.
  • J'ai corrigé pas mal de bug dans Jelix 1.0 beta 1. J'hésite alors à sortir Jelix 1.0 beta 1.1. Mais ça fait un peu lourd comme intitulé :-). Je me demande si je n'aurais finalement pas dû utiliser la notation 0.1, 0.2, 0.3 etc, bien que je n'aime pas trop.
  • Le week-end dernier, presque 4 mois aprés la 3.0 RC1 (manque de temps :-)), j'ai sorti la version 3.0 finale de Wikirenderer, ma classe php de transformation de texte wiki en ce-que-vous-voulez, avec quelques bugs corrigés en plus.
  • On a commencé le développement d'un dépôt/catalogue de composants (xbl, javascript, xpcom..) pour le site xulfr.org. Y aura peut être même finalement pour chaque projet, un dépôt subversion + trac, puisqu'un gentil contributeur a fait des scripts d'administration de tous ça, dans le cadre de la forge pour Jelix (eh oui, on prévoit une forge de module pour jelix ;-) ). Je compte bien mutualiser les devs sur les deux sites.
  • Bon, mais, problème toutefois : mon enveloppe charnelle m'a bien fait comprendre, mardi, qu'elle n'avait plus 20 ans, et qu'en gros, il fallait que j'arrête absolument de coder jusqu'à pas d'heure tous les soirs. Donc dorénavant, je vais faire des vraies nuits, ce qui aura pour conséquence un ralentissement de tous mes projets persos. C'est trop injuste :-/.

Je me dis parfois qu'un jour il faudra que j'arrête d'avoir cette vie de fou. Je m'en suis rendu compte il y a quelques années, après les quelques mois passés en Polynésie. La vie en région parisienne est aliénante, complètement folle, voire débile. Je passerais bien à nouveau quelques mois sous les tropiques, à me laisser vivre, à vivre tout simplement. Encore faut-il en avoir la possibilité...

lundi, décembre 11 2006

Gecko 1.9a1, Acid2, SVG &amp;cie

Un première version alpha de Firefox 3 est sorti. Elle est basé sur un nouveau moteur Gecko 1.9a1 qui contient un certain nombre de nouveauté :

  • refonte d'une partie du moteur de layout, par David Baron (2 ans de boulot !). Cette refonte, comme je l'avais déjà écrit, permet à cette version alpha de passer le test acid2, et d'améliorer les performances d'affichage. Elle va aussi permettre de corriger d'autres bugs plus facilement, comme l'implémentation de la propriété CSS display: inline-block ou display: inline-table. Mise à jour : il y a eu confusion de ma part. les modifications de cette refonte ont été incluse le même jour de la sortie de la alpha1, mais après la diffusion des binaires de la alpha1. Cette version officielle ne passe donc pas le test acid2.
  • une amélioration de la prise en charge de SVG : plus rapide, plus de filtres, impression de meilleure qualité, plus de fonctions DOM surtout pour les textes etc..
  • Le moteur de rendu repose maintenant entièrement sur la bibliothèque Cairo (jusqu'à maintenant, seul SVG et la balise canvas utilisaient Cairo)

Pendant ce temps là, Alex Fritze (Monsieur SVG/XTF dans Gecko ), nous fait du teasing sur Venice Project, projet qui semble combiner les technologies de Mozilla, avec des fonctionnalités multimédia (vidéo, SIP etc..)

mercredi, décembre 6 2006

Adilla : svg and flash

On thewpfblog.com, Lee has made "Microbe", a little flash app which drive a WPF/E app : a ball travels between the two app. In fact, this is simple : the flash app call a javascript function of the html page, by giving the coordinate of the ball. And this function change the coordinate of the ball in the WPF/E area.

I made the same thing, replacing the WPF/E with a little piece of SVG : Adilla (require Flash 9 and Firefox 1.5/2.0).


Sur thewpfblog.com, Lee a réalisé "Microbe", une appli flash qui pilote une appli WPF/E[1] : une balle passe de la zone flash à la zone WPF/E. En fait, c'est simple : le flash ne fait qu'appeler une fonction javascript de la page, en lui passant les coordonnées x et y. Laquelle fonction modifie les coordonnées de la balle dans le WPF/E.

Trouvant ça rigolo, j'ai fait la même chose, en remplaçant le WPF/E par 4 simples balises SVG : Adilla [2](nécessite Flash 9 sous linux, et Firefox 1.5/2.0).

Notes

[1] WPF/E est le plugin de Microsoft pour executer du XAML dans un navigateur, j'en parlais il y a un an.

[2] Sur le même modèle que Microbe, Adilla = Adobe + Mozilla... Mise à jour : j'ai changé de nom, ça fait moins bizarre que dans l'autre sens, "Mozobe" ;-)

mardi, août 9 2005

MozMapEditor

Paul Rouget, de l'équipe de xulfr.org, vient de publier sur son blog les premières captures d'écran de MozMap Editor, un nouveau logiciel qu'il est en train de réaliser avec René-Luc D'Hont.

C'est un logiciel de cartographie, utilisant les toutes dernières technologies Mozilla (qui sont toujours en développement ;-) ) : xulrunner pour lancer l'application et SVG pour l'affichage des cartes. Et bien sûr ils utilisent le traditionnel XUL et XBL pour l'interface utilisateur, et javascript pour les fonctionnalités. Mais pas de composant C++.

Je suis impatient de voir ce que ça donne en vrai. Vivement la création de leur page projet sur Mozdev !