Un tour d'horizon du code HTML5 et de sa feuille de styles, comme promis dans le précédent billet.
Pendant votre ballade dans les méandres du code, gardez en mémoire que le blog n'est pas complètement testé, tant pour le balisage HTML5 que pour celui de sa CSS. L'objectif visé était d'obtenir un code HTML proche de l'épure, simple et concis, s'appuyant sur l'ensemble des sélecteurs offerts par CSS 2.1. En évitant l'usage des sélecteurs d'ID et de CLASS, j'ai pu supprimer ainsi toutes les DIV et SPAN qui rendent le code obèse (ce qui est le cas pour le blog ici-même).
Un code plus léger donc, ne s'appuyant que sur les balises sémantiques d'HTML5, avec des gains très conséquents pour le rendu (YSlow donne un score de 100, et les GWT aujourd'hui disent qu'il est plus rapide que 87% des sites). Un code « cross-browsers » semble t-il aussi : testé sous Windows Seven dans Opera (10.60), Firefox (3.6.7), Safari (5.0), Chrome (5.0), Internet Explorer (8.0), l'impression à l'écran est identique.
Pour vous permettre de bien le lire j'ai indenté le code HTML et j'ai documenté aussi la CSS. J'ai aussi nettoyé le script PHP de toutes ses anciennes scories XHTML. J'ai réduit conséquemment le nombre de balises et, pour la feuille de styles, j'ai peu consommé des nouvelles propriétés CSS3 comme vous pourrez en juger.
Si vous voulez bien, c'est le code de cette page que l'on va scruter.
Les fondations du site et du blog
Objectif : dépouiller le code de tout ce qui est inutilement traité en HTML :
- Pour le référencement : suppression de la
meta name="robots"par la directive X-Robots-Tag :<?php header('X-Robots-Tag: index,follow');?> - Pour l'affichage des icônes
faviconetapple-touch-icon: suppression desmetaen passant par l'.htaccess:AddType image/x-icon .ico RewriteRule ^favicon.ico$ favicon.ico [NC,L] RewriteRule ^apple-touch-icon.png$ apple-touch-icon.png [L] - Pour la compression :
- application de cette méthode de compression de la CSS pour l'hébergeur 1and1.
- conversion en BASE64 des images de fond de la CSS pour éviter toute requête HTTP superfétatoire avec ConvertToBase64.exe
- Pour l'encodage : déclaration via le
.htaccessde l'usage d'UTF-8.
Pour les scripts JS et la CSS, par leHEADERHTTP en PHP :<?
if($extension=='css'){
header('Content-type: text/css; charset=utf-8');
header("Expires: ".gmdate("D, d M Y H:i:s", time() + $offset)." GMT");
}
if($extension=='js'){
header('Content-type: text/javascript; charset=utf-8');
header("Expires: ".gmdate("D, d M Y H:i:s", time() + $offset)." GMT");
}
?> - Pour la compatibilité : tous les navigateurs modernes savent interpréter HTML5 ainsi que la plupart des propriétés CSS 2.1. Les propriétés CSS3 incorporées à la feuille de styles et non reconnues aujourd'hui (cas, sur le blog de la boîte de recherches située dans le <footer>, de
border-radiusdans les navigateurs Webkit) le seront bientôt. Autant attendre et ne pas encombrer le code d'appels de scripts (tels que Modernizr ou CSS3 Pie).
Je n'ai mis en place aucun hack par un « CSS body building » ou autre technique de « sniffing » d'user-agent.
Bien sûr il y a le cas Internet Explorer. En attendant IE9, il faut apprendre aux anciennes générations le balisage d'HTML5. Ça passe par ce commentaire conditionnel placé parmi les META :
Notez que j'ai du rajouter 2 balises que j'avais supprimé. Sans <head> ni <body>, IE 8, malgré ce script, refusait d'interpréter les balises HTML5.<!--[if lt IE 9]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script> <![endif]-->
La suite ? Ce sera pour dans pas bien longtemps avec les murs, c'est à dire la structure et la logique du balisage en HTML5 de la page.
Je vous laisse : j'ai un brochet qui m'attend dans l'Eure. Là, exactement.
La structure du blog et du site
J'en discutais dimanche avec le cousin du neveu du témoin de mariage de ma boulangère — c'est vous dire si c'est un intime — : le brochet avec un authentique beurre blanc, c'est divin. Surtout sur un Chablis.
Alors, faites comme chez moi : servez-vous un verre de Chablis, on poursuit :
Voici un petit dessin de la maquette que vous pouvez même agrandir en cliquant dessus : en noir, le contenu. En rouge, le code.
Commençons par le commencement :
- Le body :
ici, c'est le conteneur global de la page. Pourquoi avoir besoin d'une <div> alors que <body> est la matrice de toutes les boîtes qui descendront de l'arbre du document ? - Le header :
La balise <header> vient en tête du document bien sûr. Elle enserre 2 autres balises que j'affiche endisplay:block:hgroupqui, sur la gauche contient le nom du sous-domaine « Normandie Web » placé en H1 et, en H2, la baseline :
« Création de sites Web en HTML5 en Haute & Basse Normandie : conception, réalisation et référencement de votre site ».navensuite, qui regroupe les liens de 1er niveau de la navigation. Pas besoin de liste ici : les liens se succèdent séparés d'une espace.
- l'en tête de la page que nous venons de voir, c'est celui qui regroupe le nom du site, sa baseline ainsi que la barre de navigation. C'est un contenu fixe.
- le pied de page qui contient 2 autres blocs dont celui du formulaire de recherches. C'est <footer> Là, itou, le contenu est fixe : il sera ainsi reproduit sur toutes les pages du blog.
- <article> qui va recevoir ces formidables textes qui m'ont valut tant de récompenses et de distinctions.
Nota bene : j'emploie le mot « bloc » pour éviter la confusion avec « section », car <section> est une balise HTML5 que l'on verra plus après.
Chaque bloc d'information, disais-je, est autonome. Chacun peut recevoir son propre <header> et <footer> ainsi que son propre <h1>. C'est bon ?
Pousuivons alors l'investigation dans les blocs de 1er niveau, avec, tout d'abord, la balise <article> :
- <article> : ce conteneur possède son propre <h1>, le titre du billet.
- vient immédiatement après dans le code, mais placé dans un cartouche flottant à la droite de l'article,
<header>.
Ce bloc regroupe lesmetaassociés au document (le fil d'Ariane, l'auteur, le permalien, la rubrique, les tags ainsi que les liens vers les articles suivant & précédent. - en marge, encore, la balise <mark> me sert à insérer des notes, de celles qu'on trouve en bas de page. Si les notes de bas de pages, sont loisibles dans un livre ou dans un journal en bas de la page ou de l'article, pour le Web ce n'est pas ce qu'on fait mieux à mon humble avis : on se doit d'abord de faire un lien vers l'ancre et, depuis l'ancre, un nouveau lien pour pouvoir remonter au point de lecture. Si le codeur l'oublie, c'est mortel : le lecteur doit scroller jusqu'à la note pour remonter ensuite cherche l'endroit où sa lecture a été interrompue. Bref, c'est lourd et pas très ergonomique.
Une dernière remarque à ce propos : ces notes j'aurai très bien pu les enserrer de la balise <aside>... sauf que... je me réserve celle-ci pour de longs articles où je vais déposer une mini-table des matières (ou sommaire) dedans. - sous le cul-de-lampe (la feuille verte du pommier), vient un autre bloc : celui des commentaires. Ici c'est la balise <section> que j'emploie. Les commentaires font partie de l'article mais se distinguent par cette rupture sémantique qu'implique <section id="comments">.
Tiens uneID!? s'interroge le lecteur pas encore assez bourré pour avoir oublié qu'il n'y en aurait pas. Oui, uneID, mais parce que c'est une ancre. Et elle n'est pas utilisée par la CSS.
Enfonçons-nous dans la zone des commentaires :
Dans ce bloc, que retrouve t-on ? Tout d'abord,- la balise <article>. Encore ! Oui : mais c'est un choix personnel. Le commentaire de votre lecteur aurait très bien pu se satisfaire d'une balise de paragraphe mais j'ai préféré que chaque commentaire soit bien distingué et identifié par ses propres
METAque je regroupe (encore)... - dans la balise d'en-tête du commentaire, <header>.
Notez que j'aurai tout autant pu placer celle-ci en <footer>. - en suite, on trouve le formulaire de publication du commentaire. En HTML5 les formulaires ont fait de grands progrès.
Ainsi le nouvel attributautofocusnous permet enfin de nous débarrasser de :
Mieux encore et là c'est un vrai bonheur, avec l'autre nouvel attribut,<script> document.getElementById('Chablis').focus() </script>required, plus besoin de scripts pour effectuer la validation côté client : quand le commentateur soumet son envoi, le navigateur vérifie si toutes les conditions sont remplies et envoie le formulaire si tout est bon. Et si ce n'est pas le cas, hop ! il affiche un message d'erreur. Épatant non ?
Vous noterez dans le code que l'attributrequiredest répété pour l'accessibilité avec l'attribut ARIA :required aria-required="true". - autre nouvel attribut,
placeholderpermet d'afficher un texte d’information dans un champ de formulaire. Ce texte disparaît dès l'entrée du curseur dans le champ pour placer le contenu que vous voulez adresser. Avec cet attribut, tout est géré nativement par le navigateur. Et hop ! encore des économies de scripts.
- la balise <article>. Encore ! Oui : mais c'est un choix personnel. Le commentaire de votre lecteur aurait très bien pu se satisfaire d'une balise de paragraphe mais j'ai préféré que chaque commentaire soit bien distingué et identifié par ses propres
- vient immédiatement après dans le code, mais placé dans un cartouche flottant à la droite de l'article,
<header>.
C'est maintenant au <footer> ( celui de la page) que nous arrivons tout naturellement, un verre vide en main :
- <footer> : à l'instar des autres blocs, le pied de page ainsi nommé et placé est indépendant. Il peut donc recevoir, lui aussi son lot de balises sémantiques. Mais c'est un peu le « footoir » : un jour le whatwg.org recommande d'y placer des liens ceint de la balise <nav>, un autre jour, le W3C recommande de les mettre seulement dans des listes ou dans des paragraphes.
Quand ils auront accordé leurs violons, on pourra respecter la partition.
Pour le blog c'est un simple paragraphe qui les affiche dans sa partie gauche.
Tandis que, pour le bloc droit nous avons droit à une nouvelle <section> comprenant :- le formulaire de recherche le plus simple qui soit et qui aurait pu ressembler à ça :
Là aussi des économies sont faites : on peut omettre l'attribut<form> <label>Rechercher</label> <input name=search autofocus placeholder="Chercher un verre" /> <input type="submit" value="de Chablis !"-> </form>actionsi la chaîne de caractères est vide ; on peut se passer demethodsi vous utilisezgetcar le formulaire fera une requête GET par défaut (pour moi c'estpost, je dois donc le préciser). Un formulaire de recherche plus simple vous connaissez ? - vient ensuite la balise <hr /> qui, en HTML5, porte une valeur de rupture sémantique.
- et c'est enfin la bonne vieille balise <p> que nous retrouvons pour les liens situés en-dessous, ceci pour économiser quelques <li>.
- le formulaire de recherche le plus simple qui soit et qui aurait pu ressembler à ça :
Finissons par la fin...
Je ne crois pas m'être planté sur le bon usage des balises HTML5 tel que défini à l'heure où j'écris ces lignes. Les recommandations de la « kommandantur » du « Wmachin » n'étant pas encore sorties, il faudrait être devin pour en connaître la teneur définitive.
Faut-il passer dès maintenant à HTML5 ou attendre la Saint Glinglin ? À mon avis, oui, pour votre site, votre blog d'abord et ensuite, en prod, pour vos clients. Il n'y a aucun risque à coder ainsi.
Par contre je ne recommanderais pas d'utiliser les nouvelles propriétés des CSS3 (qui, elles, ne sont pas encore définies,), malgré le fait que ça apporte une très grande souplesse.
Alors, HTML5 = Oui..., CSS3, avec parcimonie.
Mes très chères frères, mes très chères sœurs reprenons tous ensemble un verre de Chablis à la santé d'HTML5. Hic.
Commentaires :
par exemple..
C'est juste que tu as loupé un épisode : dans les liens il n'est pas nécessaire d'indiquer le protocole. HTTP est le protocole par défaut.
Les guillemets ne sont pas nécessaires non plus.
en fait c'est surtout l'absence de guillemets qui me piquait les yeux.
j'adore me coucher moins con.
Bon je ronge mon frein pour voir la suite. En fait je suis en plein questionnement sur HTML5 et risque de franchir le pas. Du coup je vais suivre attentivement l'avancement du blog Normandie. Bon courage et merci.
Celui-ci renvoie vers une page neutre avec la CSS figée.
Pourquoi ? Tout simplement parce que je vais rentrer maintenant dans le design et la typo et que le gabarit va pas mal changer.
Et pour les formulaires HTML5 est tout simplement génial.
Merci beaucoup pour le partage du code et de l’éxpérinentation.
C’est le point essentiel.
Mais c’est pas simple à gérer... je te l’accorde, mais pour la performance du site ça compte.
Mais, autre intérêt, c’est pour le CORE de mon CMS HTML5 :
j’ai pu ainsi le nettoyer de toute référence à la feuille de styles sous forme d’ID ou de CLASS. Le CORE mais aussi le gabarit.
Du coup, j’ai une seule version du CORE et du gabarit à gérer pour tous mes clients. Pour le développement et la maintenance c’est l’idéal.