CSS & Webdesign » Section http://css.4design.tl Le blog de l'intégrateur web Thu, 24 May 2012 16:31:47 +0000 en hourly 1 http://wordpress.org/?v=3.3.2 HTML 5 Outline — Quelques notes sur la structure des pages Web avec h1 et section http://css.4design.tl/html-5-outline-page-web-section-h1 http://css.4design.tl/html-5-outline-page-web-section-h1#comments Mon, 20 Dec 2010 08:07:49 +0000 Bruno Bichet http://css4design.com/?p=8482 Après l’article Quelques notes sur la balise h1 avec HTML5 dans lequel j’ai abordé l’utilisation des niveaux d’en-tête h1 -- h6 pour savoir dans quelle mesure il est judicieux d’utiliser une ou plusieurs balises h1 dans une même page Web, je continue sur ma lancée avec la notion d’Outline. Cette dernière fournit la liste des sections imbriquées impliquant les éléments de type Sectioning Content ou Sectioning Root. Chaque section peut être associée à un niveau d’en-tête et peut contenir autant de sections imbriquées que l’on veut. Notez que les sections dont on parle ne sont pas nécessairement l’élément section lui-même (même si ce dernier fait partie des éléments ayant une portée de Sectioning Content).

Balises h1, avec ou sans section ?

HTML5 Outliner est un outil qui permet de souligner la structure hiérarchique d’un document HTML en mettant en évidence les différents niveaux d’en-tête et de sections. En HTML5, les sections sont déterminées de deux manières :

  1. Explicite, avec les éléments ayant une portée de Sectioning Content (`article`, `aside`, `nav` ou `section`).
  2. Implicite, avec les élements d’en-tête (Headings) (`h1`, `h2`, `h3`, `h4`, `h5`, `h6` et `hgroup`).

Pour s’en convaincre, il suffit de jeter un oeil sur les deux exemples mis en ligne par @futomi qui tient un blog consacré à HTML5 (oui, c’est en japonais, mais le code n’a pas de frontière et Google Translate est toujours ton ami) :

Section implicite

<!DOCTYPE html>
<html lang="ja">
    <head>
        <meta charset="UTF-8" />
        <title>outline1</title>
    </head>
    <body>
        <article>
            <h1>a</h1>
            <h1>b</h1>
            <h1>c</h1>
        </article>
    </body>
</html>
Source : http://www.html5.jp/test/outline1.html

Section explicite

<!DOCTYPE html>
<html lang="ja">
    <head>
        <meta charset="UTF-8" />
        <title>outline2</title>
    </head>
    <body>
        <section>
            <h1>a</h1>
        </section>
        <section>
            <h1>b</h1>
        </section>
        <section>
            <h1>c</h1>
        </section>
    </body>
</html>
Source : http://www.html5.jp/test/outline2.html

La vérification avec HTML5 Outliner montre une hiérarchie similaire, même si le maquage HTML est différent. La section Untitled qui apparait au début n’est autre que la section introduite par la balise body qui a une portée de Sectioning Roots avec blockquote, details, fieldset, figure et td. Ce n’est pas très gênant dans la mesure où un document HTML5 reste valide sans body lorsqu’il n’est pas nécessaire, ce qui est le cas ici.

Outline, au pied !

Si l’on raisonne en terme de page Web et non plus uniquement en terme de document, on peut se trouver face à quelques problèmes de structure, notamment, si l’on désire que les en-têtes contenus dans une balise aside suivent la hiérarchie initiée plus haut dans la page. Par exemple : 

<!DOCTYPE html>
<html>
    <head><title>Test</title></head>
    <body>
        <article>
            <h1>Title 1</h1>
                <h2>Title 2</h2>
        <aside>Aside</aside>
            <h3>Title 3</h3>
        </article>
    </body>
</html>
Est compris comme : 
article
    h1
        h2
        aside
        h3
Alors que l’on voudrais que le h3 contenu dans la balise aside descende de h2 au lieu que la balise aside (suivant logiquement son statut de Sectioning Content) ne remette la hiérarchie des en-têtes h1 -- h6 à zéro, pour obtenir : 
article
    h1
        h2
            aside
            h3
Pour cela, il est nécessaire d’utiliser des sections explicites, comme : 
<!DOCTYPE html>
<html>
    <head><title>Test</title></head>
    <body>
        <article>
            <h1>Title 1</h1>
            <section>
                <h2>Title 2</h2>
                <aside>Aside</aside>
                <section>
                    <h3>Title 3</h3>
                </section>
            </section>
        </article>
    </body>
