Après Une orientation encore trop « littéraire » et pas assez « web » je m’interroge aujourd’hui sur un autre aspect des spécifications HTML5 :  cette tendance à dire aux éditeurs de contenus comment il doivent écrire ou mettre en forme leurs documents. Aujourd’hui, j’ai eu la surprise de voir une page rejetée par le validateur au motif qu’un Element aside not allowed as child of element hgroup in this context. Autrement dit, un élément aside n’est pas autorisé à être enfant d’un élément hgroup. C’est agaçant parce que je trouvais que mon marquage en avait sous la santiag :

<hgroup id="brand"">
  <h1><a href="/"><?php echo get_bloginfo ( 'title' ); ?></a></h1>
  <h2><?php echo get_bloginfo ( 'description' ); ?></h2>
  <aside>
    <?php if (!function_exists('dynamic_sidebar') || !dynamic_sidebar('logo')) : ?>
        <p><img src="images/logo.png" alt></p>
    <?php endif; ?>
  </aside>
</hgroup>

Oui mais voilà : dans mon idée, l’image incluse dans aside — qui aurait pu n’être qu’un background – est destinée à être imprimée sans que l’utilisateur ne bidouille les options d’impression, d’où sa présence en dur dans le code HTML.

Je n’ai pas cherché à couper les cheveux en quatre ; je suis sûr qu’en cherchant un peu on pourrait trouver «what 1000» occasions légitimes et sémantiques (c’est-à-dire qui font sens du point de vue de l’auteur du document) pour justifier la présence d’un élément aside dans un hgroup.

Maintenant que le lait est tiré il faut le boire, certes, mais plus je réfléchis et plus je trouve que HTML5 a le «cul entre deux chaises» : soit il y a trop de balises spécifiques, soit pas assez, sans parler des restrictions comme celle que je viens de soumettre à votre attention.

N’hésitez pas à me remettre les idées en place dans les commentaires si quelque chose d’évident m’a échappé ;)

Articles sur le même sujet

• hgroup disparait du brouillon HTML5, une chance pour logo et motto ?
• Quelques notes sur la balise h1 avec HTML5
• Logo HTML5 du W3C — Vers une redéfinition des métiers du web ?
• HTML 5 Outline — Quelques notes sur la structure des pages Web avec h1 et section
• Manifeste pour la création des éléments LOGO et MOTTO dans HTML5

Je vous ai rapidement parlé de The HTML Framework Project qui propose de réfléchir ensemble à la mise en place d’un environnement de travail pour rendre le démarrage d’un projet de site web moins ennuyeux. Le projet en est à la phase 1.1 : définir. Il est évident que produire un bon code HTML est un métier, un art qui peut difficilement se faire comme on élève des poules en batteries. Pour autant, il doit être possible de dégager parmi les bonnes pratiques de travail, quelques concepts récurrents que l’on pourrait utiliser au démarrage d’un projet.

C’est quoi un framework HTML, au juste ?

Un Framework HTML devrait inclure une structure de fichiers normalisée, quelques trucs pour mettre les navigateurs au garde-à-vous et des fichiers HTML servant de fondations pour des maquettes différentes. C’est aussi simple que ça : un jeu de fichiers et de répertoires pour amorcer le travail dans la joie et la bonne humeur ;)

Sur quelles bases construire ce framework ?

S’assurer que le Framework HTML est conforme avec les points suivants :

• Éviter les tables pour la présentation,
• Séparer le fond et la forme,
• Réserver la partie présentation aux CSS,
• Prendre en considération la « sémantique » des balises HTML,
• Intégrer des noms de classes signifiants,
• Valider en accord avec les spécifications du W3C.

Un mot d’ordre : la flexibilité

Pour que ce framework HTML soit utile aux développeurs, il faudra :

• Ne pas gêner les web designers (les graphistes doivent pouvoir laisser libre-court à leur créativité),
• S’adapter aux contraintes propres d’un projet (être un plus, pas un obstacle),
• Rester léger en excluant les fonctionnalités superflues,
• Être extensible pour faire face aux besoins futurs.

Participer à la discussion

On parle beaucoup (ou pas) de HTML5. J’ai donc lancé l’idée de bâtir les fondations du framework sur la base des spécifications du HTML5, notamment pour la partie structure en accord avec la partie sections du W3C :

• section — Chapitres, onglets des menu, etc. La page d’accueil d’un site web pourrait être découpée en sections : introduction, news et informations de contact.
• nav — Menu principal ou secondaire d’un site web.
• article — Partie indépendante d’une page, d’un document ou d’un site : contribution sur un forum, article de magazine, billet de blog, commentaire, etc.
• aside — Barre latérale ou contenu adjacent,
• header — Regroupement de sections ou de balises h1, h2, etc.
• footer — Pied de page d’une section,
• address — Informations de contact, idéalement placées dans le footer.

Dans le framework HTML, ces éléments pourraient se traduire par :

<div id="header></div>
<div class="article"></div>
<p class="aside">

Les autres éléments de HTML4 étant utilisés — comme d’habitude — de manière à coller au plus près du sens véhiculé par le contenu.

Pour conclure

L’avantage de calquer les id et les class sur les balises prévues par HTML5, c’est de voir loin tout en s’adaptant dès maintenant aux nouvelles habitudes de structuration des contenus avec HTML5. Et comme le suggère jdgraffam il est envisageable que le framework définisse un plan pour passer du framework au HTML 5 quand ce dernier sera pris en compte par les navigateurs, tout en restant rétro-compatible !

Faites tourner et n’hésitez pas à partager ce que ce projet vous inspire. Si vous avez des idées et quelques connaissances en anglais, je vous invite à commenter ce billet, ou ici, si vous êtes plus à l’aise en français ;)

Articles sur le même sujet

• HTML5 — Pourquoi «header» et «footer» ne créent pas de «sections»
• HTML5 — Et si on évitait la balise «section» dans une balise «article» ?
• HTML5 — Une orientation encore trop « littéraire » et pas assez « web »
• Le petit journal du web — Les fruits de la veille ont gardé toute leur fraicheur
• Quelques notes — Programme de formation HTML & CSS