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

Mot-clé - firefox

Fil des billets - Fil des commentaires

jeudi, octobre 14 2010

Le moteur Javascript de Firefox rattrape son retard

Connaissez-vous http://arewefastyet.com/ ? C'est un site mis en place par l'équipe des développeurs du moteur javascript de Mozilla, SpiderMonkey. Il permet de suivre l'évolution des performances de ce moteur, en exécutant deux tests : sunspider et v8bench.

Il y a quelques jours, SpiderMonkey avait dépassé Apple Nitro (le moteur js de webkit) sur v8bench. Depuis hier, il est sur le point de le dépasser sur sunspider ! Il reste maintenant à battre le moteur de Google, V8. (Ce sont les versions de développement de ces moteurs javascripts qui sont testés)

Arewefastyet ? v8bench 20101013 arewefastyet ? sunspider 20101013

Légende: courbe violette : spidermonkey (Tracemonkey + JaëgerMonkey); courbe rouge : apple nitro. courbe verte : google v8. courbe noire : spidermonkey (JaëgerMonkey seul)

À noter que ces résultats sont obtenus en lançant les tests non pas dans un navigateur, mais avec les versions "autonomes" des moteurs javascripts (hors navigateur donc). On a donc ici des performances pures, qui ne sont pas impactées par d'autres choses comme un moteur de rendu ou des scripts d'autres sites etc. Il est évident donc que vous n'obtiendrez pas des résultats comparatifs du même ordre, en les lançant dans un navigateur.

C'est ainsi que ce n'est pas encore parfait du coté Mozilla, puisqu'on obtient encore des écarts en lançant ces tests avec Firefox. Probablement que les tests dans Firefox sont biaisés à cause de l'exécution de code JS en dehors de la page de tests, puisque l'interface de Firefox est développée en partie en javascript.

Cependant, les améliorations entre Firefox 3.6 et Firefox 4 sont énormes, et les performances des moteurs javascripts des principaux navigateurs (IE9, Chrome, Safari et Firefox 4) sont maintenant équivalentes. On arrive à des différences qui ne seront pas perceptibles par l'utilisateur.

Je pense que d'ici quelques mois, on aura atteint les limites sur les améliorations dans les moteurs javascript.

la bataille des navigateurs va pouvoir aller se focaliser sur d'autres sujets :-) (accélération matériel etc..)

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

mardi, février 2 2010

La puissance de HTML5 dans vos applis web

Paul Rouget vient de sortir une nouvelle démo montrant les possibilités techniques de Firefox pour les développeurs web. Ici cependant, c'est plus qu'une démo, c'est une véritable petite application concrète.

Il s'agit d'un outil, qui permet d'envoyer des images sur twitpic et comportant un éditeur d'image. Vous sélectionnez les images que vous voulez envoyer, vous les retouchez éventuellement, et vous les envoyez. Visualisez la video, c'est carrément génial, d'un point de vue technique. C'est du jamais vu dans une application web HTML (je ne parle pas d'applet java ou flash, souvent lourdes et peu ergonomiques).

demo_editeur_twitpic.png

