9 Mar
Vous connaissez la technologie Ambilight de Philips ? Bon. Imaginez ça dans votre navigateur.
Si vous avez aimé le Sublime Video, vous aimerez l’Ambilight en HTML5 (qui reprend d’ailleurs la même vidéo).
Par contre, j’ai pas trop compris les explications en russe…
(via Beautiful Pixels)
19 Oct
“It’s not the language you use ; it’s what you do with it.”
Le HTML 5 se popularise. Ok. Mais même avec un code propre et valide dans un langage novateur, tout le monde est libre d’y appliquer le design qu’il veut.
26 Jul
Même si le HTML 5 est encore un joli bordel, des développeurs s’en donnent à coeur joie pour trouver des fonctionnalités très intéressantes, comme ce Drag & Drop en HTML 5 et JS.
5 Jul
Vous êtes sans doute au courant que le groupe travaillant sur le XHTML 2 va s’arrêter à la fin de l’année, pour notamment rejoindre le groupe du HTML 5. C’est moins laisser tomber quelque chose que se concentrer sur un seul standard.
La différence principale entre le XHTML et le HTML est la rigueur du code. Un document XHTML nécessite de n’inclure aucune erreur de syntaxe pour être bien rendu, alors qu’un document HTML peut se permettre de contenir certaines erreurs. Ca vient du moteur de rendu du navigateur qui gère les deux documents différemment. Ca ne veut pas dire qu’il faut être négligeant dans l’écriture du code pour autant. Mais c’est plus propre d’avoir à se tenir à une syntaxe rigoureuse.
Le HTML a l’avantage d’être davantage rétro-compatible. Les navigateurs plus anciens arrivent à mieux lire un document HTML récent qu’un document XHTML récent. Ca vient sans doute du côté “léger” de sa rigueur.
A vrai dire, pas grand chose car c’est dans la logique des choses. Depuis quelques mois, le HTML 5 n’arrête pas de faire parler de lui. Les navigateurs commencent à bien l’implémenter (Safari 4, Opera et le tout récent Firefox 3.5). Et il a un gros potentiel. Pour en savoir plus, vous pouvez lire ma petite introduction au HTML 5.
Etant un adepte du XHTML 1.0 (pour des raisons de rigueur de code et pour éviter le Quirks Mode), je n’aurais pas à choisir entre le HTML 5 et le XHTML 2. Il n’y en aura plus qu’un. Et puis le HTML 5 aura aussi sa “version XML“. Donc je pourrais toujours imposer au document d’être totalement propre.
Je pense que cette fin du XHTML 2 est une bonne chose (même si ce n’est pas la fin du XHTML). Pas de casse-tête avec plusieurs standards à suivre, et un renforcement du HTML 5, ce qui va amener les navigateurs à être encore plus plongé dans le HTML 5 et va faciliter cette tâche.
8 Jun
Le HTML 5 est la prochaine version importante du HTML. Bien qu’étant en compétition avec le XHTML 2, le HTML 5 fait davantage parler de lui parce qu’étant plus facilement implémentable et plus pragmatique dans l’utilisation des nouvelles balises qu’il introduit.
J’avais déjà parlé du HTML 5 l’an dernier, en parlant notamment des balises visant à structurer le contenu. Mais l’intérêt du HTML 5 se trouve surtout dans ces balises qui vont grandement faciliter la création d’applications web.
Tous les exemples proviennent de la Google Keynote.
Google, le plus grand acteur chez les applications web, mise gros sur le HTML 5. Au départ, Google ne croyait pas que les applications web pouvaient rivaliser avec les applications de bureau. Mais avec le grand succès de Google Maps, leur état d’esprit a changé. Comme le dit le VP of Engineering Vic Gundotra :
We knew then that the web had won. What was once thought impossible is now commonplace.
La sortie de Google Chrome est un signe important. Le principal atout de ce navigateur est sa rapidité, grâce à son moteur JS très performant. Et en voyant les applications web utiliser massivement du JS, ce n’est pas un hasard.
Il y a aussi la sortie récente des Google Web Elements qui introduit l’idée de widgets exportables où l’on veut. Avec le HTML 5, ceci risque d’être encore plus simple.
La version Chrome d’Android supportera aussi le HTML 5.
Et puis, YouTube y porte aussi un certain intérêt.
Mozilla est le plus actif pour implémenter les nouveautés HTML 5 dans Firefox, suivi de près par Safari et Opera, si l’on considère cette liste d’implémentation du HTML 5 dans chaque navigateur.
La vidéo en HTML 5 par Dailymotion ne fonctionne que sous Firefox Beta. On peut ajouter un skin autour, mettre la vidéo en flou, ajouter un “edge effect” par dessus… Ca rame sur mon netbook mais c’est sympa.
Avec le sortie de JetPack, on peut imaginer un bel avenir pour le combo JS + HTML 5.
Michael Abbot, le Senior Vice President de Palm, en charge des applications et des services, mise aussi sur le HTML 5 sur le WebOS de Palm :
You as a developer don’t need to leave your prior knowledge at the door to develop for the phone.
Pour faire des applis iPhone, il faut s’y connaître en Objective-C. Pour faire des applis Palm, il faudra s’y connaître en HTML 5 et JS. Je ne sais pas à quel point ça pourra rivaliser en termes de qualité d’applications, mais je veux bien voir.
Je viens de voir sur la Worldwide Developers Conference 2009 que Safari Mobile supportait le HTML 5. C’est pas un détail anodin. Après le succès des app iPhone, celui des app web mobiles sur iPhone ?
Je ne suis pas développeur web mais j’imagine que je pourrais m’y intéresser si les possibilités sont importantes tout en gardant des technologies simples d’accès et performantes. Un avis de développeur JS sur la question ?
Ok, c’est bien beau toutes ces nouvelles balises, mais je fais comment pour l’utiliser aujourd’hui ?
Applications Web : oui mais…
Pour les balises axées “applications web” (canvas, geolocation, video, appcache…), quelques navigateurs en version beta offrent la possiblité d’utiliser ces nouvelles balises. Avec du JS, c’est déjà possible d’en tirer profit.
Structure : OK
En ce qui concerne les balises de “structure” (header, section, article…), il est d’ores et déjà possible de les utiliser. En fait, si les navigateurs ne comprennent pas forcément ces balises “inconnues” mais ne renvoient pas d’erreur. C’est juste que ces balises ne sont pas stylées et qu’elles sont considérées comme “inline”. Un display:block fait l’affaire.
Pour IE6, il faut rajouter un script pour que le style s’applique à ces nouvelles balises.
Je pense que le HTML 5 va surtout concurrencer les plugins de navigateur, et notamment Flash/Silverlight. En fait, l’intérêt de ces deux derniers est avant tout de palier à un manque, surtout au niveau de la gestion du multimédia dans le web (la vidéo en premier). Le HTML 5 peut sans doute gérer ça de manière plus légère, plus sémantique et plus accessible. C’est plutôt le combo HTML 5 + JS qui sera intéressant.
En parallèle du développement du HTML 5, il y aussi celui du XHTML 2. Actuellement, je mets toutes mes Doctype en XHTML 1.0 Strict, parce que j’ai peu de problème de compatibilité avec (Quirks Mode sous IE6 notamment). Après, j’ai pas trop suivi l’avancée du XHTML 2. Peut-être qu’on arrivera à “merger” les deux à un moment donné ?
Enfin, est-ce que le HTML 5 peut rivaliser avec Windows (et plus généralement les OS) ? Haha, ça a l’air très marrant comme supposition, mais certains y croient vraiment. Depuis des années, Google se positionne sur ça : faire du web l’outil de travail principal.
Google Docs + Chrome + Calendar + Notebook + Picasa + Mail + Talk = Web Desktop ?
Le problème des applis web par rapport aux applis de bureau sont principalement :
Le HTML 5 va aider à résoudre le 3ème point, avec la possiblité de sauvegarder des informations en local (voir AppCache plus haut).
Pour le 2nd point, j’utilise rarement les fonctionnalités avancées de Word, et sur ce point, Google Docs me sufflit largement.
Pour le 1er point, un outil aussi basique qu’un tableur ou qu’un traitement de texte nécessite relativement peu de ressources.
Etant très souvent connecté, j’utilise uniquement Google Docs et plus du tout Microsoft Word/Excel. Avec le HTML 5, j’aurais sans doute même plus besoin d’être connecté.
J’imagine un OS qui sera uniquement un navigateur web. Peut-être pour la Crunchpad ?
Le HTML 5 est résolument axé “application web”. Couplé avec du JS, les résultats sont très intéressants. Ca me fait penser à du Jetpack pour un site (et non pas un navigateur). Il est surtout intéressant pour les développeurs du web de s’y pencher plutôt qu’un web designer comme moi. Parce qu’au final, les balises de structure (header, section…), ça facilite légèrement l’intégration et ça ajoute de la sémantique mais c’est pas révolutionnaire, alors que la video/audio, la géo localisation, le appcache… ont énormément de potentiel.
Le problème actuel est qu’il faut encore attendre 2010 avant de profiter vraiment du HTML 5. Mais en réalité, les développeurs n’attendent pas. Comme le dit Dave Clark :
The technology is here even if the standards committees haven’t caught up
We reject: kings, presidents, and voting. We believe in: rough consensus and running code.
Le mot d’ordre serait donc d’être pragmatique. Ne pas attendre les standards mais s’amuser à utiliser ce qu’on peut déjà utiliser pour avoir de l’avance et faire avancer la standardisation justement.
Le plus gros acteur du web, Google, s’y intéresse. Il y a donc forcément du potentiel dans le HTML 5…
22 Jan
Ca faisait quelques temps que je voulais en parler. Cela fait suite à cet article de “A List Apart” : A Preview of HTML 5, dont ce post est entièrement inspiré.
Voici donc des infos sur le HTML 5. Cela correspond aussi au XHTML 5 (à la différence que ce dernier est exprimé en XML, ce qui apporte son lots de variations), qui passerait de la version 1.1 à la version 5 (et coller à celle du HTML). Bien évidemment, tout ceci n’est pas encore clairement défini, ce sont juste des versions alpha (et encore) développées par le W3C et le WHATWG.
Pour l’instant, les balises existantes définissent des titres, des paragraphes, des liens, des emphases, des abbréviations… Mais lorsqu’il est question d’établir les grandes parties d’une page, on doit se tourner vers l’inévitable balise générique : <div> (qui amènera l’horrible expression “coder en div”), balise qui ne signifie et ne représente rien. Que ce soit le header, le footer ou la sidebar, n’ayant pas autre chose sous la main, on utilise des <div> par défaut, auxquelles on applique des id spécifiques.
Le HTML 5 corrigera tout ça. On aura droit à des nouvelles balises très utiles :
La structure d’une page pourra ressembler à ceci :
<body>
<header>Bienvenue</header>
<nav>Accueil - A Propos - Contact</nav>
<article>
<section>
Prémices du HTML 5
</section>
</article>
<aside>Catégories</aside>
<footer>bbxdesign 2008</footer>
</body>Plus léger et plus lisible. Il faut noter que dans sa syntaxe, une balise <article> pourra regrouper plusieurs balises <section>, ces dernières correspondants à des sous-parties d’un article.
L’intérêt n’est pas seulement pour l’intégrateur du site, mais aussi au niveau des moteurs de recherches. A l’heure actuelle, un moteur ne peut en aucun cas savoir que différentes parties existent dans une page. Il ne peut pas hiérarchiser ou utiliser ces parties.
Ces véritables balises de page pourront le permettre. Ensuite, libre alors aux moteurs de les interpréter à leur façon.
Question accessibilité, ces balises seront très utiles. La page étant bien hiérarchisée, on pourra facilement naviguer et sauter des parties, aller d’une section à une autre… Il suffira d’adapter les outils à cette nouvelle structure.
Lorsqu’il s’agit d’audio ou de vidéo dans les pages web, on pense tout de suite et exclusivement au lecteur Flash. Il s’est imposé par sa légèreté, ses fonctionnalités (streaming, multimédia…), son design. C’est tout simplement le seul moyen de partager de l’audio et de la vidéo facilement, avec des unités de contrôle, et une grande rapidité.
HTML 5 proposera une alternative grâce à ses balises <video> et <audio>. Par exemple, pour la vidéo on pourra définir :
Bref, ça sera le strict minimum, histoire d’avoir la possibilité de lire des fichiers multimédia sans passer par Flash (surtout lorsqu’on ne le maîtrise pas).
Un petit tour sur le site du W3C permet de connaître quelques autres nouvelles balises qui vont venir enrichir le panel :
La liste des balises (et des attributs) s’agrandit pour mieux nous aider en tant que développeurs (facilité, flexibilité, lisibilité) mais aussi en tant qu’utilisateurs (accessibilité, intéraction, simplicité).
Sources : A Preview of HTML 5 , HTML 5 differences from HTML 4
@denisdkr Y a des plugins "Retard" et "Avis de grève" aussi ? — il y a 34 min