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

Technologies Web

Articles, tutos, actualité sur les technologies du web

Fil des billets - Fil des commentaires

jeudi, juin 24 2010

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

Par Laurentj le jeudi, juin 24 2010, 11:42

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 ?

8 commentaires

IE9 a quasi rattrapé son retard

Par Laurentj le jeudi, juin 24 2010, 10:39

La troisième preview de IE9 est sortie. J'avoue être plutôt impressionné par toutes les améliorations qu'ils ont encore apporté. IE9, une fois que la version finale sera sortie, sera vraiment dans la cour des grands et aura rattrapé tout son retard technologiquement parlant.

Une partie des questions que je me posais il y a quelques mois ont maintenant une réponse : c'est implémenté.

  • Support de SVG (en partie)
  • éléments HTML5 <video>, <audio>, <canvas>,
  • support DOM largement amélioré: DOM traversal, DOM level3 core, DOM level3 events,
  • fontes téléchargeable WOFF, support complet CSS 2.1, support des media queries CSS3, selecteurs CSS3, bordures CSS3, background CSS3
  • un moteur javascript complet et aussi rapide que celui des autres navigateurs (je ne tiens pas compte des pouillèmes de milli secondes de différences entre chacun, à ce niveau, ce n'est plus tellement significatif)

Bref, tout plein de choses à se mettre sous la dent, avec un score acid3 qui grimpe à 83[1]. Sans parler d'un support très avancé de l'accélération graphique matérielle.

Il lui manque toutefois encore des technologies qu'ont déjà les concurrents, comme :

  • les WebWorkers
  • les WebSockets
  • formulaires HTML5, HTML5 File API, et autres éléments de sections HTML5 probablement
  • transitions CSS3, transformations CSS3, animations CSS3, gradients,
  • WebGL
  • SMIL
  • Évènements DOM multi touch, support accéléromètre, support géolocalisation
  • base IndexedDb
  • API Drag and drop (à vérifier)

Et j'en oublie certainement[2]. Ils ont donc encore du chemin à rattraper, et je ne doute pas que certaines de ces technos seront implémentés dans la version finale de IE9. Pour moi, on pourra qualifier IE9 de navigateur moderne. Car une chose est sûre, les développeurs web auront déjà suffisamment de technologies pour faire des sites modernes qui soient compatibles avec la majorité des navigateurs.

Le rouleau compresseur Microsoft a mis du temps à se mettre en route. Il est maintenant en marche, et pas qu'un peu. Mozilla, Apple, et Google ne devront pas s'endormir sur leurs lauriers. Cette nouvelle guerre de navigateurs initiée par Mozilla devient vraiment intéressante.

Notes

[1] Même si, comme je l'ai déjà dit, ce test n'est pas vraiment significatif

[2] je me suis en partie basé sur la liste des fonctionnalités qui sont implémentés dans Firefox 3.6 ou 4

10 commentaires

mercredi, mai 19 2010

WebM, le nouveau format video du web

Par Laurentj le mercredi, mai 19 2010, 22:07

Le petit monde des formats videos, et le web sont en pleine ébullition, avec l'annonce du nouveau format WebM. Mais avant de voir ce que nous promet WebM, faisons d'abord un petit retour en arrière dans l'histoire des codecs pour la balise video de HTML5.

Lire la suite...

17 commentaires

jeudi, février 11 2010

Faire du drag and drop avec flash en utilisant canvas

Par Laurentj le jeudi, février 11 2010, 15:18

À Zoomorama, Flash nous rend bien service. De par ses performances au niveau rendu, il nous permet de développer notre navigateur de documents zoomable, notre "ZoomViewer", que l'on peut intégrer dans une page web. Seul souci avec Flash : il ne connait pas le drag and drop.

Lire la suite...

4 commentaires

mardi, février 2 2010

La puissance de HTML5 dans vos applis web

Par Laurentj le mardi, février 2 2010, 20:21

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

7 commentaires

vendredi, novembre 13 2009

Javascript coté serveur

Par Laurentj le vendredi, novembre 13 2009, 06:39

Ça commence à faire pas mal d'année que je fais du javascript, non seulement pour le web, mais aussi dans les applications XUL. Ce qu'il y a d'intéressant à utiliser Javascript avec le XUL, c'est qu'on peut se lâcher, et utiliser tout le potentiel du javascript de la plateforme Mozilla, comme les générateurs et iterateurs, les propriétés et méthodes avancées sur les objets de base (comme sur Array). Même si je ne suis pas fan de certaines constructions syntaxiques[1].

Et depuis quelques jours j'ai une lubie : pourquoi ne pas utiliser javascript coté serveur, en remplacement de PHP par exemple ?

Et j'ai découvert sur wikipedia qu'il existait quelques dizaines de projets de générateurs de pages web à base de javascript. La majorité de ces projets reposent sur les moteurs JS de Mozilla :

  • SpiderMonkey, le moteur (en C) utilisé dans Firefox 3/Gecko 1.9.0 et précédent
  • Rhino, un moteur en java

Ceux à base de SpiderMonkey m'intéresse plus particulièrement. Je ne les ai pas encore tous regardé, mais jslibs semble sympa, dans la mesure où la dernière version ne repose plus sur SpiderMonkey, mais sur TraceMonkey, le moteur JS accéléré de Firefox 3.5.

Pour faire le choix d'un de ces projets, il va falloir regarder de plus près les API proposées. En effet, il faut savoir qu'un moteur JS ne fait qu'exécuter du code, et ne contient nativement que quelques objets primitifs comme String, Array, Date, Math... C'est au code embarquant de "brancher" des bibliothèques ou fonctions C sur des objets JS (faire des wrappers donc), pour enrichir l'API utilisable dans le code JS. Ce que fait d'ailleurs un navigateur, pour les objets window, document, les objets DOM etc.

Reste aussi à faire quelques benchmarks, pour voir si ça vaut vraiment le coup par rapport à PHP, Python ou autre..

Notes

[1] disons que depuis la publication de ce billet, j'ai un avis moins tranché :-) On s'y fait

15 commentaires

mardi, novembre 10 2009

Et le meilleur moteur javascript est....

Par Laurentj le mardi, novembre 10 2009, 18:01

On voit circuler ces slides sur des astuces pour les perfs en javascript, et on y voit notamment que les résultats de Firefox par rapport aux autres moteurs, notamment V8, ne sont pas folichons.

Cependant, comme beaucoup de benchmarks, ces résultats sont sujets à cautions, d'autant plus qu'ici :

  1. On ne sait absolument quelles versions de chaque moteur sont mises en comparaison
  2. Comparer SpiderMonkey, moteur d'ancienne génération (Firefox 3.0 et précédent), à V8, ce n'est vraiment pas "fair play". Il aurait pu prendre au moins TraceMonkey (Firefox 3.5). À moins qu'il confond dans les noms, mais ça m'étonnerai, car pour les quelques tests que j'ai effectué avec son script, les résultats de TraceMonkey sont plus proches de V8 que de IE (dernières versions stables des navigateurs).

Et puis bien sûr, aucune mention d'Opera.

Enfin, c'est bien beau d'avoir un moteur rapide, encore faut il qu'il soit en conformité avec la spécification Ecmascript. Ce qui est encore loin d'être le cas pour certains d'entre eux.

2 commentaires

vendredi, octobre 16 2009

Transitions CSS

Par Laurentj le vendredi, octobre 16 2009, 13:24

La version de développement du futur Firefox 3.7 implémente depuis quelques jours les transitions CSS. Vous avez peut être pu le voir, en lisant Paul qui a parlé discrètement sur son blog, en même temps que la nouvelle implémentation de l'API de l'accéléromètre. Vous pouvez voir une démo de Paul avec les transitions CSS.

Le principe est assez simple:

  • avec la propriété transition-property, vous indiquez les propriétés CSS qui seront concernées par la transition, c'est à dire, quand leur valeur changera, il y aura une transition entre l'ancienne valeur vers la nouvelle valeur, le changement ne sera donc pas immédiat.
  • transition-duration permet d'indiquer la durée de la transition, pour chacune des propriétés
  • transition-timing-function, indique la fonction de transition, c'est à dire la manière dont la transition sera faite. Par exemple la fonction ease-in-out fait une transition rapide au début, lente au "milieu", et rapide à la fin. On a ainsi des fonctions pour faire des effets élastiques, smooth etc..
  • transition-delay pour indiquer à partir de combien de temps la transition doit être faite, à partir du moment où la valeur est changée.
  • transition pour indiquer tout ça en une seule instruction.

Voir la spécification complète sur le site du W3C (spécification qui est encore un brouillon).

Un exemple :

  .mydiv {
     width: 100px;
     transition: width 1s linear;
  }

 .mydiv:hover {
    width:200px;
 }

Quand on passera la souris au dessus de l'élément, sa largeur changera à 200px. Avec la propriété transition, ce changement ne sera pas immédiat. La largeur passera de 100px à 200px en 1 seconde, de manière linéaire. Bien sûr, ce changement de valeur peut être fait via javascript plutôt que sur un :hover, par exemple: document.querySelector(".mydiv").style.width="200px";.

Le gros intérêt de ces propriétés CSS, c'est que ça va rendre obsolète beaucoup de fonctions d'animations que l'on retrouve dans beaucoup de frameworks javascript (jquery, mootools...). Ça permettra des pages plus légères (les frameworks seront moins lourds à terme) et plus rapide.

C'est donc implémenté dans webkit (donc dans Safari, et Chrome je crois), et dans une future version de Firefox, en utilisant bien entendu les prefixes -webkit- et -moz- sur les propriétés pour que ça fonctionne.

Et, comme je l'avais déjà dis il y a quelques mois dans un billet sur notre technologie à Zoomorama, c'est aussi implémenté dans notre browser (développé en actionscript 3). J'ai mis en ligne deux démos faites par David Marteau, et c'est utilisable dés maintenant dans vos fichiers ZML :-)

