zzzombie

Hixie (l’une des personnalités les plus importantes du Whatwg, à l’origine d’HTML 5) est revenu sur les codecs et les standards Web : http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020620.html

Il manque une solution : le FLV qui fonctionne sur 98% des postes connectés à Internet. Bien sûr, ça n’est pas standard mais il y a un avantage considérable : on n’a pas besoin de stocker la vidéo en plusieurs formats.
Ca fait un moment que je pense à réaliser un player “total”, capable de lire plusieurs formats de vidéo et des vidéos hébergées sur d’autres sites, avec une seule interface.

La solution sur laquelle je vais partir, c’est du standard pour l’interface, et du Flash et du Quicktime (ou autre s’il n’est pas disponible) pour la zone de visualisation.
Il y a plusieurs avantages à cette solution :
- compatibilité maximale avec les différents navigateurs
- qualité vidéo maximale avec Quicktime
- bypass de Flash dans le cas de Quicktime, mauvais pour streamer ce genre de flux
- possibilité d’utiliser simplement les possibilités de Youtube API : affichage chromeless, interactions en javascript

Après avoir retourné le problème dans tous les sens, il s’avère que le tag video est inutilisable et fait revenir à une époque que j’ai détestée : sniffing d’user-agent coté serveur, multiplication des besoins en espace disque et des encodages.

Hixie parle d’une fin proche des brevets sur H.264… mais quand ? Car une chose est quasi certaine : tant que ça ne sera pas arrivé, tant que FF et Opera n’intégreront pas de codes H.264, le tag video restera une solution purement idéologique.
D’ici là, mieux vaut continuer de jouer avec les balises object.

Mozilla continue sa période de promotion de pré-lancement de Firefox 3.5 avec un argument de taille : la vidéo nativement intégrée, en HTML5.
Comme d’habitude, à les écouter on pourrait croire qu’ils sont les premiers et à la limite, qu’ils ont inventé le concept (un peu comme pour l’Awesome Bar, repompée sur Opera. Ou la navigation privée, repompée sur Safari. Ou… bref, c’est une habitude).

Le problème, c’est que la vidéo dans Firefox, on s’en fout un peu et ceci pour une raison simple : le choix de ne supporter que du OGG.
OGG c’est super, c’est libre. Forcément, c’est un sacré avantage.
Mais il a aussi de sacrés inconvénients :
- ce n’est pas un standard du monde de l’imagerie
- il n’est pas de bonne qualité
- ce n’est pas un standard informatique installé

Le premier est plutôt problématique, car il signifie qu’on va devoir réencoder à coup sûr en OGG, même les sources déjà compressées. Et qui dit encodage dit perte de qualité. Mais soyons honnête, on recompresse très souvent de toute façon, ne serait-ce que pour mettre à l’échelle et changer le bitrate.
Le second  devrait évoluer rapidement, et Mozilla finance son amélioration. Là j’ai envie de troller un petit peu au passage, je dois dire, mais je vais me retenir pour éviter de dévier.
Le troisième est le problème majeur, parce qu’il retient fortement les développeurs de choisir le OGG.

Le marché des navigateurs est assez simple : IE domine encore et ne supporte pas la vidéo en natif. Firefox est un second solide et supportera le OGG. Safari est un troisième non négligeable et il supporte tous les formats supportés par QuickTime.

Ajoutons à cela le marché des navigateurs mobiles, en forte expansion : l’iPhone représente la majorité du surf et inclus Safari, le second voir même le premier sera dès l’année prochaine Android qui va s’installer sur un grand nombre de marques et de modèles, et propose Chrome, donc un autre navigateur WebKit. Mais sans QuickTime.
Pour le reste, il y a du Opera mini qui supporte peut-être la vidéo comme son grand frère mais dont on se fiche un peu puisqu’il va perdre sans cesse du terrain, et IE qui est aussi appelé à perdre des parts de marché et qui ne fait pas grand chose de toute façon.