</html>

Titre h1 et sous-titre h2 informatif

Il peut arriver que l’on désire utiliser envelopper un titre avec la balise h1 et un sous-titre dans une balise h2. Si on utilise : 

<section>
    <h1>Section and outlines of a document</h1>
    <h2>HTML, HTML5, Sections, Outlines</h2>
</section>
On va se retrouver avec une structure qui risque de «décaler» la hiérarchie de notre document, comme : 
1. Section and outlines of a document
    1.1 HTML, HTML5, Sections, Outlines
Pour éviter que notre balise h2 n’apparaisse dans l’outine, il suffit d’utiliser l’élément hgroup : 
<section>
    <hgroup>
        <h1>Justine</h1>
        <h2>Les Malheurs de la vertu</h2>
    </hgroup>
</section>
Qui nous donnera l’outline suivant : 
1. Justine

Pour finir

Je vous laisse avec quelques liens triés sur le volet à propos de l’Outline des documents Web. N’hésitez pas à partager vos expériences heureuses ou non concernant le balisage des pages Web avec les nouvelles balises HTML5.

Linkographie

Articles sur le même sujet

flattr this!

]]> http://css.4design.tl/html-5-outline-page-web-section-h1/feed 5 Quelques notes sur la balise h1 avec HTML5 http://css.4design.tl/quelques-notes-sur-la-balise-h1-avec-html5 http://css.4design.tl/quelques-notes-sur-la-balise-h1-avec-html5#comments Thu, 16 Dec 2010 13:19:29 +0000 Bruno Bichet http://css4design.com/?p=8356 La réponse courte à la question « Combien de balises h1 dans une page Web HTML5 ? » est : « Autant que nécessaire ! » En gros, chaque fois que vous avez une nouvelle section, vous  pouvez mettre un h1. D’une manière générale, h1 accompagnera article, aside, nav ou section avec brio ! (cf. Sectioning content). Allons voir ce que nous disent les spécifications HTM5 sur l’emploi des balises de titre h1 — h6, notamment les exemples concernant les niveaux de titre. Ils sont assez parlant bien que parfois déroutant lorsqu’on a l’habitude du balisage utilisé jusqu’à présent. Les éléments h1 — h6 représentent les niveaux d’en-têtes de leurs sections respectives. Quant à l’élément hgroup, il regroupe un ensemble d’en-têtes composé d’au moins deux niveaux de titre, comme un titre et son sous-titre ou un titre et le slogan associé (un bon candidat pour Logo et Motto, faute de mieux).

Quelques exemples avec H1

Les deux bouts de code qui suivent sont équivalent : 

<body>
    <h1>Let's call it a draw(ing surface)</h1>
    <h2>Diving in</h2>
    <h2>Simple shapes</h2>
    <h2>Canvas coordinates</h2>
    <h3>Canvas coordinates diagram</h3>
    <h2>Paths</h2>
</body>
<body>
    <h1>Let's call it a draw(ing surface)</h1>
    <section>
        <h1>Diving in</h1>
    </section>
    <section>
        <h1>Simple shapes</h1>
    </section>
    <section>
        <h1>Canvas coordinates</h1>
        <section>
            <h1>Canvas coordinates diagram</h1>
        </section>
    </section>
    <section>
        <h1>Paths</h1>
    </section>
</body>
La première forme est celle que l’on utilisera le plus souvent dans le cadre d’un CMS, puisque il est rare que l’on puisse saisir des balises section lors de la rédaction d’un article, même en passant par l’éditeur HTML puisqu’il supprime les balises exotiques. A moins qu’un plugin ne permette d’y remédier.

Dans un autre exemple, on trouve une utilisation des niveaux h1 suivis de h2 et h3 à l’intérieur des sections : 

<body>
    <h1>Apples</h1>
    <p>Apples are fruit.</p>
    <section>
        <h2>Taste</h2>
        <p>They taste lovely.</p>
        <section>
            <h3>Sweet</h3>
            <p>Red apples are sweeter than green ones.</p>
        </section>
    </section>
    <section>
        <h2>Color</h2>
        <p>Apples come in various colors.</p>
    </section>
