Publié par

Il y a 9 années -

Temps de lecture 16 minutes

HTML5 – Les nouveaux éléments

Comme évoqué dans une précédente revue de presse, voici le premier article de ma série sur HTML5. Plutôt que de faire du comptage de points entre Apple et Adobe, j’ai décidé de commencer par faire un tour d’horizon des nouveautés proposées par cette nouvelle spécification du W3C. Dans ce premier article, je vous propose donc de faire un voyage à la découverte des nouveautés du côté de HTML. ; pour connaître les nouvelles balises, et les nouveaux attributs que nous pouvons déjà ou pourrons bientôt utiliser dans nos navigateurs. Du layout au canvas en passant par les WebForms, le son et la vidéo, tout tout tout, je vous dirai tout sur HTML5. Commençons donc par le commencement: HTML5 qu’est-ce que c’est ?

Sommaire

HTML5 ?

HTML5 est au départ la nouvelle version du langage HTML en cours de développement par le W3C. Pour le moment, il s’agit d’une recommandation en DRAFT, fruit du travail initial réalisé par le WHATWG depuis 2004. Le W3C espère en faire un de ses standards libres aux alentours de 2022. De prime abord, ça nous laisse le temps de réfléchir au problème pendant les 10 prochaines années. L’idée d’une nouvelle version de HTML serait motivée par quelques constats simples :

  • Les navigateurs ont besoin de plugins pour gérer le multimédia (flash et consorts)
  • La structure des documents n’est pas intuitive et rend l’accessibilité difficile
  • Les API JavaScript varient trop d’un navigateur à l’autre pour garantir la portabilité des documents
  • Les sites sont de plus en plus proches des applications de bureaux mais souffrent encore de limitations

Pour répondre à ces problématiques et favoriser l’émergence du web sémantique, la spécification propose :

  • Un nouveau modèle de contenu des éléments
  • Des éléments de mise en page
  • De nouveaux éléments pour les formulaires
  • Du contenu multimédia
  • Plus d’interactivité
  • Des APIs standards JavaScript

Bien que la spécification soit encore en cours d’écriture, certaines parties sont déjà très avancées et les navigateurs ont tous commencé à les implémenter. Google Chrome est actuellement en tête. Il bénéficie nativement de Gears et respecte 87% de la spécification. Parmi les principaux supporters de ce standard en devenir, nous retrouvons Google, Mozilla, Opera, Apple et Palm, pour ne citer que les plus grands. Apparemment, les navigateurs qui ont le vent en poupe sont tous de la partie. Microsoft, de son côté, suit la tendance de très loin en intégrant des fonctionnalités au compte goutte dans son IE, qui supporte tout de même 28% du langage.

Nouveau modèle de contenu

Bye, bye, les alignements hasardeux dus aux éléments de type bloc ou en ligne. Les éléments seront plutôt classés par catégories.

contenthtml5
  • La catégorie ancêtre Flow correspond à tous les éléments qui contiennent un flot de texte
  • Phrasing correspond aux éléments qui apparaissent dans le texte (a, li)
  • Interactive définit les éléments qui fournissent une interaction avec l’utilisateur
  • Embedded affiche des ressource externes dans le document
  • Les Metadata représentent tout ce qui n’est pas affiché (style, script, …)
  • Heading définit les en-têtes d’une section
  • Sectioning définit le scope des en-têtes et pieds de page

Toutes ces catégories permettent de définir le contenu autorisé pour les éléments. Leur but est d’une part de fournir une grande souplesse de composition (par exemple la balise a peut maintenant contenir un paragraphe entier, une liste ou des headers (h*)), d’autre part ces catégories permettent aux navigateurs d’assimiler le contenu de la page, notamment pour les exports d’impression ou l’accessibilité.

Nouveaux éléments de mise en page

Jusqu’à maintenant, l’élément de mise en page par excellence était la balise div. La grande majorité des sites est construite sur un modèle d’empilement de ces boites avec des id différents pour finir par une grosse partie de styles CSS assurant le positionnement. Mais cela a quelques inconvénients:

  • Ce n’est pas intuitif pour le développeur, vous en conviendrez.
  • Le navigateur ne peut pas connaître le rôle de chacune des parties de la mise en page, ce qui rend beaucoup plus difficile la génération de plan ou d’aide à la navigation.