Coté technique donc, voici ce qui est utilisé :

  • HTML5 Canvas: on ne présente plus l'élement <canvas>, qui permet d'avoir une zone dans la page web où l'on peut "dessiner" programmativement. Les images que l'on a glisser dans l'application sont "injectées" dans un canvas. Cela permet alors de les modifier, de proposer à l'utilisateur une mini application de retouche, avec des fonctions de découpage, de décoration, de mirroir etc. Avec Canvas, on peut aller très très loin. Voir par exemple cet outil, sketchpad, un paint-like bien plus beau que l'original :-)
  • HTML5 Drag and Drop: Paul utilise les évènements drag-and-drop, pour permettre, d'une part, de glisser des fichiers de votre bureau ou explorateur de fichiers vers l'application, mais aussi de glisser les images à l'intérieur de l'application entre les différentes fonctionnalités (glisser une image précédemment sélectionnée vers la poubelle par exemple).
  • File API : permet dans l'application d'avoir des informations sur les fichiers, à partir de ce qui est indiqué dans un <input type="file"> ou un évènement drag and drop qui concerne un fichier. Ça permet à l'application de réagir ensuite en fonction du type du fichier, de sa taille etc..
  • HTML5 localStorage: localStorage est un objet javascript qui permet de stocker ce que l'on veut, durablement, coté client. Il est utilisé ici pour stocker les images sélectionnées, en attendant de les envoyer vers twitpic. L'image, affichée en fait via un canvas (ce qui permet de la modifier), est en fait transformée en data URL. Cette URL est alors stockée dans localeStorage.
  • HTML5 Application Cache : toute la machinerie permettant de continuer à faire fonctionner l'application même en étant déconnecté, est utilisée. En particulier, un manifest "offline" est utilisé pour indiquer les fichiers de ressources (js, css) à stocker durablement dans le cache du navigateur, de manière à pouvoir recharger l'application, même en étant déconnecté. En fait, c'est comme si l'application était stockée en local. De plus, les évènements offline et online sont écoutés, pour pouvoir autoriser ou non la publication des images.
  • Cross Site xmlHTTPRequest, un mécanisme http permettant d'autoriser ou non à une application web (ici la demo) de communiquer avec une autre application web (ici twitpic).

Toutes ces technologies, dorénavant présente dans Firefox 3.6 et déjà plus ou moins dans d'autres navigateurs (je n'ai pas vérifié, ça ne va pas tarder en tout cas), offrent de bien belles perspectives en matières d'applications web puissantes et agréables à utiliser. À quand de telles fonctionnalités dans mon outil de blog préféré, pour faciliter l'insertion et la retouche de nouvelles images dans un billet sans ouvrir de lourdes applications graphiques desktop ? ;-)

Cerise sur le gâteau : cette application fonctionne parfaitement dans la version mobile de Firefox, qui est sortie hier pour Maemo :-)

mercredi, octobre 14 2009

L'utilité de l'API de l'accéléromètre dans les navigateurs

Paul Rouget nous a fait de jolies demos (que vous pouvez voir en vidéo sur hacks.mozilla.org), pour montrer ce qu'on peut faire avec la nouvelle API qui permet de profiter de l'accéléromètre embarqué dans votre laptop ou tablette.

Les réactions n'ont pas tardé un peu partout sur le web, et en gros, j'en ai retiré 3 différentes :

  • "vous feriez mieux de travailler sur autre chose"
  • "c'est inutile, ça sert à rien"
  • "c'est génial !"

Pour le "vous feriez mieux de travailler sur autre chose", on va passer vite fait, c'est du pur troll. Il y a plusieurs dizaines de développeurs qui bossent à temps plein sur Firefox, et il est évident que chacun bosse sur des sujets différents. Le support de l'accéléromètre a été fait par un seul gars, pas 250. Bref, ce n'est pas une perte de temps.

Les deux autres remarques sont plus intéressantes. Et en analysant (à l'arrache) les réactions, j'ai remarqué qu'en fait la première semblait être faite principalement par des non-développeurs, et la deuxième par des développeurs.

En fait, beaucoup de gens, en voyant une des démos qui montre une page web s'orienter ou se tordre en fonction de l'orientation du laptop, n'ont pas vu l'intérêt technique de la chose. Ils ont regardé la démo "au premier degré" pourrait-on dire. Il y en a qui ont cru comprendre que dans les prochaines versions de Firefox, les pages web s'orienteront en fonction de l'orientation du laptop. Du coup, ils disent que ça ne sert à rien, qu'ils ne bougent de toute façon pas leur laptop, ou encore que c'est une horreur, parce que quand une image s'affichera dans le mauvais sens, ils ne pourront plus basculer leur laptop pour voir l'image dans le bon sens, etc...

Et en fait, ce n'est pas du tout ça, et effectivement, la démo est peut être mal choisie au final. Car en fait, l'intérêt de la démo se trouve sous le capot, dans le code source de la page, pour montrer avec quelle facilité on peut utiliser l'accéléromètre. C'est pourquoi la plupart qui ont trouvé cette démo géniale sont je pense des développeurs, ils ont regardé le source de la page.

Il faut donc juste comprendre que Mozilla a mis à disposition un outil, pour les développeurs web. Et il est tellement nouveau que des usages concrets de cet outils restent à inventer. On sait que l'une des premières utilités est pour les jeux, sur Fennec, la version mobile de Firefox, ou pour la version desktop sur les tablettes, comme on peut voir dans les jeux pour IPhone. Pour d'autres utilités, surtout sur le desktop, nul doute que des développeurs vont en trouver ! C'était pareil pour <canvas>, <video>, l'api de géolocalisation etc.. On ne voit pas toujours l'intérêt d'une nouvelle techno quand elle débarque. Mais au final, des usages sont inventés, créés.

Ça me rappelle d'ailleurs la conférence de Paul et Tristan à Paris Web, durant laquelle Paul fait plein de démos sur des nouvelles technos présentes ou à venir dans Firefox, et ajoutant à un moment donné, "j'ai pas dit que ça servait à quelque chose", suivi d'un grand rire dans la salle. Oui, au visionnage des démos (genre une vidéo de Tristan Nitot tournant en rond), un utilisateur lambda, voire un développeur web, peut effectivement se demander l'intérêt de tel ou tel truc. Mais en y réfléchissant, ou quand il sera confronté à un besoin précis, peut être bien qu'il en trouvera.

Si d'ailleurs vous avez des idées de l'utilité de l'accéléromètre dans une appli web, signalez les à Paul ou ici dans les commentaires, cela lui permettra de faire des démos "plus utiles" du point de vue de l'utilisateur :-)