5 commentaires un rétrolien

mercredi, octobre 14 2009

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

Par Laurentj le mercredi, octobre 14 2009, 14:59

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

11 commentaires

jeudi, octobre 8 2009

PHP n'est pas un bon langage de template

Par Laurentj le jeudi, octobre 8 2009, 12:39

Ça me fait plaisir de lire ce genre de billet, surtout venant de la part d'une figure du monde PHP, à savoir Fabien Potencier (monsieur Symfony). Ça fait des années que je pense comme Fabien : PHP est un mauvais langage de template. Pas assez sécure (que fait-t-on des templates uploadés par des utilisateurs par exemple ?), trop verbeux, parfois trop complexe pour les intégrateurs web qui ne savent pas programmer, et n'impose pas une séparation entre logique métier et "vue" (vu que dans un template en PHP, on peut appeler tout et n'importe quoi).

C'est pourquoi j'ai toujours préfèré utiliser un langage qui soit conçu pour les templates, pour faciliter leurs écritures d'une part, et de bien faire une séparation entre la logique métier et la "vue". Et c'est pourquoi dans Jelix, j'ai crée mon propre moteur de template, ultra léger et performant, jTpl, qui est disponible en version standalone, dont je devrais sortir la version 1.0 dés que j'ai un peu de temps.

14 commentaires

mardi, septembre 22 2009

De la 3D dans Firefox

Par Laurentj le mardi, septembre 22 2009, 15:28

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

4 commentaires

vendredi, septembre 11 2009

XRX, un doux rêve ?

Par Laurentj le vendredi, septembre 11 2009, 14:30

Tangi vient de publier un billet très intéressant sur une nouvelle façon de faire une application web, une architecture XRX, qui utilise XForms, Rest, et XQuery. Vu de loin, ce triplet à l'air sexy, et fait renaître l'idée de faire du XML de bout en bout, sans avoir à taper une ligne de code "fonctionnelles". Et pour Tangui, cela apporte beaucoup de simplicité par rapport au triptique Javascript/PHP/MYSQL. Sur ce point, je ne suis pas d'accord avec lui.

Lire la suite...

3 commentaires

vendredi, juillet 17 2009

Transformations 2D et 3D en CSS

Par Laurentj le vendredi, juillet 17 2009, 13:46

Ainsi donc, webkit supporte maintenant les transformations 3D en CSS. Je trouve ça génial. J'apprécie déjà les transformations 2D (que j'utilise sur la page d'accueil de jelix.org). Mais là, ça ouvre encore plus de perspectives (c'est le cas de le dire ;-)).