</body>
Toutefois, le W3C recommande d’utiliser la forme suivante plus explicite et plus simple à maintenir si l’on doit modifier l’ordre des sections en cours de rédaction (ou lors de corrections plus tardives) : 
<body>
    <h1>Apples</h1>
    <p>Apples are fruit.</p>
    <section>
        <h1>Taste</h1>
        <p>They taste lovely.</p>
        <section>
            <h1>Sweet</h1>
            <p>Red apples are sweeter than green ones.</p>
        </section>
    </section>
    <section>
        <h1>Color</h1>
        <p>Apples come in various colors.</p>
    </section>
</body>
Si la première version semble mieux hiérarchisée, la deuxième est plus claire : un h1 gratuit pour chaque création de section explicite ! Et l’on peut continuer avec les balises h2, h3, etc. C’est la profondeur du document, l’imbrication des sections et des sous-sections qui définit la hiérarchie du document. Ce qui ne signifie pas que les balises h2  – h6 sont inutiles. Elle sont toujours indispensables pour structurer le message à l’intérieur des sections.

Pour l’application des styles CSS, en revanche, pas sûr que section section h1 {...} soit plus simple que h3 {...}. Voir à ce sujet HTML5 Titles Inception, la courageuse descente de Nicolas Hoizey dans les limbes pour styler les h1 selon leur profondeur.

Sémantique ou optimisation SEO ?

La question du nombre de fois où l’on peut utiliser la balise h1 dans un document présente deux facettes :

  1. Logique interne du document (Semantic). Un document est souvent identifié par un titre et les parties qui le composent par des sous-titres. Si un document peut ne posséder qu’un seul titre (à l’image des livres où le titre se trouve en couverture), il est possible d’utiliser un titre `h1` par `section`. On suppose alors que les sections forment des parties dissociables du tout. A cet égard, on peut se demander si une balise `article` n’est pas préférable dans la mesure où une partie indépendante peut bénéficier (en théorie) d’un flux RSS dédié.
  2. Le référencement au niveau de la page (In Page). Google accorde un poids supplémentaire (un petit poids, faut pas trop rêver non plus) aux mots-clés contenus dans les balises de titre `h1`, `h2` et `h3`. La tentation est grande de vouloir en utiliser un maximum dans une même page.

Est-il est possible de mixer ces deux approches en tentant le Jackpot de la beauté sémantique et du charme SEO ? Lorsqu’on regarde de près les ouvrages imprimés (livre ou magazine), on s’aperçoit que le titre ne se retrouve pas toujours uniquement sur la 1ère de couverture. Dans certains livres, le titre est parfois répété dans les feuillets intérieurs précédé et/ou suivi de quelques pages blanches. Dans certains magazines, le nom de la revue peut se retrouver sur toutes les pages avec le titre de la rubrique en regard.

Du coup, l’argument du titre unique pour l’ensemble du site Web — en comparaison logique avec le Livre (objet de référence dès qu’il s’agit de bon goût) — ne tient plus. CQFD. Reste la question du title présent dans les balises meta. D’un point de vue SEO, cette balise est fondamentale car elle fait office de titre dans les SERP’s (Résultats dans les pages de recherche). Il faut donc lui accorder un soin tout particulier. Elle doit être unique sur la page. Or, la plupart des CMS utilisent le titre de l’article pour garnir ce title, ce qui le fait apparaitre deux fois. Sans compter l’URL du billet qui reprend souvent ce même titre lors de la réécriture des URL (URL Rewriting).

Il est important de s’assurer que ce title n’est pas redondant. Le meilleur moyen d’y parvenir est de considérer qu’il représente le vrai titre de la page Web, indépendamment des niveaux de titres h1 présents (sans compter que la page n’est pas forcément synonyme de document) ou même du logo, qu’il s’agisse d’un texte ou d’une image. Le Web n’est pas totalement réductible aux pratiques de l’imprimé, fussent-elles de bon goût.

En matière de SEO, redondance rime avec décadence, du moins lorsque la répétition s’effectue sur des niveaux hiérarchiques d’égale importance.

Document vs Site Web

La plupart des exemples fournis par le W3C concernent des documents et pas des sites Web, et ce n’est pas un détail : de nombreuses ambiguïtés concernant le bon usage de la balise h1 viennent de là. Si l’on doit présenter le compte-rendu d’une réunion, le titre du document pourrait être l’objet du mail qui a servi pour inviter les participants.

Prenons par exemple le document suivant : 

