Création Web en Normandie : le blog et son code HTML5

Par
Philippe Le Mesle
Publié le Classé dans Fatras Lien permanent de l'article Tags : SEO ~ COSE ~ référencement ~ balisage ~ CSS ~ sémantique ~ templateCommentaires (8)

Un code HTML5 propre, lisible, sémantique ; une CSS légère uniquement dotée de sélecteurs s'appuyant sur l'arbre du document ; l'encodage en BASE64 des images de fond pour réduire les requêtes HTTP ; des optimisations (SEO) pour le référencement naturel du contenu (COSE) ; des optimisations côté serveur pour soulager le navigateur... c'est le blog de la future agence normande pour la création de sites Web modernes performants.


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 :

  1. Pour le référencement : suppression de la meta name="robots" par la directive X-Robots-Tag :
    <?php header('X-Robots-Tag: index,follow');?>
  2. Pour l'affichage des icônes favicon et apple-touch-icon : suppression des meta en 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]
  3. Pour la compression :
  4. Pour l'encodage : déclaration via le .htaccess de l'usage d'UTF-8.
    Pour les scripts JS et la CSS, par le HEADER HTTP 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");
    }
    ?>
  5. 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-radius dans 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 :
    <!--[if lt IE 9]>
    <script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script> <![endif]-->
    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.

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.
Stucture page HTML5 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 en display:block :
    1. hgroup qui, 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 ».
    2. nav ensuite, 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.
    <header> c'est donc une en-tête. Et il peut y avoir autant d'en-têtes que de blocs de contenus. Vous me suivez ? Non ? Reprenez un verre de Chablis alors. On va faire un détour :
Regardez mon dessin. Nous avons : 3 blocs de 1er niveau (hormis <body> bien sûr) :
  1. 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.
  2. 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.
  3. <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.
    1. vient immédiatement après dans le code, mais placé dans un cartouche flottant à la droite de l'article, <header>.
      Ce bloc regroupe les meta associé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.
    2. 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.
    3. 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 une ID !? s'interroge le lecteur pas encore assez bourré pour avoir oublié qu'il n'y en aurait pas. Oui, une ID, 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,
      1. 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 META que je regroupe (encore)...
      2. dans la balise d'en-tête du commentaire, <header>.
        Notez que j'aurai tout autant pu placer celle-ci en <footer>.
      3. en suite, on trouve le formulaire de publication du commentaire. En HTML5 les formulaires ont fait de grands progrès.
        Ainsi le nouvel attribut autofocus nous permet enfin de nous débarrasser de :
        <script> document.getElementById('Chablis').focus() </script>
        Mieux encore et là c'est un vrai bonheur, avec l'autre nouvel attribut, 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'attribut required est répété pour l'accessibilité avec l'attribut ARIA : required aria-required="true".
      4. autre nouvel attribut, placeholder permet 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.

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 :
    1. le formulaire de recherche le plus simple qui soit et qui aurait pu ressembler à ça :
      <form>
      <label>Rechercher</label>
      <input name=search autofocus placeholder="Chercher un verre" />
      <input type="submit" value="de Chablis !"->
      </form>
      Là aussi des économies sont faites : on peut omettre l'attribut action si la chaîne de caractères est vide ; on peut se passer de method si vous utilisez get car le formulaire fera une requête GET par défaut (pour moi c'est post, je dois donc le préciser). Un formulaire de recherche plus simple vous connaissez ?
    2. vient ensuite la balise <hr /> qui, en HTML5, porte une valeur de rupture sémantique.
    3. et c'est enfin la bonne vieille balise <p> que nous retrouvons pour les liens situés en-dessous, ceci pour économiser quelques <li>.

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 :

playmobitch||#1
playmobitch
c'est moi ou y'a un problème sur certains liens ? dans la source j'ai href=//normandie-web.hiseo.fr/
par exemple..
Philippe||#2
Philippe
Non il n'y a pas de problème : ça marche...
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.
playmobitch||#3
playmobitch
ça m'apprendra tiens...

en fait c'est surtout l'absence de guillemets qui me piquait les yeux.

j'adore me coucher moins con.
Eric||#4
Eric
LoL .... et ce brochet ?
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.
Philippe||#5
Philippe
De retour de Nantes où j'ai terminé l'article.
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.
Frédéric||#6
Frédéric
Ouh la la ! C’est quand même pas évident de se passer des ID, des CLASS et des DIV. Chapeau !

Et pour les formulaires HTML5 est tout simplement génial.
Merci beaucoup pour le partage du code et de l’éxpérinentation.
Rémy||#7
Rémy
Bonjour, merci pour tous ces beaux articles mais une question me taraude, surement dû à ma faible expérience : quel est l'utilité pratique de se passer des ID et CLASS pour le CSS, outre la beauté du geste ?
Réaliser site Web en Normandie||#8
Réaliser site Web en Normandie
Réduire le verbe du code HTML par un autre ciblage.
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.

Les commentaires pour ce billet sont fermés