layoutHTML4 layoutHTML5

Les balises article, section, header et footer indiquent clairement à quel type de texte elles correspondent et comment s’organise leur contenu. La balise aside définit un contenu lié au sujet principal, sans en faire partie pour autant. Reste le tag nav qui est prévu pour servir les liens de navigations de la page comme un menu par exemple. La mise en page proposée ci-dessus ne révèle pas la flexibilité d’utilisation de ces éléments. Notez bien que les article et section peuvent avoir leur propre header et footer.

Avec ces nouvelles balises, nous serons enfin capables de gérer l’organisation de nos documents de façon intuitive et les navigateurs pourront générer le plan des documents eux-mêmes. L’algorithme nécessaire est d’ailleurs décrit dans la spécification. Tous ces éléments sont déjà supportés nativement par les navigateurs avec l’exception habituelle de IE pour lequel il existe un workaround JavaScript. Vous pouvez dès maintenant vous familiariser avec ces nouvelles balises sans avoir peur des problèmes de compatibilité.

Eléments interactifs

Sous ce terme limpide se cachent les éléments qui fournissent de l’interaction utilisateur dans la page. Ce qui correspond aux Interactive elements de la spécification. La grosse nouveauté ici est la définition d’une balise menu permettant de construire des barres de menu (type="toolbar"), des menus contextuels (type="context") ou de simples listes de commandes. Un tag menu peut contenir des sous-menus et se compose d’éléments permettant de lancer des commandes.


 
  • Pour les commandes, HTML5 propose directement un élément command qui permet d’associer un texte ou icône à une exécution JavaScript sur événement onclick="alert('hello world')". Pour utiliser le menu contextuel, il suffit d’ajouter l’attribut contextmenu="menu_id", sur l’élément qui doit utiliser le menu.

    L’autre nouveauté parmi les éléments interactifs est la balise details. Le fonctionnement de ce tag est proche d’un menu en accordéon, avec une partie de texte toujours affichée et une partie cachée pouvant être rendue visible sur demande de l’utilisateur. Cela peut être utile, pour cacher des options avancées par exemple.

    Copying "Really Achieving Your Childhood Dreams"

    Copying... 25%
    Transfer rate:
    452KB/s
    Local filename:
    /home/rpausch/raycd.m4v
    Remote filename:
    /var/www/lectures/raycd.m4v

    Ici, le tag details est utilisé pour cacher les informations techniques d’une copie. Vous noterez au passage l’utilisation d’une balise progress, pour afficher une barre d’avancement.

    Les WebForms

    Nouveaux input

    Les formulaires aussi profitent de la mise à jour en reprenant en partie XForms pour les connaisseurs. Le principe est de fournir des input fortement typés ainsi qu’une API JavaScript de validation en plus d’une interactivité accrue. Parmi les nouveaux types d’input, il y a :

    • Le support des saisies de dates et heure décliné sous plusieurs formes (date, datetime, datetime-local, month, week, time). Nous n’aurons donc plus besoin des widgets supplémentaires JavaScript pour générer des calendriers.
    • La saisie de formats numériques via les number et les range qui pourront prendre la forme d’un slider vertical ou horizontal
    • Différents types de chaînes formatées comme les url, les email et tel
    • Le selecteur de couleur color
    • Le champ de recherche search

    Les anciens types sont maintenus. Ils bénéficient d’un bon lifting, tel le type file qui permettra désormais de sélectionner plusieurs fichiers d’un seul coup, tout en précisant le type mime accepté. Il y a aussi l’attribut placeHolder qui permet de fournir un texte descriptif affiché dans le champs si il n’est pas renseigné.

    Validation native

    Tous les input supportent de nouveaux attributs de validation qui permettent de contraindre les saisies de l’utilisateur, et peuvent interdire la soumission du formulaire, s’il n’est pas valide. Encore une fois, cela permettra de remplacer des solutions hétérogènes JavaScript par un standard nativement supporté par le navigateur. La validation s’accompagne aussi de nouveaux évènements DOM pour notifier les erreurs ou surcharger la validation avec son propre code JavaScript. Plus besoin non plus de jouer avec les classes CSS pour faire ressortir les champs en erreur grâce aux pseudo-formats (:invalid, :valid, :Out-of-range, …).

    Des validateurs par défaut sont fournis sous la forme de nouveaux attributs à placer sur les input :

    • required pour un champ requis
    • min et max permettent de définir une valeur minimum et maximum sur les types numérique et date
    • pattern fournit une expression régulière que la saisie doit respecter

    Auto-complétion

    Autre nouveauté inspirée des widgets JavaScript existant, les datalist sont des listes de valeurs construites à l’aide d’éléments de type liste (li, option, …). La datalist est transparente par défaut mais elle peut-être liée à un ou plusieurs input avec l’attribut list. Une fois l’association établie avec un input, la liste est utilisée pour fournir des suggestions à la saisie. Les éléments à l’intérieur de la liste peuvent-être décorés par CSS directement.

    
    
       
  • Designer
  • Integrateur
  • Programmeur
  • Répétitions

    Une autre évolution sympathique est la création d’un système de template, facilitant la création de formulaire dynamique. Dans les applications de gestion, il est souvent utile de pouvoir ajouter et supprimer des lignes de saisie dans le formulaire. Le système de répétition est fait pour ça. Je peux définir un bloc comme étant mon template, et le contenu de cet élément pourra être dupliqué via une API JavaScript.

    
       
       
       
    
    

    C’est l’attribut repeat qui définit notre bloc de répétition, le repeat-start permet de gérer les aller-retour serveur, pour afficher la liste avec le nombre d’éléments précédemment soumis. Pour assurer l’ajout et la suppression de ligne, j’ai utilisé les boutons de type add et remove mais j’aurais aussi bien pu utiliser des méthodes JavaScript de l’élément template addRepetitionBlock(). Il y a aussi des solutions pour gérer l’ordre des répétitions permettant de monter et descendre les lignes répétées.

    Etat des lieux

    Voilà la promesse d’un monde meilleur dans lequel nous aurons moins de travail à fournir (CSS, JS) pour obtenir des résultats simplement meilleurs. Notez une dernière chose, les input peuvent être liés à un ou plusieurs formulaires via le nouvel attribut form. En d’autres termes, il sera possible de placer nos input pour un formulaire à l’extérieur de ce dernier.

    Comme vous l’avez remarqué, j’ai utilisé le futur dans ce paragraphe car pour le moment seul Opera 9 supporte nativement les WebForms. Pour permettre aux développeurs de s’y essayer et valider la spécification, le projet WebForms2 propose une implémentation partielle en JavaScript. La spécification au départ avait été séparée du langage HTML5, mais le W3C a décidé de la ré-intégrer en y apportant des modifications. Du coup la plupart des fonctions développées sont liées à une ancienne version des WebForms.

    Pour les autres navigateurs, notez tout de même que les développements ont déjà commencé. Par exemple Chrome 5 devrait être livré avec le support des nouveaux input et l’API de validation(Chrome Web Platform Status). Safari bénéficie du même support que chrome qui se limite aux types search, range et file multiple. Du côté de Firefox, les choses sont moins claires ; il existe bien un ensemble de bugs pour le support des WebForms mais Mozilla communique peu sur le sujet. Actuellement, Internet Explorer 8 ne supporte aucune des ces nouveautés et il est impossible de connaître la roadmap de Microsoft sur le sujet. Tout ce que l’on sait, c’est que l’éditeur a décidé de mettre les bouchées doubles pour améliorer son support des travaux du W3C. Peut-être une bonne solution pour inverser la vapeur et en finir avec la descente aux enfers de son précieux navigateur.

    Page de démonstration pour Chrome, Safari et Opera.

    Multimedia

    Il est temps de parler des nouveaux types de contenu poussés par HTML5. Les auteurs du whatwg se sont probablement demandé pourquoi doit-on installer des plugins dans nos navigateurs ? Nous savons a priori tous aujourd’hui que Flash est utilisé principalement pour 3 choses dans les applications :

    • Pouvoir écouter de la musique
    • Pouvoir regarder des vidéos
    • Faire des animations de folies

    J’ai mis volontairement de côté Flex car il cible plutôt les applications d’entreprise, et les jeux Flash car le Boss ne veut pas en entendre parler ;-). Sachez, si vous êtes passé à côté de ça, que HTML5 adresse ces trois problématiques en sortant trois nouvelles balises de son chapeau :

    • audio permet de gérer la lecture de fichiers audio en streaming.
    • video assure la lecture de vidéos en streaming toujours.
    • canvas permet de dessiner et de faire des animations en JavaScript.

    Audio et Video

    Jusqu’à maintenant, les gros avantages de la technologie d’Adobe sont la portabilité puisque Flash est disponible pour tous les navigateurs, et la performance en comparaison avec les moteurs JavaScript. Il est clair que ces trois balises viennent marcher sur les plate-bandes de Flash. Les éléments média disposent des attributs :

    • controls pour activer l’affichage de l’interface de contrôle du navigateur
    • autobuffer pour activer le chargement automatique de la ressource en cache
    • autoplay pour activer le lancement automatique de la lecture
    • loop pour lire le ou les médias en boucle
    • src pour fournir l’url du fichier média à lire

    La balise source placée à l’intérieure d’une balise audio ou video permet aussi de définir l’url (@src), le type mime et le codec (@type) d’une ressource média. Il suffit de mettre plusieurs source pour créer une playlist.

    
    
    

    Si le navigateurs n’arrivent pas à lire le fichier ogg, il tentera de lire le fichier H.264. De même, si le navigateur ne supporte pas l’élément video, il affichera le texte alternatif. Il suffit donc de placer un lecteur Flash à la place du texte pour que la vidéo reste lisible dans un ancien navigateur.

    Si vous ne voulez pas utiliser l’interface native, ou que vous souhaitez simplement cacher le lecteur audio, vous pouvez utiliser l’API standard JavaScript pour créer un lecteur, et profiter des méthodes play(), pause(), et load() pour charger la prochaine ressource média. Une dernière méthode : canPlayType(type), permet de demander au navigateur si il supporte le format vidéo ou audio fournit en paramètre. Cela sera très utile pour gérer les incompatibilités de format.

    De plus l’interface HTMLMediaElement fournit quantité de propriétés allant du volume à l’état du buffer en passant par le temps de lecture courant. Le tout est, bien sûr, accompagné d’une batterie d’événements qui permettent de suivre l’avancement du chargement, l’état du lecteur, et les action lancées par l’utilisateur.

    Pour plus de détail sur le sujet, je vous invite à lire la spécification W3C des éléments média et à tester la démo de jPlayer un lecteur audio pour jQuery.

    La guerre des Codecs

    Venons en au problème des codecs. Le W3C se contente de citer un certain nombre de formats allant du H.264 au DIRAC pour la vidéo en passant par mpeg-4 et Theora; même chose pour l’audio avec AAC, FLAC, Vorbis, … La spécification laisse le libre choix aux navigateurs et table sur la création d’extensions propres à ces derniers pour apporter le support de nouveaux formats. Si aujourd’hui YouTube et Vimeo ont choisi le H.264, DailyMotion joue les fidèles Mozilla avec sa démo basée sur Ogg et ne supportant que Firefox.

    Chrome et Safari poussent H.264 tandis que Mozilla le rejette totalement et pousse les formats libres Vorbis et Theora (Ogg). Le gros avantage d’H.264, à mon sens, tient au fait qu’il est parfaitement adapté à l’embarqué et beaucoup plus optimisé que Theora. Malgré le barrage de Firefox (25% de parts de marché), avec Apple et Google le codec H.264 semble avoir de beaux jours devant lui. Google qui est justement le plus gros contributeur de Mozilla, fournira peut-être une extension, sinon ce sera probablement du codec pack pour tous.

    Codecs supportés par navigateurs

    Navigateur Ogg MP3 WAV MP4
    Firefox 3.5 Ok Ok
    Safari 4 Ok Ok Ok
    Chrome 3 Ok Ok Ok
    Opera 10 Ok
    IE

    Internet Explorer est pour le moment hors-jeu, sauf si on installe Google Chrome Frame. Mais il semblerait que Microsoft s’intéresse au sujet pour l’avenir et participe à la rédaction de la spécification. En attendant, Flash conserve une avance confortable et profite de sa très large base installée. Le changement arrive bizarrement par l’embarqué, iPhone et iPod Touch en tête, qui, d’une part, supportent pleinement les balises audio, et video, et d’autre part prouvent que les utilisateurs peuvent se passer de Flash sur le web.

    Le Canvas

    Passons maintenant au canvas. Inventé par Apple pour le Dashboard d’OS X et ses widgets, le canvas fournit une API JavaScript pour le dessin 2D. La balise définit une aire de dessins avec sa hauteur et sa largeur. L’objet DOM donne accès au contexte graphique qui possède les primitives de dessins. Outre les formes géométriques standards, l’API permet de faire de la composition, des transformations, de manipuler des images et d’afficher du texte formaté. Avec un timeout ou un intervalle sur l’objet et un peu de JavaScript, il devient possible d’animer les dessins. Les implémentations ne sont pas encore très optimisées. Un simple gif animé reste pour le moment plus performant en terme d’animation. Il existe déjà un tas de librairie JS construites autour de l’élément canvas pour générer des graphes et des charts par exemple (Flotr, ProtoChart, fgCharting).

    Browser does not support the canvas element.
    
    

    Les détracteurs déplorent l’utilisation d’une API procédurale, et l’absence d’éléments crées dans l’arbre DOM de la page comme le fait SVG. Autre inconvénient, canvas travaille la composition directement en pixels et non en calques. SVCKit a donc implémenté en grande partie SVG dans canvas dans SVGCanvas. Il existe déjà beaucoup de documentations et tutoriels autour de canvas qui rencontre, malgré ses défauts (de jeunesse ?), un grand succès. Mozilla a même développé un IDE en ligne basé sur canvas, nom de code : BeSpin.

    Voilà pour les domaines d’application, passons maintenant à la question des navigateurs. Avec Apple pour inventeur et Mozilla comme évangéliste, canvas est déjà supporté nativement sur Safari, Firefox, Chrome et Opéra. Comme d’habitude IE est à la traine, mais il existe des contournements comme le plugin IECanvas, ou le portage Flash ExplorerCanvas.

    Conclusion

    Nous voici à la fin de ce tour d’horizon des nouveautés d’HTML5, côté contenu du moins.
    Avec les grands du web dans la poche, HTML5 est déjà promis à un bel avenir, malgré son jeune age. La prochaine échéance du W3C devrait être le passage en recommandation dans le courant de cette année peut-être. Si les WebForms ne sont pas pour tout de suite, le multimédia et le canvas sont déjà suffisamment supportés pour être utilisés aujourd’hui. Il faudra attendre la sortie d’IE 9 pour connaître les plans concrets de Microsoft sur le sujet. A mon humble avis, Microsoft intégrera HTML5 au fur et à mesure qu’il s’imposera sur le web. Il faudra aussi regarder de près l’évolution du standard CSS car HTML5 ne va pas sans CSS3. De ce côté, pas de crainte à avoir puisque même IE est dans la course.

    Il reste un problème d’outillage, car il n’existe pas pour le moment de WYSIWYG compatible HTML5. Et il ne faut sans doute pas compter sur Adobe pour le faire rapidement. Apple propose déjà DashCode pour créer des widgets ou des applications web iPhone avec un éditeur graphique bien monté. Mais l’export vers d’autres navigateurs est presque impossible tant les applications construites reposent sur des fonctionnalités spécifiques de Safari.

    Dans le prochain article, je vous présenterai les nouveautés JavaScript poussées par HTML5 et leur état actuel d’implémentation.

    Publié par

    Commentaire

    9 réponses pour " HTML5 – Les nouveaux éléments "

    1. Publié par , Il y a 9 années

      Merci pour ce tour d’horizon très intéressant. Sur la question des codecs le rachat par Google de On2 (http://techcrunch.com/2009/08/05/google-acquires-video-compression-technology-company-on2-for-106-million/) pourrait changer la donne et permettre de dépasser la gueguerre entre H264 et OGG. Sinon j’ai peur que cela fragmente le web vidéo cette histoire de support optionnel.

      Une question précise : est-ce que HTML5 me permettra par exemple d’avoir un bouton de formulaire complètement personnalisé sans sacrifier l’accessibilité et sans avoir à coder du CSS/Javascript en pagaille ? Aujourd’hui une simple recherche montre qu’il n’y a pas de solution 100% satisfaisantes. Je me pose donc pour le développement d’application d’entreprises on est encore loin ou HTML5 peut faire une vraie différence ?

    2. Publié par , Il y a 9 années

      Sur le rachat de On2 par Google, j’avoue que la nouvelle est intéressante. Mais il est encore trop tôt pour en tirer des conclusions. Il faudra un consensus entre les différents acteurs du marché pour avoir enfin un Codec utilisable par tous. L’avantage pour le moment est clairement à H.264 puisqu’Apple, Google et Adobe, l’utilisent déjà. Il y aura du temps avant que Google ne réussissent à positionner ce nouveau Codec comme standard. Il faudra d’abord le libérer pour pouvoir faire rentrer Mozilla dans la danse. Cela dit, j’espère aussi que cela pourra mettre fin à la guerre des codecs.

      Concernant la personnalisation des boutons, il faut composer avec le nouveau standard CSS3. Donc, il y a bien du CSS et/ou du JavaScript. Tant qu’il n’y aura pas d’outils graphique avancé pour créer les CSS des boutons, il y aura du code à écrire. HTML5 n’est clairement pas, aujourd’hui, une concurrence pour les applications d’entreprise type Flex.

    3. Publié par , Il y a 9 années

      Merci Jérémy pour ce « petit détail », j’ai supprimé les espaces surnuméraires.

    4. Publié par , Il y a 9 années

      Ah ! L’un des articles les plus intéressants qui m’ait été donné de lire sur le sujet.

      « HTML5 ne va pas sans CSS 3 » : ben pourquoi ? Ça n’a rien à voir. Et CSS3 c’est sans espace aussi. Nananère…

    5. Publié par , Il y a 9 années

      Ben merde alors ! Mon nom c’est Le Mesle aussi !!!
      On est de la même famille ?

    6. Publié par , Il y a 9 années

      @Philippe
      Décidément c’est le festival des espaces cher homonyme ;-). Pour en revenir à CSS3, ça n’a peut-être rien à voir, mais pour citer les inconnus, une page HTML sans CSS, c’est un peu comme un chagrin d’amour:
      La mer sans les vagues, les vagues sans l’écume, l’écume sans le sel, et le sel sans le poivre.
      HTML5 seul ne permettra pas de concurrencer les applications lourdes, il faut du style et un look’n’feel agréable, et c’est précisément ce que fait CSS3.
      Cela dit, les spécifications sont bien séparées et n’ont donc pas de rapport direct.

    7. Publié par , Il y a 9 années

      Très bon article qui ouvre de nombreuses perspectives pour les futures applications Web.
      Justement je me dis que notre projet d’ouvrir le code de la Tomosfactory (CMS web2.0) devrait être l’occasion de tout en réécrire en HTML5.

      Greg

    8. Publié par , Il y a 9 années

      Bonjour,

      J’ai du mal à comprendre le « classement » des éléments dans chaque catégorie. Chaque élément n’a plus par défaut un comportement « block » ou « inline » ? Comment les change t’on de catégories ?

      J’ai beaucoup vu ce schéma mais j’aimerai bien qu’on me l’explique.

      Merci pour vos explications et bravo pour cet article très complet

      Raphael

    Laisser un commentaire

    Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

    Nous recrutons

    Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.