<h1>«La Tête Dans l'Asso» accueille les nouveaux adhérents</h1>
<p>Cette année, l'association a recueillie une centaine de nouveaux membres [...]</p>
<h2>La réunion d'intégration</h2>
<p>blablabla [...]</p>
<h2>Le livret d'intégration</h2>
<p>blablabla [...]</p>
<h2>Partenaires</h2>
<ul>
    <li>La Tête dans l'Ecu</li>
    <li>La Tête allant vers... </li>
</ul>
Une fois que le document est balisé correctement, il reste à l’intégrer dans le site Web qui contient généralement des balises d’en-tête de différents niveaux avant et après la zone des articles. Pour simplifier, on peut utiliser le marquage suivant : 
<header>
    <hgroup>
        <h1>Mon logo qu'il est beau</h1>
        <h2>Mon Slogan qu'il est grand</h2>
    </hgroup>
    <p>Ma description étendue qu'elle est bien fichue [...]</p>
</header>
Sous réserve que le logo en question soit composé en HTML et signifie quelque chose. Pendant longtemps, ce blogzine avait pour titre «CSS & Webdesign», ce qui en faisait un titre efficace dans le sens où 1) l’expression était représentative du contenu et 2) signifiait quelque chose pour les moteurs de recherche. D’ailleurs, sans trop vouloir enfoncer le clou du SEO, si votre logo-titre n’est pas utile pour les moteurs de recherche (ex. css4design, logo en image), autant utiliser une balise div.

Pour intégrer notre document dans le site Web, nous allons l’envelopper avec une balise article. Puis, nous allons modifier le marquage du header pour supprimer la balise h1 bien que les spécifications HTML5 ne nous y oblige pas. L’idée est de garder la ou les balises h1 uniquement à l’intérieur de la balise article pour optimiser le SEO In Page. Nous en profiterons pour remplacer la description du site par un résumé de l’article qui servira de chapô : 

<header>
    <p>
        <span id="logo">Mon logo qu'il est beau </span>
        <span id="slogan">Mon Slogan qu'il est grand</span>
    <p>
    <p>Un résumé de l'article qui servira de chapô [...]</p>
</header>
<article>
    <h1>«La Tête Dans l'Asso» accueille les nouveaux adhérents</h1>
    <p>Cette année, l'association a recueillie une centaine de nouveaux membres [...]</p>
    <h2>La réunion d'intégration</h2>
    <p>blablabla [...]</p>
    <h2>Le livret d'intégration</h2>
    <p>blablabla [...]</p>
    <h2>Partenaires</h2>
    <ul>
        <li>La Tête dans l'Ecu</li>
        <li>La Tête allant vers... </li>
    </ul>
<article>
Pour continuer dans cette logique de donner la primeur au contenu principal de la page, le mieux est encore de le placer en premier dans le code. En effet, un des avantages du Web par rapport à l’imprimé, c’est que l’ordre d’affichage des éléments n’est pas forcément celui du code source. Ainsi, dans l’exemple, ci-dessus, on peut très bien placer le contenu de la balise article avant celui de header dans le code et inverser l’ordre d’affichage avec la propriété float ou position: absolute.

Adaptez la feuille de style aux documents, pas l’inverse !

Si les spécification du W3C autorisent — voire encouragent — l’utilisation de plusieurs balises h1 pour structurer le contenu à l’aide de section, il me semble important d’adapter le balisage HTML à la sémantique des documents. Vous trouvez ça bateau ? Pourtant je remarque que l’on a tendance à baliser les documents de manière à les adapter à la feuille de style que l’on a déjà, plutôt que d’adapter la feuille de style aux documents ! Cela passe par une analyse approfondie des documents existants, par la création d’une feuille de style CSS souple et par la capacité de remettre son travail en question selon la nature des documents à venir.

Linkographie

Articles sur le même sujet

flattr this!

]]> http://css.4design.tl/quelques-notes-sur-la-balise-h1-avec-html5/feed 35 HTML5 — Repenser le découpage des pages web et des contenus http://css.4design.tl/html5-repenser-le-decoupage-des-pages-web-et-des-contenus http://css.4design.tl/html5-repenser-le-decoupage-des-pages-web-et-des-contenus#comments Thu, 08 Apr 2010 16:09:01 +0000 Bruno Bichet http://css4design.com/?p=5967 Derrière les nouvelles balises proposées par HTML5 se cache un nouveau modèle de structuration. Jusqu’à présent, on rencontre souvent la structure suivante : un niveau de titre h1 pour le nom du site et ça continue avec h2 pour le titre des articles ; reste h3 — h6 pour structurer la prose, ce qui est suffisant ou pas. HTML5 introduit la notion de Sectioning Content (cf. le concept d’outline) de manière explicite avec les balises section, nav, article et aside ou de manière implicite a chaque utilisation d’un niveau de titre h1.