mardi, septembre 22 2009

De la 3D dans Firefox

L'extension canvas 3D permet depuis 2 ans, d'utiliser l'element <canvas> pour faire de la 3D, en profitant de l'accélération matériel apportée par openGL.

S'en est suivi la naissance d'un groupe de travail en mars dernier, au Khronos Group, pour normaliser une API, appelée communément WebGL, dérivée d'OpenGL ES 2.0, qui sera adaptée aux application web. Mozilla et d'autres éditeurs participent à ce groupe.

En juin dernier, le code de l'extension Canvas 3D a été intégré dans le trunk de Mozilla, et ce n'est que depuis quelques jours que ce code a été activé par défaut dans les compilations nocturnes de Firefox (en l'occurence, cela sera disponible pour Firefox 3.7, il est trop tard pour Firefox 3.6 qui sortira d'ici la fin de l'année). Il y a eu aussi des changements dans l'API du contexte 3D de l'élement <canvas>, afin de coller au plus près aux derniers brouillons de WebGL.

Nous voilà donc avec des nightlies de Firefox permettant de faire de la 3D. Le développeur de canvas 3D, Vlad Vukićević, vient de publier une démo, qui permet de visualiser une creature en 3D.

J'ai fait un screencast de la demo executée avec une nightly de Firefox (fichier Ogg/Theora, et désolé, pas d'utilisation de la balise video dans ce billet, impossible de l'utiliser avec dotclear ! grrrrrr)

Mise à jour : deux nouvelles démos ! À voir ici et .

jeudi, juillet 2 2009

Theora, après Firefox et Chrome : Opera

Après Firefox et Chrome, Philip Jägenstedt, un développeur du navigateur Opera annonce que ce dernier embarquera en natif le support pour Ogg Vorbis/Theora. Un autre développeur d'Opera, Anne Van Kesteren, apporte des précisions sur ce choix en expliquant qu'embarquer H264 n'est pas très bon pour le web, et que le web a besoin de format ouvert, libre d'utilisation (sans avoir à payer des royalties), et libre de tout brevet logiciel. Theora est donc le format idéal pour diffuser de la vidéo sur le web.

Beaucoup de développeurs et d'utilisateurs préfèrent cependant H264, sous prétexte que les fichiers sont moins gros, et la qualité meilleure qu'avec Theora. Ils ne savent pas cependant (ou ne veulent pas savoir parfois) que Theora n'est pas si mauvais que ça, et que les encoders pour ce format s'améliorent !

Ainsi, la 1.1 alpha 2 de l'encoder 'Thusnelda' réalisé par la fondation Xiph vient de sortir. Sans changer le format Theora, il permet de produire des vidéos de meilleure qualité, et des fichiers moins gros. (voir ce comparatif sur ce blog). Bien entendu, la prochaine version de Firefox utilisera cette future version de la libtheora, si elle est prête à temps.

Ogg Theora vaincra ! :-)