Donc : soit on fait du OGG et on ne s’adresse qu’à Firefox et Opera, et éventuellement à Safari en expliquant aux utilisateurs comment ajouter le codec OGG  (ah ah ah) et il faut faire une version Flash pour les autres, soit on fait un lecteur Flash pour lire du H264 et on peut faire un lecteur standard pour Safari et Chrome desktop… et l’iPhone.
D’un autre coté, Mozilla va sortir Fennec, et il supportera probablement le tag video, tout comme Opera mini.
Les téléphones sous Android n’auront pas QuickTime donc pas de H264, et Linux non plus d’ailleurs, donc pour lui le OGG est tout désigné… ou le Flash puisqu’il existe déjà.
Ou bien on bouffe deux fois plus d’espace disque, deux fois plus d’encodage et on fait du OGG et du H264. Ou 3X et on ajoute le FLV : chaque plate-forme son fichier : c’est beau les standards du web, j’vous l’dit !

Pour finir de rigoler, parlons des possibilités et des performances :
- Firefox 3.5 permet plus de choses que Safari,en permettant d’accéder aux informations bitmap de la vidéo. Safari ne le proposera que plus tard, sans qu’on sache trop quand.
- Par contre, Firefox 3.5 est incroyablement gourmand en CPU, même en idle, dès qu’une vidéo est intégrée à la page. Autant vous dire que les pages avec plein de vidéos qui s’enchaînent vont par contre déchaîner les ventilateurs, et effrayer les portables.
De plus son algorithme de streaming est vraiment nul. Enfin était, il paraît qu’il y a eu du progrès récemment mais on partait de très, très loin.
De son coté, Safari est économe en CPU, a déjà un streaming excellent et va avoir un streaming adaptatif de folie avec Quicktime X, et ce sans avoir de serveur de vidéo dédié : idéal pour la diffusion autant HD que dans des conditions difficiles de mobilité.
Alors que les premiers retours de Fennec que j’ai pu voir indiquaient que le navigateur était plutôt lourd. Et puis je ne sais pas quand il va sortir mais s’il faut attendre autant que pour FF3.5, c’est pas pour tout de suite.

“Alors, tu tournes autour du pot mais qu’est-ce qu’on fait, du coup ?”, me demanderez-vous.

Pour le moment, je dirais :
- du H264 avec un  javascript qui affiche un player HTML5 pour Safari et iPhone, un lecteur Flash pour les autres
- un fallback vers un tag vidéo HTML5 dans le noscript si on n’a pas d’Opera ni de Firefox dans la chaine de l’agent des headers HTTP (à voir…)
- un fallback video vers une image de preview et un lien de téléchargement du fichier vidéo.

Mais si vous avez de l’espace disque et du CPU en trop :
- deux version de la vidéo, détection javascript du navigateur pour afficher le player adéquat
- un fallback vers un tag vidéo HTML5 dans le noscript avec la vidéo H264 comme source si on a Webkit dans la chaine de l’agent des headers HTTP, le OGG sinon
- un fallback avec deux liens pour télécharger ou bien le fichier OGG, ou bien le H264. Et les linuxiens seront contents.

Dernière solution :
Un FLV dans un player Flash, à l’ancienne. A la limite un H264 pour avoir une chance d’évoluer un peu plus tard.

Pour faire bouger les choses, vous pouvez toujours demander à Mozilla de supporter les codecs système, à WebKit d’intégrer nativement le OGG, mais enfin il restera toujours le lamentable IE.

Et pour faire bouger Microsoft ça risque d’être coton : leur avancée très lente vers les standards n’est qu’une grosse blague destinée à maintenir des parts de marché pour IE, alors que dans le  même temps ils mettent les bouchées doubles pour Silverlight.
Leur avancée vers les standards me rappelle quelque chose qui n’a rien à voir avec l’informatique : la Moonwalk.

Conclusion : y’a pas à dire, la vidéo en HTML5, ça simplifie vraiment la vie…

Safari n’a pas autant d’extensions que Firefox, loin de là mais il en existe tout de même quelques-unes pour OS X qui valent le détour :