Soyez détendus du h1

En gros, il est tout à fait possible d’utiliser un h1pour le titre du site (suivi d’un h2 pour le sous-titre éventuellement dans un hgroup), mais aussi pour le titre des articles et pourquoi pas à l’intérieur de l’article lui-même pour le découper en «sections». Ça tombe bien car je trouvais un peu pénible d’être «obligé» de commencer mes titres avec un h2 voire un h3 et laisser le h1 de mon éditeur WYSIWYG prendre la poussière !

Articles sur le même sujet

flattr this!

]]> http://css.4design.tl/html5-repenser-le-decoupage-des-pages-web-et-des-contenus/feed 1 HTML5 — Et si on évitait la balise «section» dans une balise «article» ? http://css.4design.tl/html5-et-si-on-evitait-la-balise-section-dans-une-balise-article http://css.4design.tl/html5-et-si-on-evitait-la-balise-section-dans-une-balise-article#comments Fri, 26 Mar 2010 08:44:06 +0000 Bruno Bichet http://css4design.com/?p=5888 Ce billet fait partie d’une série de notes rapides prises lors de ma lecture des spécifications HTML5. Aujourd’hui, c’est le commentaire de Romy qui me donne l’occasion de rebondir sur le découpage d’une page web avec HTML5 et plus particulièrement la balise section. Dans ce billet, je m’éloigne un peu du commentaire de Romy et je voudrais souligner qu’elle a parfaitement raison quand elle dit que le rôle des balises header et footer est clair mais que leur traduction en En-tête et Pied de page prête à confusion ; il faudrait peut-être introduire la notion de meta information.

La balise section

Dans l’article Éléments HTML 5 de structure on trouve un exemple de l’utilisation d’une balise section dans une balise article. Si j’ai bien compris la partie des spécifications consacrée à la notion de Sectioning Content et à l’élément section, ce dernier agit comme une «remise à zéro» de la hiérarchie des niveaux de titres.

The section element represents a generic document or application section. A section, in this context, is a thematic grouping of content, typically with a heading

Mettre une balise section à l’intérieur d’une balise article n’est donc pas l’idéal : le h1 du titre de l’article (et les éventuels éléments présents dans son header) n’est plus en relation avec les niveaux de titres situés dans le corps de l’article lui-même. Et ce, d’autant plus que l’élément article possède également le statut de Sectioning Content. Il vaudrait mieux faire le contraire.

Ainsi, au lieu de : 

body
    header
    div#content
        article
            header
            section
Je trouve plus logique d’utiliser : 
body
    header
    section#content
        article
            header
            div.hentry
div.hentry n’est pas une obligation : on pourrait très bien s’en passer en attaquant directement l’article sous le header mais on a généralement besoin d’élément permettant de gérer les padding et autres margin ou placer un background. Utilisation qui est dans les cordes de notre bonne vieille balise div désormais réservée au scripting ou à l’application de styles CSS.

La balise nav

The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.

L’élément nav possède également des propriétés de Sectioning Content. Il ne serait donc pas très judicieux de l’englober avec une balise section. Celà dit, il est facile de confondre la balise nav avec ce que l’on appelle la Sidebar. Une barre latérale contient souvent des liens qui pointent vers des pages intérieures du site (catégories, derniers billets, commentaires récents, etc.) mais on y trouve aussi toute sortes de contenus qui ne pointent nullement vers le site (textes de présentation, blogroll, publicités, listes des derniers tweets, etc.).

Pour ma part, je réserverais l’élément nav aux menus de navigation tels que : Breadcrumbs, listes des pages et des catégories, pages suivantes et précédentes, liens d’évitement, etc.

Ce qui m’amène à continuer la structure précédente : 

body
    header
    section#content
        article
            header
            div.hentry
    section#sidebar-1
        nav#category
        section#blogroll
Ici, l’imbrication des sections n’est pas préjudiciable à la hiérarchie des titres de niveaux hn, puisque chaque section (y compris nav, donc) est indépendante et possède sa propre hiérarchie.  C’est pourquoi je n’ai pas retenu l’élément aside pour remplacer nav en raison de la diversité des contenus présent dans une sidebar. Toutefois, lorsque les éléments de la « barre latérale » se rapportent globalement au contenu principal  (les articles en l’occurrence), il vaut mieux se tourner vers aside.

