Les articles avec le tag « HTML5 »

Flash vs. HTML5

Depuis que Steve Jobs a publié ses « pensées sur Flash » en avril 2010, beaucoup de technophiles prédisent régulièrement la mort de Flash. J’abuse moi-même volontiers du hash #flashisdead quand je poste des sites ou démos particulièrement impressionnants en HTML5 sur Twitter.

Mais j’ai beau détester Flash de manière quasi-viscérale, que ce soit en tant que développeur web ou simple utilisateur, je sais bien que Flash n’est pas prêt de mourir. Des gens continueront à faire des sites en Flash, à diffuser des vidéos en Flash et à faire des animations en Flash pendant au moins les 10 prochaines années. Ça ne signifie pas pour autant que Flash va rester techniquement pertinent. Aujourd’hui encore, des gens continuent de faire des sites en tableaux, en frameset, avec des Gifs animés partout. Ce n’est certainement pas parce que c’est un choix techniquement pertinent.

Certaines personnes refusent d’opposer techniquement Flash à HTML5, en affirmant que les 2 sont complémentaires et doivent être utilisés conjointement à bon escient. C’est vrai aujourd’hui, avec le marché actuel des navigateurs et leur prise en charge de toutes les nouveautés de HTML5. Mais si on se projette 3 ans en avant, au rythme actuel, nous serons sur IE12, Chrome 41 et Firefox 34. En étant optimiste, toutes les fonctionnalités de HTML5 et CSS3 seront déjà largement intégrées et parfaitement fonctionnelles dans ces navigateurs. Quand vous devrez faire des animations, vous aurez donc le choix d’utiliser des outils libres (Canvas, SVG, etc…) ou alors Flash. Le choix ne sera plus un choix technique, mais un choix philosophique.

Lire la suite

The end of <time>

Samedi dernier, Ian Hickson (l’auteur des Acid Tests, des specifications CSS 2.1, et membre actif des specifications HTML5) a déclenché un cataclysme dans le monde du web en annonçant le retrait de la balise <time> au profit d’une nouvelle balise : <data>.

L’objectif de ce changement, c’est d’avoir une balise plus générique, qui s’adaptera à n’importe quel type de données (temps, distances, poids, monnaie, etc…). Vendredi dernier, si vous souhaitez décrire une date de manière la plus sémantique possible, vous pouviez écrire ceci :
<time datetime="13:37">13h37</time>

Désormais, il faudra écrire ceci :
<data machineval="13:37">13h37</data>

Mais ça, c’était sans compter sur le fait qu’on est sur Internet, et que sur Internet, on râle. Du coup, un mouvement d’intégristes s’est formé sur Twitter sous le hash #occupyhtml5 puis sur le site Why no <time> ?.

The end of time

En théorie, je suis assez d’accord avec la décision du W3C. Le but du langage HTML est avant tout d’être compréhensible par des machines, et pas d’être beau pour des humains. En pratique, ce changement tombe quand même plutôt mal. Histoire de mettre de l’huile sur le feu, Mark Jaquith de WordPress.org est venu commenter sur le blog de Bruce Lawson :

Approximativement 4,103% des sites WordPress utilisent le thème Twenty Eleven, ce qui se traduit par plus de de 2,6 millions de sites WordPress qui utilisent la balise <time>.

Et ça, c’est juste pour le domaine WordPress.org.

Si je suis extrêmement enthousiaste face à pleins de nouveautés de HTML5 et CSS3, j’ai toujours été un peu distant par rapport à la nouvelle sémantique HTML5 : pas toujours adaptée, difficile à comprendre et à utiliser, pas forcément bien prise en compte par les moteurs de recherche et autres robots, … Ce changement encore tout frais de la sémantique HTML5 ne fait que renforcer mon avis, et je garde constamment à l’esprit les premières lignes des specifications HTML5 quand j’utilise des nouveautés de ce genre.

Les implémenteurs doivent être conscients que cette spécification n’est pas stable. Les vendeurs intéressés pour implémenter cette spécification avant qu’elle atteigne finalement son statut de Candidate Recommendation devraient rejoindre les listes de mail et prendre part aux discussions.

Adobe Wallaby et sa conversion Flash/HTML5