Glims ( http://www.machangout.com/ )
Ajoute un nombre considérable de possibilités à Safari. Parmi celles qui me sont le plus utiles :

• annulation de la fermeture d’onglets par cmd+z (identique à cmd+shift+t pour Firefox)
• restauration des onglets à l’ouverture de safari
• favicons dans les onglets
• autocomplétion dans la zone de recherche avec suggestions de mots et de pages (nombre et ordre configurable + raccourci de zone), choix des moteurs

Safari View Selection Source ( http://sokira.pdb.com.ua/(…) )
Ajoute une entrée permettant de voir le code source de la sélection au menu contextuel, comme Firefox

Safari Source ( http://www.tildesoft.com/(…) )
Ajoute la colorisation syntaxique à la visualisation du code source. Malheureusement, ça ne fonctionne qu’avec Safari et pas avec WebKit et il n’y a pas moyen de joindre le développeur pour lui demander de corriger cette limitation.

Web inspector
Si ça n’est déjà fait, il faut débloquer le menu Debug pour avoir accès à l’excellent inspecteur web de Safari.
Dans le terminal, il suffit de saisir :
defaults write com.apple.Safari IncludeDebugMenu 1
et vous avez alors accès à cet outil puissant permettant de débugguer, de profiler, de voir les ressources liées et leur ordre et temps de téléchargement, visualiser les bases de données client-side, avoir des infos sur le DOM…
Raccourci clavier : Cmd+Option+i

Les 5 premières minutes sont un peu pénibles car le son a de sérieux problèmes, mais tout s’arrange par la suite.
La plupart des techniques présentées sont maintenant assez connues mais il en reste toujours quelques-unes qui peuvent surprendre.

High Performance Web Sites and YSlow

Presque tout ce qui est exposé dans cette vidéo peut être trouvé sous forme d’articles ici : http://developer.yahoo.com/performance/
Si vous aimez vraiment beaucoup les répétitions, une autre conférences faite par le même orateur sur le même sujet est visible ici : http://video.yahoo.com/watch/1040890/3880720
Encore plus fort, retrouvez John Resig refaire quasiment le même speech que celui présenté précédemment, mais aussi d’autres vidéos sur d’autres sujets (en rapport avec le développement web) à http://developer.yahoo.com/yui/theater/

Dans La Recrue, des apprentis espions finissent par ne plus savoir qui ils sont, pour qui ils travaillent vraiment, ni même vraiment ce qu’ils font.
A part Colin Farrel, qui peut compter sur sa solide expérience professionnelle.
Il lui suffit de deux secondes pour ouvrir son portable, brancher une clé USB, lire #include <stdio.h> #include <stlib.h> et hop c’est tout vu, il faut qu’il appelle pour prévenir :

Ah bah là alors, ok !

Voici une démonstration des nouveautés de HTML 5 par Ian Hickson du WHATWG.
Il est plus connu sous son pseudo (Hixie) et surtout pour son célèbre test d’implémentation des normes par les navigateurs : le fameux test “Acid”.

Avertissement : la fin de la vidéo ne passe pas, le lecteur de YouTube se mettant à faire n’importe quoi après 1h de vidéo, comme souvent malheureusement. De plus elle peut bloquer votre ordinateur quelques secondes quand vous en lancez la lecture : pas de panique et un peu de patience, elle finit toujours par arriver.
Peut-être que cette démo ne vous sera pas inconnue ; en effet elle n’est pas toute neuve puisqu’elle date de septembre 2008.

Sommaire (et liens vers les fichiers d’exemples) :

1. <video> (00:35)
2. postMessage() (05:40)
3. localStorage (15:20)
4. sessionStorage (21:00)
5. Drag and Drop API (29:05)
6. onhashchange (37:30)
7. Form Controls (40:50)
8. <canvas> (56:55)
9. Validation (1:07:20)
10. Questions and Answers (1:09:35)

Cet exposé montre un certain nombre de choses qui devraient largement simplifier la vie des développeurs.

Même s’il va falloir attendre un bon moment avant de pouvoir les utiliser sur des sites Internet, le développement des intranets et des interfaces d’administration va être nettement raccourci grâce aux WebForms 2.0, et vont pouvoir être bien plus riches et réactives grâce aux bases de données coté client.
Quant à Canevas, il permet de se passer des plug-ins pour créer des graphiques et donc des dashboards complexes. Si Google Analytics pouvait se débarrasser de Flash par exemple, je ne m’en plaindrais vraiment pas.
Pour les choses plus ludiques et grand public, tant qu’IE n’implémentera pas Canevas, on sera forcément bloqués rapidement.

Safari 4

De son coté, Apple a sorti une beta de Safari 4 et en a profité pour mettre à jour ses docs : la page CSS Recipes for WebKit pourra intéresser les nouveaux venus. Pour les autres, rien de nouveau.

Ce nouveau Safari 4 est une avancée majeure sur plusieurs points :
- Elle est nettement plus conforme aux Windows GUI guidelines : rendu du texte “à la Windows”, apparence bien plus standard. Apple veut maintenant ratisser large et propose une adaptation plutôt qu’un portage bâclé, c’est une bonne chose.
- Son interface est enfin digne d’un produit Apple. Jusqu’ici sobre à l’outrance, limite “ghetto”, Safari 4 est maintenant beau, et utilise des transitions et modes d’affichages agréables à l’oeil.
- Son moteur est WebKit, incontestablement le plus avancé et le plus rapide du marché
- De nouvelles fonctionnalités sont apparues et sont vraiment utiles. Les Top Sites “à la Chrome” sont vraiment pratiques, le coverflow dans l’historique et les bookmarks permettent un bien meilleur repérage et surtout, la fonction “Search History” (en bas à droite de la page “top sites” ou dans l’historique) est incroyablement pratique, recherchant dans le contenu textuel de toutes les pages visitées. Pour les maceux, c’est l’occasion d’adopter les mêmes réflexes qu’avec iTunes ou SpotLight, avec la même efficacité : cette fonction me sert sans arrêt depuis deux jours.
- La Smart Bar (barre d’adresse avec suggestions) comble un manque évident par rapport à Firefox ou Opera. Elle est moins flexible que celle de Firefox mais en revanche elle s’affiche beaucoup mieux, est est plus réactive et lisible. Elle est aussi mieux présentée que celle d’Opera, qui reste la plus puissante (recherche dans les adresses dans l’historique, mais aussi dans les titres et le contenu textuel des pages).
La barre d’Opéra a cependant un inconvénient de taille : il y a tellement d’infos et de résultats qu’elle peine à rester lisible, et si on a trop de résultats il est bien difficile de retrouver le bon vu le peu d’infos qui tiennent en deux lignes. Pire, l’historique est une réplique de la barre d’adresse et n’arrange rien. L’approche d’Apple me paraît donc meilleure, quoique les résultats “historique” de la Smart Bar pourraient inclure la recherche fulltext en marquant les résultats trouvés dans le corps d’une page d’un petit picto, ou proposer une option “tout afficher” à la SpotLight… mais j’imagine que ça a été déjà tenté et rejeté, ou que c’est en cours d’implémentation.

Bref, entre les nouvelles technologies en approche et un Apple de plus en plus agressif qui force ses compétiteurs à forcer la cadence, les mois prochains s’annoncent vraiment très, très intéressants pour les développeurs web.

Comme chacun le sait, le plug-in Flash sous OS X est une horreur qui consomme énormément de ressources CPU et a tendance à faire tourner les ventilos à la première vidéo venue.
Jusqu’ici, comme tout le monde ou presque, je rendais le plug-in Flash Player responsable.
Le fait est que je n’avais jamais particulièrement fait attention à ce qu’il donnait sous Opera. Et là, surprise : la consommation de CPU pour visionner une vidéo YouTube est deux fois moindre que sous Firefox ou Safari.

Il n’y a pas de miracle : le plug-in Flash était exactement le même pour Opera, Safari et Firefox. La conclusion qui s’impose est que les fautifs sont Gecko et Webkit, qui intègrent visiblement très mal le plug-in d’Adobe. Si la VM de Flash est capable de tourner deux fois plus rapidement dans un navigateur, c’est donc qu’elle tourne deux fois trop lentement dans les autres.

Je vous invite à faire le test avec Opera 10 alpha (c’est le navigateur avec lequel j’ai fait mes divers tests).
Même si Flash n’est pas standard et ne va pas dans la direction voulue par Apple et Mozilla ça n’est pas une raison pour bâcler ce qui l’entoure.
J’espère que cette lenteur n’est pas délibérée, sans quoi ça serait un comportement digne de Microsoft.

Voici deux conférences sur l’évolution du web, l’une en anglais, l’autre en français. Chacune dure environ une heure.

La première concerne les évolutions des navigateurs et ce qu’elles impliquent et s’est déroulée dans les locaux de Google. L’intervenant n’est autre que John Resig (le créateur de jQuery, actuellement employé par Mozilla en tant que Javascript Evangelist).

John Resig - Search for Drop-in JavaScript Performance (en)

La seconde est très différente puisqu’elle concerne les politiques des réseaux et obligations légales des différents acteurs, que ce soient les FAI, les hébergeurs ou les éditeurs. Elle se déroule dans une ambiance très différente : un amphi d’université devant un public visiblement très libriste.
Le fond est très bon et l’argumentation est très pertinente. Pour la forme, vous verrez bien : personnellement je ne suis pas fan des ambiances universitaires, chacun son truc.

 Benjamin Bayart - Internet libre ou Minitel 2.0 (fr)

Opera a annoncé récemment l’arrivée d’un nouveau moteur Javascript “révolutionaire” qui devrait arriver dans Opera 11. Les performances sont sensées être 2,5x meilleures au bas mot, bref c’est sensé tuer la gueule, rien de moins.

Ces chiffres qui reviennent de plus en plus souvent commencent à m’ennuyer sérieusement. Il est devenu impossible de s’y fier, les différents acteurs se focalisant sur cetains benchs bien en vue (Acid 3, au hasard) pour concentrer leurs développements. Ces tests sont trop basiques et pas assez graphiques.

En réalité, ce qui manque de plus en plus est la possibilité de créer des animations en n’utilisant que des technologies standardes et de pouvoir se passer de Flash.

Comme ce sont à peu près toujours les mêmes benchmarks qui reviennent à chaque nouvelle version et qu’ils sont plutôt bidons, voici une courte liste d’autres tests pour la plupart visuels, qui s’enrichira probablement avec le temps :

http://acko.net/files/projective/index.html : test de 3D mappée utilisant Canevas

http://prototype-graphic.xilinus.com/samples/shape.html : tests vectoriels 2D avec SVG, VML (pour IE) et Canevas (pour tous les autres navigateurs qu’IE).

http://www.jsballs.com/benchmark.html : de plus en plus de sprites 2D pour voir à partir de quand votre navigateur décroche.

http://intertwingly.net/stories/2006/07/10/penroseTiling.html : encore du SVG et du Canevas 

http://bubblemark.com/dhtml.htm : ce test est aussi disponible en Flash, Silverlight ou Java. Les versions Java sont vraiment incroyablement pénibles et donnent des résultats très étranges (du genre : un FPS très élevé, mais à l’écran ça rame franchement)

Le nouveau jQuery est arrivé, rapidement suivi d’une d’une mise à jour de correction de bugs.
Cette nouvelle version apporte des changements très appréciables à tous les niveaux :

- plus de détection des navigateurs. Cette technique était vraiment très mauvaise. Si elle n’avait pas trop d’incidence quand on suit l’évolution d’un produit et qu’on le met à jour régulièrement, elle était bien plus problématique pour les sites sans suivi. Au mieux, les nouveaux navigateurs ne profitaient pas forcément des implémentations des nouvelles normes pour accélérer l’exécution de codes jQuery, au pire on pouvait voir apparaître un bug avec le temps.
jQuery teste maintenant les implémentations technologiques des browsers pour décider de quelles méthodes utiliser ce qui en fait une bibliothèque “future-proof”. Il n’y a donc plus de risque d’avoir des appels de vos clients concernant des anciens projets, parce que la version de jQuery que vous avez utilisé à l’époque ne fonctionne pas bien avec un nouveau navigateur.

- beaucoup plus rapide, en particulier avec les nouveaux navigateurs.
Si jQuery a bien sûr été optimisé,  l’un des changements les plus radicaux vient de l’implémentation des nouveaux sélecteurs DOM des navigateurs récents comme querySelectorAll. Moins de code javascript, moins d’opérations DOM pour un même résultat et les performances s’envolent pour les navigateurs supportant ces nouvelles possibilités. C’est à dire, pour le moment, les navigateurs basés sur Webkit (Safari et Chrome), et dans un avenir proche Firefox 3.1, IE8 (si si !) et Opera 10.
Les benchmarks de jQuery 1.3 avec différents navigateurs et comparés aux autres bibliothèques javascript sont disponibles sur cette page.

Au-delà du code, d’autres choses accélèrent encore jQuery. Ainsi, il n’y a plus de version “packed” (l’algo de Dean qui permet de compresser les javascripts par minification / encodage Base62) : cette version était optionnelle mais asez largement répandue puisque plus petite que les autres distributions. Mais comme le gain disparaît quand on active la compression gzip over http 1.1 et que le navigateur doit décoder la bibliothèque, au final on perd du temps.
jQuery force donc la main des développeurs et administrateurs en les obligeant à utiliser des méthodes plus rationnelles et modernes et ça n’est pas un mal.

Plus important encore, Google s’associe à jQuery et en propose une distribution. C’est à dire que vous pouvez inclure directement l’url du script hébergé par Google et d’une part profiter de la compression gZip même si vous ne l’avez pas mise en place sur votre serveur, et d’autre part profiter de l’exceptionnelle infrastructure de Google, et de leurs réplications locales à gogo qui font que vous gagnerez toujours en vitesse à moins d’utiliser un service équivalent comme Akamai. Vu les tarifs d’Akamai, cette réserve ne concerne pas grand monde.

- Une nouvelle doc de l’API. Si vous utilisiez une doc de type VisualJQuery, sachez qu’il y a maintenant un équivalent officiel et qui forcément, sera toujours à jour : http://api.jquery.com/
Seul regret, il y a une petite erreur ergonomique : le filtre est mal placé. Tant pis.

- Nouvelles possibilités : Tout est détaillé ici. Les nouveautés ouvrent beaucoup de nouvelles perspectives mais il y a finalement pas tant de monde que ça qui code vraiment en jQuery, la plupart des développeurs se contentant d’utiliser des plugins. Si vous êtes concernés, vous trouverez sans doute des solutions à vos problèmes récurrents.

Avertissement : lisez bien la section Changes de cette page avant de vous lancer dans une mise en production hâtive. Car il y a des aussi des changements importants dans le comportement de jQuery qui peuvent altérer sérieusement le comportement de vos scripts.
Par exemple, le sélecteur d’attribut @ dans [@attr] a été supprimé. Ou encore, la méthose (ready) ne concerne plus les CSS et vous devrez les déplacer avant dans votre code HTML si vos scripts interagissent avec.
Vous êtes aussi prévenus que vos pages doivent etre codées en mode standard pour être assurés que vos scripts tourneront normalement, car il peut y avoir des bugs en quirksmode.

Bref, voilà une mise à jour très prometteuse qui devrait trouver immédiatement sa place sur vos machines de dev, mais mieux vaut l’y laisser un bon moment le temps de vous être assurés que tout fonctionne comme avant, tout en profitant de cette période pour découvrir ses nouvelles capacités.

Bon courage…