Bref, HTML5, des fois c’est facile, des fois… pas facile. Rassurez-vous (ou pas) : j’aurais l’occasion de revenir sur HTML5 plus souvent qu’à mon tour car écrire sur ce sujet me permets de sortir un peu la tête des spécifications !

Articles sur le même sujet

flattr this!

]]> http://css.4design.tl/html5-et-si-on-evitait-la-balise-section-dans-une-balise-article/feed 13 HTML5 — Pourquoi «header» et «footer» ne créent pas de «sections» http://css.4design.tl/html5-pourquoi-header-et-footer-ne-creent-pas-de-sections http://css.4design.tl/html5-pourquoi-header-et-footer-ne-creent-pas-de-sections#comments Wed, 24 Mar 2010 16:00:39 +0000 Bruno Bichet http://css4design.com/?p=5890 Les nouvelles balises introduites par HTML5 ne sont pas très évidentes à utiliser. Plus que jamais, le contenu est roi et tout dépend de lui. Les notions de Sectioning Content implicites ou explicites risquent de se transformer en poil à gratter pour les intégrateurs web. Pour commencer, notre balise div préférée devra laisser du terrain à la balise section quand on pourra justifier d’un h1 à l’intérieur.

Ce titre de premier niveau mène la danse et pourra inspirer l’intitulé de l’id de la section. Plus que jamais, l’intégrateur web devra avoir une solide culture générale. Il lui faudra tout au moins s’intéresser suffisamment aux contenus qu’il met en page pour savoir où commencent et où finissent les idées de ses clients !

Durant mes tests, j’ai beaucoup hésité sur l’utilisation de la balise header. Celle que l’on pensait forcément prévue pour prendre la place de notre div id="header" ne s’est pas vu attribuée ce rôle de manière formelle et univoque dans les spécifications. Elle pourra servir dans plusieurs contextes en conjonction (ou pas) avec une balise footer ; mais pas le footer que l’on place généralement tout en bas de la page page… Dans les faits, l’utilisation des balises header et footer est à géométrie variable.

Modèles de document HTML5

HTML5 introduit la notion de Sectioning Content. Pour faire simple, une section regroupe un ensemble de titres de plusieurs niveaux formant une unité logico-sémantique. Lorsqu’un deuxième h1 est nécessaire, c’est qu’on se trouve dans une autre «section».  Les sections sont implicites et suivent la hiérarchie des balises h1, h2, etc. mais on peut les formaliser avec les balises article, aside, nav ou… section.

La première remarque qui m’est venue à l’esprit en voyant la liste des balises ayant le statut de «section», c’est qu’il manquait les balises header et footer !

Les éléments HTML se retrouvent dans zéro ou plusieurs catégories en fonction de leurs caractéristiques.

Le modèle de document HTML5 se compose de : metadata content, flow content, sectioning content, heading content, phrasing content, embedded content et interactive content. (Source : W3C)

Pourquoi les balises header et footer n’en font pas partie ?

Très bonne question. La premier élément de réponse tient certainement à la nature équivoque de ces balises : elles peuvent se trouver à l’intérieur des sections introduites par body, article, nav, aside ou section pour regrouper le titre (ou les titres avec hgroup) et des informations complémentaires sur le contenu (date, auteur, etc.).

La deuxième, c’est peut-être pour les utiliser afin de regrouper des informations dans l’en-tête et le pied de page du site, sans les couper des autres informations. De cette manière, les informations contenues dans header et footer concernent toute la page (voire tout le site web), ce qui est plus logique.

Reste le Sectioning implicite. Est-ce à dire qu’il faut éviter d’utiliser des niveaux de titre dans notre en-tête et notre pied de page ?

Articles sur le même sujet

flattr this!

]]> http://css.4design.tl/html5-pourquoi-header-et-footer-ne-creent-pas-de-sections/feed 14 The HTML Framework Project | Phase 1.1 — définir http://css.4design.tl/the-html-framework-project-phase-11-definir http://css.4design.tl/the-html-framework-project-phase-11-definir#comments Fri, 05 Sep 2008 02:25:23 +0000 Bruno Bichet http://www.css4design.com/?p=1681 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></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

flattr this!

]]> http://css.4design.tl/the-html-framework-project-phase-11-definir/feed 8