WallabyEntre le succès d’iOS et toute la com’ autour d’HTML5, Adobe a bien du soucis à se faire pour l’avenir de Flash. Il y a quasiment 1 an, Steve Jobs publiait ses pensées sur Flash, fermant définitivement tout espoir de voir le plugin d’Adobe apparaître un jour sur la plate-forme d’Apple. Kevin Lynch, responsable technique chez Adobe, répondait quelques jours plus tard « [qu’ils avaient décidé] de s’éloigner de l’iPhone et de l’iPad aussi bien pour le Flash Player que pour AIR« . Retournement de situation hier, avec la sortie en version prerelease d’Adobe Wallaby, un convertisseur d’animations Flash en HTML5 pour Webkit. Lire la suite de mon premier essai de Wallaby

Des démos WebGL

Vendredi dernier, Chrome 9 est sorti avec pour la première fois dans un navigateur en version finale : WebGL. Si comme moi vous vous étiez jusqu’alors désintéressé de WebGL (la flemme d’activer WebGL dans Chrome ou Firefox 4), voici l’occasion de se rattraper avec cette petite sélection personnelle. Pour voir ces démos, vous aurez besoin de Chrome 9 ou Firefox 4 (beta).

Google Body

Google Body : Après la cartographie Terrestre, Google a lancé en décembre dernier cette application en ligne permettant d’explorer le corps humain. Grâce à WebGL, vous pouvez tourner le corps de la charmante cobaye sous toutes les coutures, zoomer à travers les différentes couches du corps humain pour faire apparaître nos différents organes.

Quake II WebGL

Quake 2 : En avril 2010, deux illuminés se sont mis en tête de faire un portage WebGL de Quake 2. Résultat : le jeu mythique d’ID Software est désormais partiellement jouable dans un navigateur, sans aucun plugin à installer. ID Software avait déjà sorti en 2007 Quake Live, une version jouable dans un navigateur de Quake III Arena, mais il fallait obligatoirement installer un plugin pour y jouer. Des fans ont déjà réalisé des démos de portage de Quake III en WebGL (Copperlicht Demo Quake 3 Level et Q3Tourney2). De là à rêver d’une version officielle et jouable complète en ligne avec WebGL, il n’y a qu’un pas (que je fais en bunnyhop doublé d’un rocket jump sans hésiter).

Minecraft WebGLMinecraft : Bon OK, ce n’est pas LE Minecraft, mais juste une démo d’un moteur 3D qui ressemble à Minecraft. Mais quand même, l’idée de pouvoir passer sa vie dans une mine pour construire le PlanetExpress de Futurama, ça fait rêver non ?

Nine Point FiveNine Point Five est un site permettant de visualiser les tremblements de terre au cours de ces 30 dernières années. Cliquez sur une des entrées sur la droite pour visualiser le séisme et sa magnitude.

Collectibles PainterCollectible painter vous permet de créer votre propre figurine.  La 3D n’est pas forcément très poussée, mais l’expérience est quand même sympa.

WebGL FieldsWebGL Field est une simple simulation de champs (agricole, hein, pas de formulaire, tsss).  Mais avec un petit effet de flou, la lumière, et le vent qui balaye chaque brindille, ça donne un bon aperçu des capacités de WebGL.

Aquarium WebGLAquarium est une démo qui porte bien son nom. Des petits poissons qui tournent dans leur bocal. Mais du coup, ça donne une bien chouette démo avec pleins d’effets 3D et des animations calculée par votre navigateur.

Voilà pour ma petite sélection personnelle. En farfouillant encore un peu plus sur le web, vous pourrez trouver des tonnes d’autres démos, comme par exemple sur le site officiel de WebGL, le célèbre Flight of the Navigator des gens de Mozilla, ou encore d’autres démos répertoriées par Google.

Gmail et les marges sous les images

Le bug des marges avec les images dans Gmail

Depuis mai 2010, Gmail affiche une marge sous chaque image. C’est bien embêtant puisqu’un e-mail est composé principalement d’images, de tableaux et d’offres pour du viagra. Heureusement, il y a une solution toute simple proposée entre autres par CampaignMonitor. Il suffit d’ajouter sur chaque image concernée un style="display:block;" directement dans votre balise img. Vous obtiendrez alors quelque chose comme ça : <img src="ch34p_v14gr4.jpg" style="display:block;" />. Tadam !

Ce problème n’est pas directement lié à Gmail, mais à HTML5. En effet, en passant une page en doctype HTML5, les navigateurs affichent différemment les images, probablement en prenant en compte une hauteur de ligne (line-height) différente.