Seulement, à travers les demos que j'ai ouvert dans mon Firefox (qui ne supporte pas les propriétés transform3D), j'ai remarqué que l'utilisation de ces transformations avaient un écueil : ça se dégrade très mal dans les navigateurs ne supportant pas ces propriétés. Du genre, les éléments s'affichent les uns sur les autres. Il y a certainement des améliorations possibles dans ces démos pour que ça se dégrade un peu mieux. Mais c'est certain qu'il va falloir faire attention...

Pour les plus curieux d'entre vous, les brouillons des spécifications sont disponibles sur le site du W3C : CSS3 3D transforms, CSS3 3D transforms.

4 commentaires

jeudi, juillet 2 2009

Theora, après Firefox et Chrome : Opera

Par Laurentj le jeudi, juillet 2 2009, 17:30

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

7 commentaires

dimanche, juin 28 2009

De la 3D dans Firefox

Par Laurentj le dimanche, juin 28 2009, 16:11

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

un commentaire

vendredi, juin 26 2009

Chantiers: XBL2 et multi processes

Par Laurentj le vendredi, juin 26 2009, 17:51

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

Par Laurentj le mardi, juin 23 2009, 12:49

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

14 commentaires

jeudi, juin 18 2009

La technologie Zoomorama

Par Laurentj le jeudi, juin 18 2009, 11:17

Une fois n'est pas coutume, je vais vous parler de ce qu'on fait dans la boîte où je travaille, Zoomorama, ou plus exactement, de la technologie que l'on a crée ou utilisé.

Lire la suite...

7 commentaires

mercredi, juin 17 2009

Des articles intéressants sur hacks.mozilla.org

Par Laurentj le mercredi, juin 17 2009, 17:53

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

un commentaire

mardi, juin 9 2009

Les nouveautés de Firefox 3.5 en 35 jours

Par Laurentj le mardi, juin 9 2009, 13:19

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

2 commentaires

- page 1 de 15