mardi, juin 30 2009

Sorties majeures aujourd'hui

D'abord celle de Firefox 3.5. Et puis celle de PHP 5.3. Ils apportent chacun leur gros lot de nouveautés.

Notez les chiffres des versions de ces deux logiciels :-)

Sans oublier TwitFactory, la nouvelle appli de Daniel.

dimanche, juin 28 2009

De la 3D dans Firefox

Énorme ! Le coeur du code de l'extension qui apporte un contexte 3D dans la balise <canvas> vient d'être intégré dans le trunk de Mozilla. Dans une version future de Firefox, on pourra donc faire de l'affichage 3D via cette balise, avec semble-t-il une API proche d'openGL.

Voir la news sur xulfr.

vendredi, juin 26 2009

Chantiers: XBL2 et multi processes

Je l'avais déjà annoncé sur xulfr le mois dernier, le développement du support des multi-processeurs dans Gecko a démarré. Ce projet a même un nom maintenant : Electrolysis.

Benjamin Smedberg avait annoncé le projet "officiellement" il y a 10 jours, et peu de temps après, Chris Jones publiait une vidéo d'une première expérience, avec une simple fenêtre XUL dans lequel le contenu HTML était affiché via un processus différent.

Pour la petite anecdote, ils ont repris la bibliothèque de communication inter-processus de Chromium. Vive l'open source :-).

Autre bonne nouvelle, le développement de l'implémentation du langage XBL2 va bientôt démarrer, dixit Jonas Sicking, le développeur qui va s'en occuper. Pour en savoir plus sur XBL2, voir mon billet précédent sur ce sujet et les slides de la conférence sur XBL2 que j'avais donné à ParisWeb 2007.

J'aime bien ses périodes de release de Firefox, les développeurs n'ont plus trop de bugs à corriger pour la version qui sort, et du coup plus de temps pour développer des nouveaux trucs.

mardi, juin 23 2009

Pas de support DirectShow et Quicktime dans Firefox

À l'origine, dans le cadre de la balise video, il était prévu d'intégrer le support de DirectShow et de Quicktime dans Firefox, pour ses versions respectives sous windows et mac, en plus du support natif du format OGG/Theora. Finalement, cela ne se fera pas, comme l'explique Robert O'Callahan l'un des core-developer de Mozilla. Voici en gros les raisons :

  • Mozilla veut se concentrer sur la promotion des formats ouverts comme OGG/Theora
  • Apparemment, peu d'utilisateurs ont les codecs installés pour H264, par défaut, il n'y a que des codecs pour des "vieux" formats (sauf dans Windows 7 qui fournira un codec H264 en standard)
  • DirectShow est sous-spécifié, contient des bugs, et les codecs disponibles pour DirectShow sont de qualités très inégales, et ne fournissent pas tous tout ce qu'il faut pour que l'API de la balise video fonctionne correctement. C'est à dire, qu'avec certains codec, des scripts dans les pages web ne pourraient pas fonctionner, et l'auteur de la page web ne pourrait rien y faire. Déjà que la compatibilité cross-browser est un cauchemar, alors si il faut aussi se préoccuper des problèmes cross-codec...
  • Vu la qualité inégale des codecs, cela veut dire bugs potentiels, que les utilisateurs attribueraient à tord à Firefox. Les développeurs de Firefox ont assez de problèmes à régler comme ça
  • Il y a des codecs "malware"
  • Il y a des codecs avec des trous de sécurité, que Firefox ne pourrait pas "contrôler"
  • Deux backends en plus, c'est du boulot en plus, de la maintenance en plus etc.
  • Mozilla ne peut fournir des codecs par défauts avec le support Quicktime ou DirectShow (pour H264 notamment), à cause des royalties qu'il faudrait payer, et des problèmes de brevet.

Bref, dans Firefox, il n'y aura que le support natif de OGG/Theora (et OGG/Vorbis), ainsi que la backend GStreamer (au moins pour la version mobile, il n'est pas encore sûr qu'il le soit dans la version desktop).

lundi, juin 22 2009

Passage à Firefox 3.5RC

