Quelques notes sur la balise h1 avec HTML5

Rigueur. Et passion !

Ne dites pas à ma mère que je suis artisan en architecture de l'information appliquée aux sites web : elle croit que je suis webdesigner, intégrateur HTML & CSS, rédacteur web, formateur NTIC et consultant en webmarketing depuis 2001 ! Voulez-vous en savoir plus ?

Le blog de l'intégrateur web

Quelques notes sur la balise h1 avec HTML5

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 h1h6, 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 h1h6 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

PS : Le respect de la vie privée sur internet est important : j'ai décidé d'échanger mon bouton Like de Facebook par un bouton Faire un don de Paypal car
Il n'y pas d'amour, il n'y a que des preuves d'amour (Jean Cocteau) ;) Merci d'avance.



37 commentaires pour “Quelques notes sur la balise h1 avec HTML5”

  1. Aurélien dit :

    Est-ce que tu sais si Google a déjà communiqué sur ce sujet ? Je sais que c’est un sujet de discorde entre référenceurs, mais globalement il est admis qu’on ne met qu’une balise h1 par page. Google va-t-il faire la différence entre un h1 sur une page html classique et plusieurs h1 sur une page en html5 ?

  2. Alban dit :

    Il ne me semble pas que google se soit exprimé pour l’instant, mais par contre on peut regarder le code source de leur site html5 rocks pour voir comment ils implémentent les h1. Moi je serais partant pour respecter les nouvelles specs et pourvoir mettre des h1 dans chaque section.

  3. Loiseau2nuit dit :

    Je ne suis pas spécialement d’accord !

    Même sur le papier, les documents n’ont qu’un seul gros titre (h1) les sections détaillées ensuite dans le document étant par nature des « enfants » de ce document, doivent avoir un H2.

    Pour ce qui est du point de vue SEO, trop de h1 tue le h1 et comme il semble que ce soit le seul capable de compléter efficacement les autres métas données de la page, il faut non seulement l’optimiser mais surtout ne pas le noyer.

    Puis, entre nous soit dit, avoir plusieurs h1 sur une page, c’est comme si un bouquin avait 50 couvertures quelque part, c’est pas cohérent.

    Bon après ca n’engage que moi hein mais quand même ^^

  4. Alban dit :

    Je viens de regarder le site de google sur l’html5 et ils suivent un peu ce que dit l’oiseau de nuit : a savoir un h1 et les sections avec des h2.

  5. C’est noté & tweeté :)

  6. [...] This post was mentioned on Twitter by geekbay rss, Dotpress. Dotpress said: Quelques notes sur la balise #h1 avec #HTML5: La réponse courte à la question « Combien de balises h1 dans une page… http://goo.gl/fb/Hyh7X [...]

  7. GizMecano dit :

    Si on veut suivre la comparaison avec l’objet livre, ne suffit-il pas de considérer que seul un h1 inclus dans un header corresponde en fait au fameux titre de couverture évoqué ?

  8. Bruno Bichet dit :

    Loiseau2nuit, Alban >

    En fait, l’idée c’est que la page Web n’est pas réductible au(x) document(s) qu’elle contient. La première balise h1 (par exemple pour le logo), se rapporte à la section la plus proche (par exemple le body). On le voit bien lorsqu’on utilise le Outliner HTML5 pour voir l’imbrication des différentes sections.

    Cette notion de section la plus proche est la base de la sémantique introduite par html5, elle concerne également l’élément address qui peut se rapporter à l’ensemble du document s’il suit la balise body, ou tout autre élément en fonction des sections où on le place.

    Pour en revenir à la solution choisie par Google, il faut se rappeller qu’il n’a jamais été un exemple en terme de balisage.

    Mais surtout, l’intérêt de HTML5 ce de permettre presque tout, à condition que le ramage se rapporte au plumage ;)

    GizMecano >

    C’est un choix valable, mais ce n’est pas le seul choix possible. Je suis convaincu que HTML5 est propice à l’expérimentation, alors essayons de sortir des sentiers battus !

  9. burninghat dit :

    C’est là que je me dis que les gars qui nous pondent ces normes feraient bien d’ouvrir une fois Word (titre, puis titre1, titre2, titre3, etc. et notion de sections) ou mieux d’aller regarder du côté de LaTeX. Parce que tout en s’adressant à priori à la création de supports papiers, ces deux logiciels (pour faire simple, désolé pour les puristes de LaTeX) ont résolu ce genre de problème simplement et avec élégance depuis longtemps.

  10. Ah ! un très bon article sur le sujet. Le nouvel algo d’HTML5 qui sert à l’extraction de la structure du document permet effectivement de bien voir l’arbre du document.

    J’utilise l’extension de Chrome HTML5 Ouliner et je me suis aperçu que ce n’était pas encore très clair après avoir pourtant fait bon nombre d’efforts pour comprendre comment ce balisage sémantique. Un exemple ? On veut placer la balise sidebar pour un contenu en rapport article à l’intérieur de l’article même. Je m’imaginais que la seule présence de sidebar permettait d’avoir un contenu bien séparé. Eh bien non. Si on met la sidebar ainsi ça ne marche pas :

    article H1 H2 sidebar H1 H2 H2 H2

    Les 2 H2 qui suivent la sidebar et qui devraient appartenir à l’article se retrouvent raccordés à l’article. Pour y remédier, il faut sectionner tout l’article :

    article H1 section H2 section sidebar H1 H2 /section /section H2 H2

    Ça devient vite énervant…

    Par contre le châpo n’est pas un résumé. Le résumé a d’ailleurs ses propres balises : details, puis summary.

    Je l’utilise sur mon blog : sur la home de la catégorie j’extraie le résumé et quand on rentre sur l’article on part sur le chapô tandis que le résumé se retrouve sur la colonne de droite. La règle étant que celui-ci ne soit visible qu’à la demande du lecteur.

    Bref, tout cela est assez compliqué et depuis plus d’un an que je code en HTML5 (voir HTML5 machin chose je n’ai toujours pas de preuve tangible d’un bénéfice côté référencement.

  11. Loiseau2nuit dit :

    Oui, en dehors du fait que je n’utilise jamais de h1 dans les heander de mes sites parce que ce n’est pas prévu pour ça et que, derrière le logo du site, ya souvent unlien vers la home et que les liens en home sont moins bien (pour ne pas dire « pas du tout ou presque ») pris en compte pour le SEO

    Non, je reste fixée à mon idée que le H1, c’est 1 seul par document pour le qualifier dans son ensemble. Ensuite, h2 qualifie ses sections.

    Lookez sur OpenWeb je ne pense pas qu’ils vous diront des choses sensiblement différentes des miennes, html5 ou pas d’ailleurs ;)

    Mais je le re-dis, ca n’engage que moi hein, alors pas taper (ou pas la tête !) ^^

  12. Loiseau2nuit dit :

    ah merdoum !

    que les liens en home sont moins bien (pour ne pas dire « pas du tout ou presque ») pris en compte pour le SEO

    Il fallait bien sur lire « les liens EN BALISE HX » et non pas « en home ». Désolé…

  13. Très intéressant, j’en apprends en même temps sur le HTML5 et sur le référencement : je ne savais pas que le Title devait être unique sur la page (pas répété dans le H1) : il me semble avoir lu plusieurs fois le contraire, mais c’est vrai que c’est plus logique (ce n’est pas très naturel sinon). Je vais de ce pas changer mes balises H1. ;)

    Merci pour l’article

  14. Loiseau2nuit dit :

    @Bigg : disons pour être clair que si tu dois choisir entre 2 optimisations, c’est le title qui doit faire l’objet de toutes tes attentions. Ca peut reprendre ton h1 mais le mieux est d’adapter ton H1 pour qu’il tape des mot-clés complémentaires à ton title (principe d’optimisation de la longue traine)

    Si déjà entre title et h1 t’as une bonne combo, quelque part les urls propres sont presque superflues derrières ;)

    Mais de base, les 2 éléments les plus importants pour le ref de ta page sont title et h1 d’où l’intérêt de ne surtout pas les multiplier dans la page sinon tu risques : - soit de foutre toute ta SEO par terre - soit de te faire blacklister par Google pour suroptimisation, ce qui en soit, revient à epu près au même donc…

  15. Merci pour cet article synthétique et intéressant à propos du balisage html5 et son implication dans le cadre du référencement d’un site Web.

    Pour ma part, je pense que le contenu rédactionnel prévaut car il permet de se distinguer de la masse d’article sur Internet traitant d’un sujet similaire.

    Il faut un balisage bien fait pour se faire comprendre au mieux par les moteurs de recherche.

    A partir du moment où il y a un balisage respectueux du W3C. Alors on peut chipoter et tenter de s’approcher toujours plus près de la perfection de la structure et des balises de son code.

    Mais le contenu entre les deux balises :

    …..

    est celui qui fait la plus-value et sans lequel il n’y a pas de page Web à écrire !

    Encore merci

  16. LaurentB dit :

    Belle démonstration. J’ai eu plus de mal à expliquer que trop de H1 tue le H1 dans mon billet sur le sujet. http://www.laurentbourrelly.com/blog/640.php

    La question du HTML5 est encore plus intéressante, même si je pense que sa généralisation n’est pas pour (demain ou même après demain). En tout cas, je me penche assidument sur le sujet et je suis en ce moment même en train de bosser sur mon tout premier site en HTML5.

  17. Aïe, les gueguerres de H1 en SEO.

    Autant je rejoins Laurent et loiseaudenuit sur la théorie, autant on se rend compte des milliers d’exemples contraires qui fonctionnent bien (les blog WP avec H1 et Title et URL idem par défaut).

    Mon avis est de moins en moins tranché sur le sujet. Les tests que j’ai fait ne remontent rien de significatif, bref, je nage en plein flou artistique.

    En fait, je traite vraiment ce cas au cas par cas. Un vieux site bien ranké pourra faire n’importe quelle cochonerie et tout passe. Un jeune site aura intérêt à limiter au maximum la suroptimisation. Dans ce dernier cas, les recommandations de Loiseau et Laurent sont à suivre à la lettre.

  18. @Loiseau2nuit : merci beaucoup pour ces précisions et tes conseils précieux!

  19. LaurentB dit :

    Bien sûr qu’il faut prendre chaque site comme un cas particulier! C’est ce que je dis dans mon billet, mais les gens ne lisent pas forcément tout. Les facteurs principaux qui permettent de supporter une suroptimisation relative étant évidemment âge du domaine et autorité/popularité.

  20. @Loiseau2nuit : merci pour ces précisions et conseils très précieux!

  21. [...] — Quelques notes sur la structure des pages Web avec h1 et section 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 [...]

  22. pas sûr que section section h1 {…} soit plus simple que h3 {…}

    C’est clair, styler les h1 différemment selon leur profondeur n’est pas simple.

    D’où ma tentative HTML5 Titles Inception … ;-)

    • Bruno Bichet dit :

      Merci Nicolas pour cet excellent html5 titles inception. J’ai ajouté une note à ce sujet dans le billet, et un lien dans la linkograhie.

      On voit bien que Less est beaucoup plus concis, mais je me suis toujours demandé (sans avoir vraiment cherché de réponse) si on ne déportait pas trop de choses sur le serveur depuis quelque temps ? Quelqu’un a fait des calculs ?

      • Merci pour le lien ! ;-)

        Concernant LESS, pas de problème de perfs côté serveur, vu que je génère la « vraie » CSS à la volée directement quand j’édite ma CSS LESS, grâce à l’appli LESS.app pour Mac.

  23. Loiseau2nuit dit :

    Euh… Woaw oO ! Je crois que l’approche qui reste la plus light est celle de Nicole Sullivan à ce stade :

    h1, .h1 {…} h2, .h2 {…} …

    • Quand tu génères le contenu avec un CMS, tu ne sais pas toujours à l’avance à quelle profondeur sera ton contenu, d’autant plus si un même contenu peut servir à plusieurs profondeur selon les endroits du site.

      S’appuyer uniquement sur des h1 « sectionnés » et mon HTML5 Titles Inception est alors un grand confort. C’est visible sur mon site.

      • Loiseau2nuit dit :

        Peut être faudrait voir à l’usage, moi ce que je vois surtout, c’est la complexité que prend d’un coup la CSS pour styler un truc aussi simple qu’un titre en fait, j’avoue que je ne suis pas habitué à ça. Peut être aussi parce que depuis quelques temps je travaille sur des projets à plusieurs mains et que du coup le plus simple reste encore une garantie qu’aucune boulette ne sera commise en amont comme en aval… je sais pas. Je passe en test on verra bien :-)

        • Nous sommes bien d’accord que c’est inutilement compliqué et lourd (et sans doute pas très performant pour le dessin de la page par le navigateur), mais en attendant que tous les navigateurs supportent le sélecteur any() de Firefox, c’est bien utile ! ;-)

  24. LaurentB dit :

    Côté SEO, on reste quand même pendu à une réponse du Dieu Google par rapport à la prise en compte du HTML5. Si j’en crois des indices comme ceux là http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=146750 les micro formats commencent à émerger, mais j’aimerai être sur des bases solides avant de revoir le balisage de fond en comble.

  25. Bruno Bichet dit :

    LaurentB — C’est en forgeant que l’on devient forgeron, et je suis convaincu qu’il faut se mettre le plus rapidement possible à expérimenter HTML5 pour être prêt.

    Dans une optique SEO, c’est différent : si c’est pour faire du « keyword stuffing », autant rester avec une seule balise h1 pour éviter de se faire blackbouler ;))

    Sinon, si un article présente plusieures parties distinctes, autonomes, pourquoi ne pas les introduire avec plusieurs h1, même si d’un autre point de vue, on aurait plutôt intérêt à écrire plusieurs billets, mais c’est un autre débat ;)

    • LaurentB dit :

      Vi vi j’ai mis les mains dans le cambouis http://www.laurentb.me/ Pour l’instant, c’est juste un thème chopé chaisplusoù, mais ça m’a permis de voir comment c’est foutu. Prochaine étape est d’étoffer le site avec des tests pour voir la prise en compte par Google.

      Sinon, oui je pense aussi que si le H1 de section doit revenir sur une même page, c’est peut-être qu’il fallait déporter sur une autre page.

      • Loiseau2nuit dit :

        Ah ben Laurent je vois que tu te fais plaisir ^^

        Ben en même temps, roulez donc jeunesse parce que si c’est moi qui fait le test (ce qui était implicitement prévu) vous n’aurez pas le résultat avant 2018 compte tenu de l’emploi du temps à venir …

        Mais plus j’y pense et moins je vois pourquoi html5 révolutionnerait si fondamentalement le SEO / la nature même d’un document.

        Le balisage exotique (html5, microformat, etc…) est une chose, la structure globale d’un document en revanche, en est une autre et reste immuable AMHA.

        De toute façon, là c’est même pas Google qu’il faut attendre, c’est le W3C. On parle d’un standard qui n’est pas vraiment finalisé et au train où vont les choses c’est pas pour demain. Peut être pas un hasard si GG ne communique dessus que du bout des lèvres….

  26. Marisol Perry dit :

    argh, la balise « code » ne semble pas fonctionner… :-(

  27. [...] Quelques notes sur la balise h1 avec HTML5 [...]

  28. [...] La réponse courte à la question « Combien de balises h1 dans une page Web HTML5 ? » est : « Autant que nécessaire !  [...]

  29. […] 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  […]

Laissez un commentaire

Vous pouvez utiliser les balises HTML suivantes : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Les commentaires sont publiés sous votre pleine et entière responsabilité et ne doivent pas contrevenir aux lois et règlementations en vigueur. Les propos racistes ou antisémites, diffamatoire ou injurieux, divulguant des informations fausses, relatives à la vie privée d'une personne ou utilisant des oeuvres protégées par les droits d'auteurs ne sont pas les bienvenus et seront modérés sans modération.

Merci d'être constructif et n'oubliez pas : « sans la liberté de ramer il n'est point d'éloge flotteur ! »



Colophon

CSS & Webdesign est une publication irrégulomadaire à tendance hebdomadaire
éditée par Bruno Bichet qui carbure à WordPress et au café équitable.
Tous droits réservés © 2006 - 2011.

Contactez l'auteur du site