HTML5
Il est fréquent d’entendre parler de html5 et il est également fréquent d’entendre certaines polémiques quant à son utilisation.
Notamment, à propos de sa non prise en compte par certains navigateurs, ou encore sur le fait qu’un grand nombre de recommandations ne soient pas encore fermement annoncées…
Qu’en est-il réellement ? Ce langage, et les technologies qui l’accompagne, ne sont-ils pas encore prêts à être employés pour concevoir nos sites web ? Sommes-nous marginaux et irresponsables si nous l’utilisons ?
C’est à ce type de questions que cet article va essayer, non pas de répondre mais, d’apporter suffisamment d’éléments, afin de pouvoir d’une part, utiliser HTML5 et d’autre part, permettre à chacun, de prendre le recul nécessaire, et de pouvoir faire sa propre analyse.
Est-ce là une énième version du langage ?
Contrairement aux anciennes évolutions, comme par exemple avec celle de xhtml 1.0, il ne s’agit pas là d’un simple changement de DTD complété par l’apparition d’une paire de balises nouvelles… le changement est bien plus profond et surtout bien plus large… tellement large que l’évolution des recommandations qui en découle, ne pourra se faire qu’au travers d’un découpage modulaire de l’ensemble, et au coup par coup.
Ainsi, html5 arrive avec des avancées autant sur la DTD, qui se veut résolument structurante et sémantique, que sur les API intégrées aux navigateurs. Ces API couvrent les principaux besoins des utilisateurs et des applications web modernes : prise en compte de la mémoire cache, de l’historique de navigation, de la géolocalisation utilisateur, optimisation de la gestion des données, implémentation du glissé-déposé… etc… etc…
Et surtout, avec une approche des recommandations qui se veut radicalement nouvelle, en apportant cette fois-ci une écoute des développeurs qui répondent aux besoins du web, sans imposer un choix éditeur. Les recommandations ne seront plus un choix dicté par une bureaucratie, mais plutôt le reflet direct de ce que les développeurs, sous la demande des utilisateurs, auront mis en place et utiliseront.
En conclusion sur l’approche, nous pourrions dire que html5 est venu poser sa ‘marque de fabrique’ sur un nouvel esprit de construction, englobant non seulement la structure et la sémantique des balises, mais aussi la prise en compte des styles CSS de niveau 3 et 4, et la gestion et l’intégration des API nativement embarquées dans les navigateurs modernes. Le tout, sans perdre de vue les diverses possibilités qui permettent de rendre portable l’ensemble des utilisations sur tous les navigateurs contemporains, mais également plus anciens. Bref, c’est à une véritable remise en question, quant à l’approche du développement d’applications web, que html5 nous convie.
Présentation du document
Fini le <!doctype> compliqué à écrire et à mémoriser. Il suffit dorénavant de le définir, sans préciser de DTD, de versions ou quelque catégorie que ce soit. Il est vrai que les navigateurs ne consultent pas les DTD et du fait que HTML5 se veut compatible avec les versions antérieures, HTML6 se voudra forcément compatible avec HTML5, donc pas de version nécessaire en déclaration.
Dans certains cas, il est intéressant de définir l’attribut lang de la balise <html>, mais c’est là une déclaration facultative. De même, la balise <meta> a été réduite à sa plus simple expression. Seule la définition de l’encodage du document est présente. Généralement utf-8 est utilisé, mais attention, encore une fois il ne s’agit pas de simplement déclarer l’encodage, encore faut-il que le document lui-même soit encodé de la sorte.
<!doctype html>
<html lang="">
<head>
<meta charset="utf-8">
<title>Untitled Document</title>
</head>
<body>
</body>
</html>
Structure et sémantique
Principes et intérêts
Le langage HTML est un langage à balises qui découpe et structure l’information. Mais pour le navigateur qui parcourt l’ensemble de la page, le contenu ne prend un sens structuré que lorsque les balises qui le définissent sont suffisamment explicites. En clair, le code suivant n’indique rien sur la nature du contenu :
<div>
<div>
<div>Duis aute irure dolor in reprehenderit.<div>
<div><span>Ut labore et dolore magna aliqua.</span> Excepteur sint.</div>
</div>
</div>
Si l’on souhaite permettre non seulement aux utilisateurs, mais également aux outils et applications tierces de pouvoir interagir avec ces contenus, il est très important d’être explicite sur la nature même et le sens de ces contenus, au travers des noms de balises employées pour la découpe. HTML4 était peu sémantique par nature. Il possédait quelques niveaux de titres et certains éléments de découpe, mais en dehors de ces quelques balises, il n’était pas possible de pouvoir distinguer les éléments de navigations, des éléments d’entête… ou encore d’éléments complémentaires au contenu… HTML5 permet dorénavant d’aller plus loin dans cette direction.
<section>
<article>
<header>Duis aute irure dolor in reprehenderit.<header>
<aside><mark>Ut labore et dolore magna aliqua.</mark> Excepteur sint.</aside>
</article>
</section>
Bien qu’il s’agisse là d’une grande avancée, certains peuvent rester sur leur faim. Il est vrai qu’entre autre par exemple, il est apparu la balise <nav>, qui permet donc comme son nom l’indique, de distinguer des éléments de navigation… mais rien ne précise s’il s’agit d’une navigation principale, d’un menu secondaire, ou encore d’un menu contextuel. De ce fait, les lecteurs d’écrans peuvent ne pas être plus informés que par le passé. De plus, cette nouvelle grille de balises ‘sémantiques’ se retrouve forcément limitée et risque de ce fait, de ne pas pouvoir répondre à toutes les attentes. Comme John Allsopp le souligne dans son excellent article Semantics in HTML5, il eût été préférable d’accéder à un nouvel attribut structure="", un peu à la manière de aria-role (voir plus loin).
Structure
En résumé, il nous faut entendre par structure, l’art et la manière d’imbriquer les éléments de contenu entre eux, afin de donner du sens et de la cohésion à l’ensemble. L’objectif final est de pouvoir très simplement mutualiser tout ou partie, de facilement déplacer des parties dans l’arborescence du document sans remettre en question l’équilibre global, de moduler de manière optimale chaque sous-partie… bref, d’accroître la flexibilité générale de l’ensemble de ce contenu. Des contenus qui sont trop alambiqués, deviennent rapidement rigides et ne permettent pas de réelles souplesses d’utilisation.
Il nous faut garder à l’esprit, qu’aujourd’hui, encore bien des sites sont construits sur des structures extrêmement lourdes et rigides. Il faut donc penser à revoir sa copie et à structurer de manière simple, en n’hésitant pas à s’arrêter à l’essentiel, sans surcharge inutile et en évitant tout ajout qui ne soit pas uniquement lié à la gestion de l’affichage… Rappelez-vous l’utilisation classique des fameuses balises englobantes <div class="maincontent">, ou encore les ancestrales divites toujours d’actualité, qui donnent l’impression de faciliter la mise en place d’un style visuel complexe, tout en engorgeant la structure…
<div class="parent"> <div class="sous parent"> <aside> </aside> </div> </div>
Sémantique
De même, il nous faut entendre par sémantique, la possibilité qu’une application tierce puisse comprendre la nature du contenu quelle parcourt. Il est vrai que pour nous ‘humains’ le simple fait de voir un texte en gras et en taille de caractères imposants, nous laisse présumer d’un titre. Mais à regarder sous le capot, et en fonction des balises HTML employées, un user agent ne ferait pas la même distinction entre les deux lignes de code suivantes, et ce, même si le visuel rendu par les CSS peut être identique ;
<p class="titre">Le titre</p> <h1>Le titre</h1>
Au delà des titres et des paragraphes, HTML5 arrive avec un grand nombre de balises structurantes et sémantiques : par exemple, il est dorénavant très facile et surtout possible d’éviter ce genre de construction, qui pour un user agent ne représente qu’une image imbriquée dans des balises de découpes blocs, donc sans connotation ou sens particulier :
<div> <div class="image"> <img src="image.jpg> <div class="legende">Un texte</div> </div> </div>
En lui préférant cette construction, le sens de cette image devient plus clair, il s’agit en fait d’une figure accompagnée de sa légende ;
<figure> <img src="image.jpg> <figcaption>Un texte</figcaption> </figure>
Aller plus loin avec la description de l’information
Un grand nombre d’informations ne peut être décrit exclusivement au travers de balises. Prenons par exemple l’identification d’une entreprise, d’un produit, d’une personne, etc… il ne serait pas envisageable de mettre en place des balises <nom>, <prenom>, <modele>, <productID>, <email>, <fax>, <description>…. etc… et pourtant, depuis HTML4 déjà, il existe des solutions afin de pouvoir marquer des éléments de la sorte, et surtout qui puissent être interprétés par des applications tierces. HTML5 est venu confirmer et améliorer leur implémentation. Il existe diverses possibilités, toutes complémentaires et cumulables…
Les microformats
Déjà utilisés en complément des descriptions HTML4, les microformats reprennent du service avec cette nouvelle version de HTML et confirment leur importance. Ce standard se base sur des standards de description déjà existants, comme hcard, hcalendar,…, qui permettent de définir les fiches de présentation, les calendriers… entre autres. Donc, plutôt que de créer de nouveaux modes de description, et de réinventer l’eau chaude, les microformats réemploient et propulsent l’utilisation de ces standards directement dans notre balisage HTML, en utilisant l’attribut class.
<div class="vcard">
<h3 class="org">Puce et Média</h3>
<p class="street-address">1 impasse de la pie </p>
<p class="locality">Jouques</p>
<p class="postal-code">13 490</p>
<p class="country-name">France</p>
</div>
Simple non ! Bon, le travail de codage est terminé, reste encore que les navigateurs, ou les applications lectrices, puissent l’interpréter. Pour cela, nous allons équiper le navigateur d’une extension sympa… un script lecteur de microformats. Il en existe plusieurs sortes et ce en fonction du navigateur utilisé… chrome, firefox, safari, internet explorer…, aucun n’est mis sur la touche. Repérez votre extension, installez-là et rendez-vous par exemple sur le site de la galerie photo des fondamentaux d’AJAX par la pratique… Dans le pied de page, vous devriez voir apparaître le logo >>>HCARD vous proposant un tierce service, mis en place au travers des microformats.
Les micros-datas
Les micro-datas vont, eux, s’appuyer sur la mise en place d’un ensemble d’attributs qui lui est propre : itemscope, itemtype, itemprop… etc… Ces attributs permettent de définir la portée, le type et le contenu de description d’une ou plusieurs balises HTML. Afin de préserver une cohérence d’interopérabilité, un ensemble de schémas organisés a été mis en place. Ainsi, qu’il s’agisse d’une personne, d’une organisation, d’un objet, d’un lieu, etc… il est très facile de pouvoir répondre aux principales attentes de description. Pour mieux comprendre le principe et le fonctionnement des micro-datas, le plus simple est de se baser sur un exemple de code beaucoup plus parlant :
<div itemscope itemtype="http://schema.org/CreativeWork" > <p itemprop="name">Responsive Web Design avec HTML5 et CSS3</p> <p itemprop="author">Bruno Sébarte</p> <p itemprop="editor">video2brain</p> <p itemprop="url">http://www.video2brain.com/fr/formation/responsive-web-design-avec-html5-et-css3</p> </div>
Il suffit alors de se rendre sur la page de description de CreativeWork et on peut voir directement l’ensemble des propriétés auxquelles nous avons accès pour ce type d’objet. Une fois votre page renseignée et publiée, vous pouvez aussi tester son interprétation et sa lisibilité, depuis un des outils pour les webmasters : Outils de test des données structurées.
Les attributs data-*
Dans la lignée des micro-datas, l’attribut data-* nous ouvre les portes sur l’utilisation d’attributs spécifiques et personnels, tout en restant dans un code HTML valide. Il est donc possible de créer un attribut datas-nom et datas-prenom, tout en restant valide. Il est également possible de passer tout type de valeur pour cet attribut. Ainsi un objet littéral est complètement envisageable. Par exemple, data-configuration:"{valeurs}" n’est pas impossible. En complément de l’attribut data-*, il existe également un objet dataset accessible depuis javascript.
A titre d’exemple, nous pourrions avoir dans la partie HTML :
<article id="indentifiant" data-configuration="{'font':'verdana','size':'12pt'}">
Ullamco laboris nisi velit esse cillum dolore cupidatat non proident.
</article>
Et dans le script en entête du fichier :
<script>
window.onload = function(){
var ref = document.getElementById('indentifiant')
var valeur = ref.dataset.configuration
valeur = eval('(' + valeur + ')')
valeur = valeur.font
alert(dt)
}
</script>
Aria-role
Bon, aborder ARIA en un seul petit paragraphe, c’est un peu… même beaucoup… osé, alors, de manière courte, nous pourrions dire qu’ARIA a pour objectif d’augmenter l’accessibilité des contenus et des applications web. Par exemple, lors de la mise en place d’un composant interactif HTML, on manque d’outils et de marqueurs sémantiques : combler ce fossé est quelque part le rôle et l’objectif d’ARIA. Justement, ARIA est souvent associé à l’un de ses attributs phares, l’attribut role, qui va nous permettre de renseigner sur le rôle de la balise à laquelle il est affecté. De ce fait, là où nous avions lors d’une crise de divite aiguë :
<div>
<ul>
<li>A</li>
<li>B</li>
</ul>
<div>Contenu du A</div>
<div>Contenu du B</div>
</div>
… composé uniquement de code assez générique et pas trop explicite, nous pourrions avoir avec l’aide des attributs propres à ARIA, un code certes plus verbeux, mais grandement plus compréhensible et basé sur du standard :
<div>
<ul role="tablist">
<li id="tab_1" role="tab" tabindex="0">A</li>
<li id="tab_2" role="tab" tabindex="-1">B</li>
</ul>
<div role="tabpanel" aria-labelledby="tab_1" aria-hidden="true">Contenu du A</div>
<div role="tabpanel" aria-labelledby="tab_2" aria-hidden="true">Contenu du B</div>
</div>
Effectivement, d’un point de vue humain et machine on comprend rapidement que cette structure HTML abrite un système de contenu à onglets. On perçoit facilement quelle balise <div> est associée à quelle balise <li>. Bref, ARIA rend les contenus qui pourraient être obscurs, assez bavards et suffisamment sémantiques pour être, significatifs.
Les nouveautés du langage
Du côté des nouvelles balises
Diverses familles de nouvelles balises ont fait leur apparition avec HTML5. Il serait difficile de classer chacune d’entre elles, car certaines jouent la nouveauté sur plusieurs tableaux. Toutefois, nous pourrons distinguer d’une part, des balises structurelles améliorant la sémantique de nos documents et d’autre part, des balises venant enrichir le catalogue multimédia ou interactif des éléments riches d’une page. On peut cependant en distinguer une liste plus détaillée avec :
- …des balises purement structurelles et sémantiques
<header>,<footer>,<aside>,<section>,<article>,<nav>, … A ce sujet, le choix des noms de balises a été longuement réfléchi. Andy Clarke, dans son analyse sur les conventions de nommage, avait travaillé sur un état des lieux des solutions retenues par certains grands noms du web. - …des balises améliorées offrant une gestion des formulaires plus adaptées :
<datalist>,<imput type="">,<keygen>,<time>, … - …des balises intégrant un certain aspect de l’interaction utilisateur :
<details>,<summary>,<command>,<output>,<meter>, … - …des balises multimédia ouvrant plus largement l’intégration tierce au sein du document :
<video>,<audio>,<figure>,<svg>,<canvas>,<embed>. Les balises multimédia sont également complétées par leur API respective. - …des balises typographiques ou basées sur la gestion du texte lui-même :
<wbr>,<mark>,<small>,<bdi> - …des balises en quantité que l’on peut explorer directement sur HTML5 Tag Reference, pour avoir une liste claire et suffisamment explicite.
Enrichissement des attributs
L’apparition de nouvelles balises ne vient pas sans l’ajout de nouveaux attributs… contenteditable, dragable, et autres spellchek, qui feront dorénavant partie de notre paysage quotidien d’ajout de fonctionnalités pour l’ensemble des balises HTML. Ils parlent d’eux-mêmes, il n’est donc pas nécessaire de les présenter plus avant. Ils ne sont pas seuls, d’autres attributs plus spécifiques apparaissent ici et là, pour compléter et enrichir certaines balises, comme par exemple, la balise <input> qui s’octroie les services de Webforms…
Interaction utilisateur améliorée
Que serait le web si les utilisateurs ne pouvaient contribuer à en enrichir le contenu? La quasi unique passerelle d’entrée que sont les formulaires, ne pouvait donc rester sans améliorations. En s’appuyant sur leur projet initial Web Forms 2.0, l’équipe whatwg à répondu à cette attente en redéfinissant l’ensemble <form>, plus précisément en renforçant le typage des éléments des champs de type input et en complétant la panoplie d’attributs qui les caractérise.
Avec un typage fort, les champs permettent ainsi de contenir et de faire transiter des données ayant un sens mieux défini. La distinction entre une date, un texte, une url, un mail, un nombre etc… sera plus évidente, et les composants de saisie peuvent, de manière native, s’adapter aux besoins. Bien que les navigateurs ne soient pas encore tous au rendez-vous, fini l’ajout de librairie pour mettre en place un calendrier de saisie, un curseur ajustable, un steppeur numérique, ou même une palette de couleur… bref, les interfaces de nos applications peuvent se munir de tels outils de manière native, intégrés aux navigateurs. De plus, et bien que des alternatives javascript fassent légions, les propriétés de validation, de complétion, d’aspect requis, etc… se devaient également de venir affiner la description de ces informations.
Deux sites, parmi tant d’autres, proposent de tester le rendu sur des pages dédiés, HTML5 Forms: Examples of Element Types and Attributes sur wufoo et HTML5 Tests – inputs sur Quirk Mode.
Whatwg ou w3c ?
Du fait de son aspect modulaire et très étendu sur un grand nombre de domaines, cela prendra du temps pour qu’HTML5 soit intégralement recommandé. Le w3c annonce HTML5 Last Call, Targets 2014 for HTML5 Standard et d’autres écrivent et ironisent sur la date de 2022. Notamment Webmonkey dans son article HTML5 won’t be ready until 2022. Yes, 2022., idem pour Remy Sharp sur html5 Doctor dans son article 2022, or when will html5 be ready ?. Alors, quoiqu’il en soit et en attendant l’une ou l’autre des dates… peu importe, utilisez HTML5… il est prêt et bon pour le service.
Afin de pouvoir suivre au plus près les évolutions des brouillons et des implémentations du développement de HTML5, il est préférable de se rapprocher de l’excellent site de la crèmerie d’origine, en la personne du whatwg. Une fois les propositions affinées sur un état de brouillon avancé, la mise à jour se fait rapidement sentir, cette fois-ci sur le site du w3c. A chaque fois, n’hésitez pas à cliquer sur le lien Latest Editor Draft.
… A ce sujet, il est bon de faire la distinction entre une version Working Draft et une version Editor’s Draft. La première correspond à un document qui a été visé par l’ensemble du groupe travaillant sur le sujet comme étant une version possible, alors que la seconde correspond à l’état d’avancée de la personne en charge d’écriture du document et non encore visée par le groupe de travail.
API
Qu’est ce qu’une API ? Une API est une interface applicative qui permet d’interagir avec une fonctionnalité donnée. Tout programme ou partie logicielle, qui se veut accessible entre les applications, donne un accès, au travers de bibliothèques spécifiques, à des fonctions ou des propriétés propres à son fonctionnement. Ceci permet aux développeurs d’applications de pouvoir en tirer partie et en utiliser les services.
Jusqu’à présent, avec l’utilisation d’HTML4, il était nécessaire de faire appel à des tierces parties pour implémenter un grand nombre de fonctionnalités à nos applications web. HTML5 ouvre grand la porte et intègre un grand nombre d’API pris en charge nativement par les navigateurs modernes. Dès lors, quelques lignes de Javascript suffiront, il ne sera plus nécessaire d’avoir recours à des bibliothèques tierces pour implémenter certaines fonctionnalités. Du moins, pour celles proposées par HTML5.
Selector ou jQuery
Une des fonctionnalités que nous utilisons constamment en appui avec Javascript, est la possibilité de sélectionner et de cibler simplement des objets du contenu. Souvent, il n’est pas nécessaire de faire appel à des mastodontes comme jQuery avec ses 32 ko, simplement pour cibler un élément. On peut toujours avoir recourt à Sizzle, qui gagnerait à être allégé, mais qui réduit un tantinet le poids de la librairie (26ko)… mais bon, si la seule préoccupation reste de cibler quelques éléments autrement que par getElementById() et consœurs, HTML5 nous propose deux nouvelles fonctions qui sont prises en compte de manière native : querySelector et querySelectorAll.
Ces deux fonctions usent de la syntaxe à laquelle les librairies nous ont rendus accro :
document.querySelector('.class p')
document.querySelectorAll('.class p')
La différence entre les deux, est que la première fonction retourne le premier élément qui reflète le sélecteur ciblé, alors que la seconde fonction renvoie un tableau d’éléments correspondant à la recherche.
Les autres API
Il n’existe pas que cette nouvelle possibilité d’accéder au DOM, un grand nombre d’API est disponible et accessible avec HTML5. Les plus populaires sont incontestablement celles basées sur la géolocalisation, sur la gestion des variables locales ou de session, ou encore, sur la gestion des fichiers utiles pour gérer le glissé déposé. Mais rassurez-vous, ou non, elles sont loin d’être les seules propositions accompagnant les recommandations. Le blog d’Erik Wilde propose, HTML5 Landscape Overview, un article assez complet sur le sujet. La mise en place de ces principales API pourrait d’ailleurs faire le sujet d’un article dédié. N’hésitez pas à faire part de vos retours à ce sujet.
Tout ceci est-il bien conforme et optimal ?
Bien qu’à ce jour html5 ne soit pas en version candidate, il est cependant possible de pouvoir pré-valider ses pages, en tenant compte de l’état d’avancée des versions brouillons. Deux sites permettent de manière assez rigoureuse, de pouvoir tester les pages développées en html5 : Validator.nu ou sur le w3c sur la page de Markup Validation Service avec options, ou encore, toujours sur le w3C Nu Markup Validation Service.
Tester cette conformité est une chose, mais s’assurer que sa page est bien construite et optimisée en est une autre. Il est donc important de tester le contenu du site sous cet angle, et à cet effet, il existe plusieurs solutions en ligne qui peuvent nous être de grande utilité : Web page test, Take it web, Web site optimization, ou encore Neustar web performance. Si vous ne trouvez pas satisfaction sur ces premiers types d’outils, il en existe bien d’autres.
État des lieux et couvertures navigateurs
Nous entendons souvent, et depuis longtemps, que HTML5 n’est pas une solution utilisable, d’une part à cause de la non prise en compte par les navigateurs de ses recommandations, d’autre part, car la plupart de ses recommandations justement, sont encore en état de brouillon. Alors qu’en est-il ?
Utilisation trop précoce ou au contraire sous-utilisation constatée et confirmée ? De part sa volonté d’être « rétro-compatible », HTML5 se veut donc compatible avec les versions antérieures des navigateurs et de ce fait, ne devrait pas causer de soucis d’interprétation par les navigateurs plus anciens. Après tout, du HTML reste du HTML. Nous verrons à ce sujet comment contourner la non-interprétation des nouvelles balises, par les versions anciennes d’Internet Explorer.
Le hic vient du fait que par HTML5, il faut également entendre et comprendre : utilisation massive des CSS3, utilisation d’API entre guillemets natives de HTML5, gestion responsive des contenus et tout ce qui s’embarque dans cette mouvance d’approche et développement d’applications web modernes. Donc, le souci n’est pas simplement concentré sur la prise en compte des balises.
Prise en compte des balises HTML5 par les vielles versions d’Internet Explorer
Qu’entendons nous par prise en compte des balises ? Et bien simplement le fait que le navigateur les reconnaisse et les interprète correctement. Le plus simple, pour mettre en évidence cette symptomatique, reste de créer un document HTML utilisant uniquement des balises HTML5 comme : <header>, <section>, <aside> et <footer>… bien qu’une seule eût suffit, ajoutons une feuille de style CSS définissant simplement une couleur d’arrière plan, un modèle de boite, une bordure…. vraiment rien de bien compliqué. Si nous visualisons dans un navigateur quelconque, tout se passe comme attendu.
Par contre, si nous lançons une version Internet Explorer inférieure à 9…. rien ne se passe, les CSS sont donc purement ignorées, car les balises ne sont pas reconnues en tant que telles.
La solution consiste à créer dynamiquement ces balises, toutes les balises nouvelles et utilisées dans le document, afin que le navigateur les reconnaisse et puisse les employer. Il suffit pour cela de placer un script en entête de document, qui prenne en compte ce besoin. Quelques lignes de code comme celles qui suivent peuvent faire le job :
<script>
document.create('balise_a_prendre_encompte');
</script>
Bien sur, il va falloir répéter ce code pour chacune des balises nouvelles utilisées. De plus, il va falloir compléter la prise en compte des nouvelles balises, par une feuille de style CSS qui définira par défaut, chacune de ces balises en tant qu’élément de type block. Il existe à cet effet, deux shim qui prennent en compte ces besoins. Le premier, mis en place par Rémy Sharp, html5shiv (à ce sujet lire l’historique de ce shim The story of the HTML5Shiv par Paul Irish), permettra de créer l’ensemble des nouvelles balises apparues avec HTML5. Le second, de Eric Meyer, CSS Tools: Reset CSS, permettra d’initialiser l’ensemble des valeurs par défaut, des balises HTML y compris celles de HTML5.
La problématique de prise en compte des nouvelles balises HTML5 étant uniquement présente avec les versions d’Internet Explorer 9, une paire de commentaires conditionnels évitera à tous les autres navigateurs, non concernés, de parser le code. Il existe également une polémique sur l’emploi de la librairie : soit directement depuis le github, permettant ainsi une actualisation permanente, mais n’excluant pas l’engorgement ou la non-disponibilité du serveur, soit la compression automatique des fichiers servis, soit encore depuis une version locale de la librairie, impliquant forcément une mise à jour manuelle si besoin était. L’article html5shiv and serving content from code repositories dresse une analyse de cette situation.
Quoiqu’il en soit, l’utilisation de la librairie depuis une version locale "../script/" ou depuis le repository "//html5shiv.googlecode.com/svn/trunk/" requiert les commentaires conditionnels suivants :
<!--[if lt IE 9]>
<script src="{...chemin...}/html5.js"></script>
<![endif]-->
Modernizr, vous comprendre API html5 ?
Souvent confondues entre elles ou simplement obscures d’aspect, il existe diverses librairies principales qui gravitent autour de l’utilisation d’html5. Je vous propose que nous en explorions 4 parmi les plus répandues et les plus populaires.
Lorsque des fonctionnalités propres à html5 sont utilisées dans une application web, c’est en espérant que le navigateur les prenne en compte. Que se passe-t-il si cela ne se produit pas ? Et bien dans le meilleur des cas, rien, le navigateur passe outre, sinon cela engendre une erreur… quoiqu’il en soit, cela ne sert pas nos objectifs. Il faut donc s’assurer avant chaque utilisation d’API, ou de CSS, de la prise en compte par le navigateur… et c’est là qu’intervient la première de nos librairies, Modernizr. Cette librairie permet deux choses importantes :
- Contrôler ce qui est pris en charge, en terme d’API, par le navigateur et ce qui ne l’est pas,
- Ajouter des classes au document HTML en fonction de la prise en compte, ou non, des styles de type CSS3
L’utilisation et le fonctionnement de cette librairie fera l’objet d’un article à part entière, mais d’ores et déjà, voyons quelques principes pour sa mise en place. Il suffit de télécharger la librairie et de la lier au document. Ensuite, deux cas de figure : Javascript et CSS. Pour le premier, soit on contrôle la prise en compte au travers d’un test de condition : si pris en compte on fait ceci, sinon on fait cela… soit on use de l’objet YepNope (intégré à Moderniz’r) qui s’assure de charger les scripts adaptés à la configuration :
<script>
if (Modernizr.canvas) {
// canvas est utilisable
} else {
// canvas n'est pas utilisable
}
</script>
<script>
window.onload = function(){
Modernizr.load({
test: Modernizr.canvas,
yep: 'fichier_basé_sur_canvas.js',
nope: 'fichier_alternatif.js',
complete: function(){
// script éventuel à exécuter après chargement des fichiers JS
}
});
}
</script>
Au niveau des CSS, c’est encore plus simple : chargez la librairie, visualisez le document dans un navigateur et inspectez la balise <html>. Elle est complétée par un grand nombre de classes qui indiquent la prise en charge ou non des fonctionnalités… il ne reste plus alors qu’à renseigner les règles de manières adéquates :
<html class=" js no-flexbox canvas canvastext no-webgl no-touch geolocation postmessage
no-websqldatabase no-indexeddb hashchange no-history draganddrop no-websockets rgba hsla
multiplebgs backgroundsize no-borderimage borderradius boxshadow no-textshadow opacity
no-cssanimations no-csscolumns no-cssgradients no-cssreflections csstransforms
no-csstransforms3d no-csstransitions fontface generatedcontent video audio localstorage
sessionstorage no-webworkers no-applicationcache svg inlinesvg no-smil svgclippaths">
.avecTextOmbre {
}
.no-textshadow {
}
.htaccess
En ouvrant sur les balises <audio> et <video> (entre autres), html5 a indirectement introduit l’accès à de nouveaux codecs, afin que chaque navigateur puisse lire ces médias. Cette nouvelle prise en charge de codecs pose le problème de la distribution de ces fichiers par les serveurs et notamment au niveau du type MIME employé. Il faut donc s’assurer que les serveurs livrent bien les formats ogv, mp4, webm, oga, aac et autres, de manière attendue.
De même, l’utilisation de librairies, telle que CSS3Pie, peuvent nécessiter l’ajout de définition de fichier, type htc par exemple, ou encore, l’utilisation de fontes peut nécessiter les mêmes préoccupations. Pour cela, nous allons devoir agir au niveau du serveur et nous pouvons nous retrouver face à deux situations : soit nous avons accès aux fichiers de configuration du serveur, généralement httpd.conf, soit nous pouvons utiliser un fichier .htaccess. Quelque soit la manière, le résultat des paramètres à définir ressemblera à ce genre de résultats :
AddType text/x-component htc AddType video/ogg .ogv AddType video/mp4 .mp4 .m4v AddType video/webm .webm AddType audio/aac .aac AddType audio/mp4 .mp4 .m4a AddType audio/mpeg .mp1 .mp2 .mp3 .mpg .mpeg AddType audio/ogg .oga .ogg AddType audio/wav .wav AddType audio/webm .webmAddType application/vnd.ms-fontobject eot AddType application/x-font-ttf ttf ttc AddType font/opentype otf AddType application/x-font-woff woff
Boilerplate, Initializr, HTML KickStart…
Il est vrai que lorsque l’on souhaite mettre en place un site, ou une application web, s’appuyant sur HTML5, et que le but est de couvrir au plus large le parc des navigateurs, nous allons devoir passer un bon moment à récupérer les différentes librairies, les empaqueter dans un template et les paramétrer. Heureusement, la communauté des développeurs qui œuvre en tâche de fond depuis les balbutiements du HTML5, a concocté et peaufiné quelques frameworks de travail pouvant rapidement répondre à ce genre de problématiques : Boilerplate, Initializr, HTML KickStart… en sont les plus populaires.
De quoi s’agit-il ? Et bien tout simplement d’une page de démarrage préparée avec l’ensemble des liens et des librairies nécessaires, au delà du simple travail en HTML5. On y trouve également un pré-emplacement pour le code de Google Analytics, l’ensemble des fichiers de configuration, des librairies Javascript… bref, tout a été pris en compte. Un visuel générique est même utilisé afin de permettre d’aller encore plus vite sur la maquette de départ. Comment l’utiliser ? Téléchargez simplement le framework que vous souhaitez mettre en place, décompressez l’archive reçue, ouvrez le fichier index.html et entrez votre contenu… c’est tout… enfin presque.
Et la sécurité dans tout cela ?
… Et bien HTML5 est également arrivé avec la réputation d’être un véritable gruyère. Beaucoup trouvent cela très préoccupant et qu’il faut s’en inquiéter en prenant en compte cette problématique, en gérant au mieux les diverses failles (la palisse). Qu’en est-il alors de ces failles et notamment des plus fréquentes et des plus classiques ? Voici quelques pistes de réflexions et quelques articles qui pourront donner de l’eau à votre moulin :
- HTML5 Security Cheatsheet
- Attack and Defense Labs
- The Open Web Application Security Project
- HTML5 WebSockets – security & new tool for attacking
- HTML5, Local Storage, and XSS
- HTML 5 et la sécurité
Si vous souhaitez en savoir plus et pousser plus loin …
- Dive into HTML5 par Mark Pilgrim
- html5 Doctor
- html5 Rocks
- html5 Demos
- Responsive Web Design avec html5 et css3
- HTML Cheat Sheet
En conclusion… faut-il utiliser HTML5 ou encore attendre ?
D’après vous ?
1 réponse
[…] outils clients pleinement opérationnels et répondant à de multiples services. Voir l’article HTML5 qui lui est pleinement […]