Ça y est, je viens de basculer définitivement de Firefox 3.0 à Firefox 3.5 (la release candidate). Malheureusement, j'ai encore la moitié des extensions qui ne sont pas compatibles, dont celle que je me sers pour lire mes flux RSS...

Vivement les extensions dans jetpack !

mercredi, juin 17 2009

Des articles intéressants sur hacks.mozilla.org

Zut, j'ai oublié de vous signaler la publication de ma démo sur hacks.mozilla.org, que je vous avez promis. Je ne suis plus au point en matière de teasing, vous avez connu mieux sur ce blog, n'est-ce pas ? :-)

Donc voilà ma démo, à tester avec Firefox 3.5b99 au moins. Si des développeurs spécialisés sur Webkit (Riiiiik !), Opera ou Konqueror, pouvaient jeter un coup d'oeil voir si je peux améliorer ça pour leur navigateur préféré respectif... (Ouai, je m'y prend un peu tard, mais là, je n'ai plus la tête hors de l'eau, tellement ma todo list est lourde, et j'ai un tuba pour éviter de me noyer).

Bon sinon, sur hacks.mozilla.org, il y a des articles que j'ai vraiment aimé jusqu'ici, et finalement bien plus impressionnant que ma petite démo, et que je veux vous faire partager (pour ceux qui ne suivent pas hacks.m.o) :

Et puis il y a aussi ce débat (ici et ) sur la qualité de Theora par rapport à ce qu'on peut avoir dans YouTube par ex. Conclusion, Theora, c'est bon, mangez-en !

Et ce n'est pas fini, mon petit doigt me dit qu'il va y avoir encore de belle demo sur les nouvelles technologies web :-)

mardi, juin 9 2009

Les nouveautés de Firefox 3.5 en 35 jours

Mozilla vient d'ouvrir un site, hacks.mozilla.org. Pendant 35 jours, nous allons vous montrer les nouvelles possibilités du moteur de Firefox, tant en terme d'API javascript, qu'en terme de support de HTML5 et de CSS3. J'ai réalisé une démo qui sera publié sur ce site. Ce sera une démo sur CSS, qui utilisera des fontes téléchargeables (propriété font-face), les ombrages sur les textes (text-shadow) et les boites (box-shadow), accompagné d'une pincé de bords arrondis (border-radius).

Stay tuned !

Mise à jour: comme promis...

jeudi, mai 28 2009

La balise <video> chez Dailymotion

L'adoption du format Ogg Theora fait son chemin : DailyMotion viennent d'annoncer sur leur blog (et via un communiqué de presse) qu'ils vont prendre en charge la balise <video> de HTML5, en particulier avec Firefox 3.5 qui sortira dans quelques jours en RC.

Ils ont ouvert un site en test diffusant les vidéos au format Ogg Theora, openvideo.dailymotion.com à visiter avec Firefox 3.5. Ils ont également fait une page de démonstration montrant les possibilités de l'utilisation de la balise <video>, conjointement avec les autres technologies web comme javascript, css, svg etc...

Qu'un site majeur dans la diffusion de vidéos sur Internet utilise ces technologies, promet un bel avenir à Theora. Bien que les encodeurs actuels pour Theora soient de moins bonne qualité que pour le H264 par exemple, un travail est en cours (sponsorisé notamment par Mozilla), pour les améliorer, tant au niveau de la qualité de l'image, que la taille des fichiers. Voir par exemple une de ces améliorations faite au début du mois.

Pour rappel, Ogg Theora est un format libre et ouvert pour stocker de la vidéo. Pour en savoir plus sur la balise <video>, vous pouvez lire un de mes billets précédents sur le sujet.

Go Theora ! Go !

vendredi, avril 24 2009

Quand une nouveauté CSS en chasse une autre...

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 :

toolbar dans Firefox 3.0 sur MacOSX

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:

toolbar dans Firefox 3.1 beta 3 sur MacOSX

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 :

images pour réaliser une toolbar dans Firefox

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

toolbar dans Firefox 3.6a1 sur MacOSX

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.

Notes

[1] ou plutôt -moz-border-radius, cette propriété n'étant pas encore un standard dans CSS3, Mozilla l'a préfixé avec -moz- comme le permet la spécification CSS, tout comme box-shadow

