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

mercredi, janvier 12 2011

Plus de H264 dans Chrome

Google vient de l'annoncer : le support du format video H264 va être retiré de Chrome (sachant que dans Chromium, la version opensource du navigateur, il n'y en avait déjà pas). Ce qui veut dire que Google va commencer à pousser fortement à l'utilisation de son propre format vidéo, WebM, déjà supporté par Firefox, Opera et d'autres navigateurs libres.

C'est une excellente nouvelle pour le web, et pour la balise video, que d'avoir un format, WebM, de qualité et non encombré de brevets logiciels connus. J'en avais déjà parlé il y a quelques mois, quand Google libérait ce format. Depuis, cette époque, même s'il n'a pas trop fait parlé de lui publiquement, WebM a progressé, tant au niveau logiciel qu'au niveau hardware, puisque des puces vont bientôt être disponibles.

Il ne reste "que" Internet Explorer et Safari (sur Macbook ou iphone) à ne pas supporter nativement WebM. Toutefois, avec IE9, il suffira d'installer le codec au niveau du système.

Attention cependant, ne crions pas victoire trop vite. Le retrait du support n'est pas encore fait, et l'annonce de ce retrait provoque une vague de mécontentement chez beaucoup d'utilisateurs et de développeurs, si on en croit les nombreux commentaires sur la news (les menaces de passer à un autre navigateur sont particulièrement risibles).

Sans parler du fait que c'est philosophiquement un peu en contradiction avec une précédente décision : celle d'inclure dans le navigateur, Flash, un produit propriétaire.

Espérons que Google tiendra bon dans sa décision sur WebM. Cela fait de lui un allié de plus à Mozilla, dans la lutte pour garder un web ouvert, dans sa volonté de ne pas supporter de formats propriétaires.

jeudi, juin 24 2010

IE9 a quasi rattrapé son retard

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

mercredi, mai 19 2010

WebM, le nouveau format video du web

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

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

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

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 !

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

jeudi, octobre 23 2008

Questions réponses sur l'élement video

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

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

vendredi, août 29 2008

Drag and drop HTML5 dans Firefox

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

Lire la suite...

dimanche, juillet 27 2008

Avancées dans Gecko 1.9.1

Malgré les 3 ans de développement qu'a necessité Gecko 1.9.0 (le moteur de Firefox 3), il n'a pas été possible d'implémenter certaines choses qu'ont déjà Safari et Opera, bien que toutefois les nouveautés pour les développeurs soient très alléchantes, avec des morceaux de HTML5 dedans :-). En effet, les développeurs du "coeur" s'étaient concentrés principalement sur la gestion de la mémoire, les performances, la refactorisation de gros morceaux de code, et la correction de bugs pour passer le test Acid2. C'était donc beaucoup de travail sur des choses "qui ne se voient pas". Mais une des conséquence de ces développements "sous-terrains", c'est que Gecko 1.9.0 est devenu une bonne base pour avancer bien plus vite sur l'implémentation des standards.

Du coup, les développeurs peuvent se concentrer sur le futur. Et ils ne s'en privent pas depuis un mois et demi. Je vous avez parlé de l'implémentation de la balide video, de l'implementation du style CSS border-image, mais aussi évoqué l'implementation complète des selecteurs CSS3 (modulo 2-3 bugs), le support de text-shadow (pour créer des ombres sur du texte), de box-shadow (pour faire des ombres sur des boîtes).

Et ces derniers jours, voici les nouveautés :

  • Implémentation de la propriété CSS3 word-wrap
  • Implémentation des propriétés CSS3 column-rule-*, pour styler les séparations entre les colonnes CSS. Souvenez-vous que depuis sa version 1.5, Firefox permet de créer des colonnes en CSS, ce qui évite de faire appel à des tables pour avoir des colonnes de texte. J'en avais parlé à l'époque.
  • Implémentation de l'objet NodeIterator dans l'API DOM traversal, permettant de parcourir un arbre DOM de manière séquentiel, contrairement au TreeWalker qui propose plutôt une vue arborescente de la navigation.
  • Implémentation des toutes nouvelles fonctions DOM querySelector et querySelectorAll : elles permettent de récupérer un ou plusieurs noeud DOM en utilisant un sélecteur CSS, ce qui est plus simple que d'utiliser un selecteur XPath (fonction evaluate sur les objets document). Voici un exemple issue de la spécification. Voici ce qu'il faut faire en temps normal quand on veut récupérer la deuxième cellule de chaque ligne d'un tableau (ayant pour id score) :
var table = document.getElementById("score");
var groups = table.tBodies;
var rows = null;
var cells = ;

for (var i = 0; i < groups.length; i++) {
  rows = groupsi.rows;
  for (var j = 0; j < rows.length; j++) {
   cells.push(rowsj.cells1);
  }
}

Et voici maintenant l'équivalent avec querySelectorAll :

 var cells = document.querySelectorAll("#score>tbody>td:nth-of-type(2)");

Sympa non ? :-)

Parmis les développements actifs en ce moment, et qui vont donc aboutir d'ici quelques semaines, voici ceux là :

  • Les propriétés CSS de transformation proposées par Webkit, permettant de faire des animations en CSS.
  • L'implémentation des medias queries de CSS. (mise à jour : en fait ça vient juste d'être intégré dans le trunk !)
  • Fonctions javascript trim, ltrim, et rtrim
  • DOMWorkerThreads : la possibilité de faire, en javascript, de vrai traitement en parallèle...
  • Une partie de l'implémentation de @font-face

Bien sûr, cette liste est loin d'être exhaustive :-)

mercredi, juillet 9 2008

La balise video dans Firefox

Il y a quelques heures, l'implémentation de la balise <video> a été intégré dans la version de développement de Firefox 3.1 !! Mais ce n'est pas encore totalement fonctionnel : il manque encore l'intégration des "backend", c'est à dire des parties de code qui lisent et affichent la vidéo. En clair : on peut mettre une balise <video>, ses attributs fonctionnent, son API (play(), stop()...) fonctionne, il y a un carré sur la page web où est censée s'afficher la vidéo, mais il ne se passe rien. Cependant ça va venir. (Mise à jour : une version plus récente de cet article est disponible !)

Lire la suite...

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

mardi, avril 17 2007

La balise <video>

Le whatwg propose une nouvelle balise,<video> dans HTML5, pour incorporer facilement des vidéos dans une page html. Certains ne voient pas l'intérêt de cette balise, dans la mesure où la balise <object> (ou <embed>) rempli soit disant très bien ce rôle. Je ne suis pas d'accord avec eux, et voici pourquoi je trouve que cette balise <video> est une bonne chose. (Mise à jour : une version plus récente de cet article est disponible !)

Lire la suite...