[2] pas sûr que le patch sera intégré dans Firefox 3.5

jeudi, avril 23 2009

Interface de la balise video dans Firefox

Depuis quelques heures, des améliorations sur l'interface utilisateur de la balise video ont été incluses dans le trunk et pour la prochaine beta de Firefox (cliquez sur l'image pour la voir en taille réèlle)

capture de l'interface de la balise video dans Firefox 3.5b4pre

Les améliorations en questions :

  • réglette pour choisir le volume sonore (tout à droite)
  • affichage du temps total de la vidéo
  • affichage du temps écoulé, dans la petite bulle au dessus de la barre de progression, petite bulle qui sert également à aller directement à l'endroit voulu dans le film en la déplaçant.
  • affichage de la progression du téléchargement dans la barre de progression de lecture (je ne sais plus si ça n'y était pas déjà dans la beta précédente)

Bref, on commence à avoir une interface par défaut plutôt complète. Notez que cette interface n'apparaît que si la souris est au dessus de l'élément <video>, et seulement si l'attribut controls est présent.

Ce qui est interressant à savoir, c'est la façon dont cette barre de contrôle est implémentée dans Firefox. En fait, ce n'est pas le code de la balise vidéo qui effectue directement cet affichage, mais un simple composant XBL qui est attaché à cet élément.

Pour rappel, XBL est un langage XML (en cours de normalisation au W3C) qui permet de définir le contenu d'un élément en indiquant les éléments fils (anonymes) à ajouter, ainsi que son comportement, c'est à dire un ensemble de méthodes javascript pour son API, et également des fonctions appelées sur des événements DOM (sur le click etc). Dans un fichier XBL, on peut ainsi définir plusieurs éléments.

Comme on peut le voir dans ce fichier XBL de l'élément video, les contrôles sont en fait des éléments XUL. Et sur les click et autre de ces élements XUL, le code javascript appel l'API native de l'élément video.

Le design est déclaré via une feuille CSS. Dans la feuille de style dédiée, on peut voir que tout est quasiment fait en CSS, que ce soit les arrondis, les couleurs, les opacités etc. Les seules images utilisées concernent juste les symboles play/pause, le dessin du haut parleur, et la bulle du temps écoulé.

Bref, on utilise des technos du web pour implémenter en partie... des technos du web :-)

Mais ce n'est pas tout !

Cette interface par défaut ne vous plaît pas ? Faites une extension qui propose un nouveau XBL en remplacement de l'original ! Ou une autre feuille de style CSS ! Où les deux !

Aaah, c'est beau les technos Mozilla, n'est-ce pas ? :-)

dimanche, février 1 2009

Relativisons les resultats du test acid3

Frédéric Bezies a fait remarquer que Netscape 7.0.1 (vieux de 6 ans) a un meilleur score au test acid3 par rapport à IE8 RC1.

On peut trouver ça dommage et se moquer de IE8, mais il faut quand même relativiser.

Lire la suite...

vendredi, décembre 5 2008

Firefox dépasse les 50% dans certains pays

Selon Net Application, en novembre Firefox a dépassé les 20% de part de marché au niveau mondial, et même les 50% dans au moins 3 pays : Indonésie, Macédoine et Solvenie. Le navigateur est aussi en passe de franchir cette barre de 50% dans d'autres pays : Pologne, Bosnie-Herzégovine, Slovaquie, Finlande et Philippines.

Voir les détails sur ce billet de Ken.

jeudi, octobre 16 2008

L'élement video

Il y a plus d'un an, j'avais publié un billet sur l'élément <video>. Les choses ont un peu évolué, les implémentations et les interrogations aussi. Voici donc un récapitulatif des avantages de cet élément sur l'élément <object>, ainsi que quelques démonstrations. On peut espérer que la balise object ne sera plus trop utilisée pour insérer de la vidéo : l'élément <video> est déjà présent dans Safari 3.1, dans des versions expérimentales d'Opéra, et la version beta1 de Firefox 3.1 qui vient de sortir.

Lire la suite...

lundi, septembre 15 2008

Transformations en CSS3

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...

- page 1 de 7