En HTML5, la navigation principale doit-elle être à l'intérieur ou à l'extérieur de l'élément <header>?

167

En HTML5, je sais que cela <nav>peut être utilisé à l'intérieur ou à l'extérieur de l' <header>élément Masthead de la page . Pour les sites Web ayant à la fois une navigation secondaire et principale, il semble courant d'inclure la navigation secondaire en tant <nav>qu'élément à l'intérieur de l' <header>élément Masthead avec la navigation principale en tant <nav>qu'élément extérieur à l' <header>élément Masthead . Cependant, si le site Web ne dispose pas de navigation secondaire, il semble courant d'inclure la navigation principale dans un <nav>élément de l' <header>élément Masthead .

Si je suis ces exemples, ma structure de contenu sera basée sur l'inclusion ou l'exclusion de la navigation secondaire. Cela introduit un couplage entre le contenu et le style qui semble inutile et non naturel.

Existe-t-il un meilleur moyen de ne pas déplacer la navigation principale de l'intérieur vers l'extérieur de l' <header>élément de bannière Masthead en fonction de l'inclusion ou de l'exclusion de la navigation secondaire?

Exemple de navigation principale et secondaire

<header>
    <nav>
        <!-- Secondary Navigation inside <header> -->
        <ul>
            <li></li>
        </ul>
    </nav>
    <h1>Website Title</h1>
</header>
<nav>
    <!-- Main Navigation outside <header> -->
    <ul>
        <li></li>
    </ul>
</nav>

OnlineDegrees.org est un exemple de site qui suit le modèle ci-dessus.

entrez la description de l'image ici

Exemple de navigation principale uniquement

<header>
    <h1>Website Title</h1>
    <nav>
        <!-- Main Navigation inside <header> -->
        <ul>
            <li></li>
        </ul>
    </nav>
</header>

Keyzo.co.uk est un exemple de site qui suit le modèle ci-dessus.

entrez la description de l'image ici

Extraits de l' introduction de HTML5 - Ajouté le 02-févr.-11 à 07:38

Présentation de HTML5 par Bruce Lawson et Remy Sharp a ceci à dire sur le sujet:

L'en-tête peut également contenir la navigation. Cela peut être très utile pour la navigation à l'échelle du site, en particulier sur les sites basés sur des modèles où l'ensemble de l' <header>élément pourrait provenir d'un fichier modèle.

Bien sûr, il n'est pas nécessaire que le <nav>fichier soit dans le <header>.

Cela dépend en grande partie du fait que vous pensez que la navigation à l'échelle du site appartient à l'en-tête à l'échelle du site et des considérations pragmatiques sur la facilité de style.

Sur la base de cette dernière phrase, il semble que Bruce Lawson - auteur du chapitre dont ces extraits sont tirés - admet que «des considérations pragmatiques sur la facilité de style» donnent lieu à un couplage entre le contenu et le style.

Matthew Rankin
la source
1
Cela dépend entièrement de la conception de votre site Web. Prenez Twitter par exemple, leur page d'accueil (la page que vous voyez avant de vous connecter) n'a pas de navigation supérieure. Tous leurs trucs de «menu principal» sont au bas de la page. Maintenant, je ne sais pas pour vous - mais je n'irais pas appeler cela un en-tête ...
uSeRnAmEhAhAhAhAhA

Réponses:

84

Cela dépend entièrement de vous. Vous pouvez les mettre dans l'en-tête ou non, tant que les éléments qu'ils contiennent sont uniquement des éléments de navigation internes (c'est-à-dire ne pas créer de lien vers des sites externes tels qu'un compte Twitter ou Facebook), alors ça va.

Ils ont tendance à être placés dans un en-tête simplement parce que c'est là que la navigation va souvent, mais ce n'est pas figé.

Vous pouvez en savoir plus sur HTML5 Doctor .

Ian Devlin
la source
5
Pourquoi dites-vous que "tant que les éléments qu'ils contiennent sont uniquement des éléments de navigation internes (c'est-à-dire ne pas créer de lien vers des sites externes tels qu'un compte Twitter ou Facebook), tout va bien."?
Matthew Rankin le
7
@Matthew car l'élément nav sert uniquement à la navigation sur ce site. J'étais juste clair, c'est tout.
Ian Devlin le
@MatthewRankin Quel choc ce serait de cliquer sur une ancre à l'intérieur d'un <nav>élément, seulement pour être envoyé sur une nouvelle page avec une navigation entièrement différente. Pour les ancres vers des sites externes sans véritable relation avec les vôtres, rappelez-vous également l' rel="nofollow"attribut des liens.
Anthony Rutledge
Je sais que c'est vieux ... Qu'en est-il des liens vers des sous-domaines? Par exemple un site Web qui a des sites différents (site de présentation, site de service, site d'authentification, etc ...), ils ont tous une structure différente. Ce que je fais, c'est placer ce lien à l'intérieur de l' <nav>élément mais pas à l'intérieur de l' <ul>élément, en le stylisant d'une manière qui ne fait pas partie de la liste de navigation principale. À l'exception de la version mobile, le lien doit apparaître dans la même liste ... Quoi qu'il en soit, le bouton est suffisamment descriptif pour savoir que vous allez ailleurs ...
Chazy Chaz
5

Il est un peu difficile de savoir si vous demandez des opinions, par exemple. "c'est courant de faire xxx" ou une règle réelle, donc je vais me pencher dans le sens des règles.

Les exemples que vous citez semblent basés sur les exemples de la spécification de l'élément nav . N'oubliez pas que les spécifications ne cessent d'être modifiées et que les règles sont parfois alambiquées, alors j'oserais que beaucoup de gens aient tendance à faire ce qui est donné plutôt qu'à interpréter. Vous montrez deux exemples distincts avec un comportement différent, vous ne pouvez donc pas y lire beaucoup de choses. L'un ou l'autre de ces sites a-t-il également une situation de sous-navigation / sous-marine opposée, et si oui, comment la gèrent-elle?

Plus important encore, cependant, rien dans la spécification ne dit non plus la façon de le faire. L'un des objectifs de HTML5 était d'être très clair [ceci à titre de comparaison] sur la sémantique, les exigences, etc. donc l'omission mérite d'être notée. Autant que je sache, les exemples sont indépendants les uns des autres et également valables dans leur propre contexte d'exigences de mise en page, etc.

Avoir la position source de la navigation est conditionnelle est un peu idiot (un autre drapeau rouge). Choisissez simplement une méthode et allez-y.

Su '
la source
4

Je n'aime pas mettre le nav dans l'en- tête . Mon raisonnement est:

Logique

L'en- tête contient des informations introductives sur le document. La navigation est un menu qui renvoie à d'autres documents. À mon avis, cela signifie que le contenu de la navigation appartient au site plutôt qu'au document. Une exception serait si la NAV détenait des liaisons directes.

Accessibilité

J'aime mettre des menus à la fin du code source plutôt qu'au début. J'utilise CSS pour l'envoyer en haut d'un écran d'ordinateur ou le laisser à la fin pour les navigateurs de synthèse vocale et les petits écrans. Cela évite le besoin de sauts de liens.

Encore un autre geek
la source
2
gardez à l'esprit que sauter les liens donne OPTION pour sauter le menu, tandis que mettre à la fin ne donne pas l'option de ne pas sauter (c'est-à-dire de naviguer) - vous seriez donc obligé d'attendre la fin pour pouvoir naviguer correctement , droite?
Julix
2
Pour continuer sur le point de @ julix, placer le nav à la fin, mais le rendre au début le rendra gênant pour les utilisateurs voyants qui parcourent le document.
Jason T Featheringham
3

@IanDevlin a raison. Les règles de MDN disent ce qui suit :

"L'élément d'en-tête HTML" "définit un en-tête de page - contenant généralement le logo et le nom du site et éventuellement un menu horizontal ..."

Le mot «peut-être» y est clé. Il poursuit en disant que l'en-tête n'a pas nécessairement besoin d'être un en-tête de site. Par exemple, vous pouvez inclure un "en-tête" sur un modal pop-up ou sur d'autres parties modulaires du document où il y a un en-tête et il serait utile pour un utilisateur sur un lecteur d'écran de le savoir.

En termes d'utilisation implicite de NAV, vous pouvez l'utiliser partout où il y a une navigation groupée sur le site, bien qu'il soit généralement omis de la section "pied de page" pour les mini-navs / liens de sites importants.

Vraiment, cela se résume à un choix personnel / d'équipe. Décidez de ce que vous et votre équipe pensez être le plus sémantique et le plus important et essayez d'être cohérent. Pour moi, si la navigation est en ligne avec le logo et le "h1" du site principal, alors il est logique de le mettre dans "l'en-tête" mais si vous avez un choix de conception différent, décidez au cas par cas.

Plus important encore, consultez les documents et assurez-vous que si vous choisissez d'omettre ou d'inclure, vous comprenez pourquoi vous prenez cette décision particulière.

Joshua Maddox
la source
2

Pour développer ce que @JoshuaMaddox a dit, dans la zone d'apprentissage MDN, dans la section "Introduction au HTML", la sous-section Structure du document et du site Web dit (en gras / l'accent est sur moi):

Entête

Habituellement, une grande bande sur le dessus avec un grand titre et / ou logo. C'est là que les principales informations communes sur un site Web restent généralement d'une page Web à une autre.

Barre de navigation

Liens vers les principales sections du site; généralement représenté par des boutons de menu, des liens ou des onglets. Tout comme l'en-tête, ce contenu reste généralement cohérent d'une page Web à une autre - une navigation incohérente sur votre site Web ne fera que conduire à des utilisateurs confus et frustrés. De nombreux concepteurs Web considèrent que la barre de navigation fait partie de l'en-tête plutôt que d'un composant individuel, mais ce n'est pas une exigence; en fait, certains affirment également qu'il est préférable de séparer les deux pour l'accessibilité, car les lecteurs d'écran peuvent mieux lire les deux fonctionnalités si elles sont séparées .

mach128x
la source
1
Je veux convenir qu'un <nav>qui est structuré peu profond dans une page peut être plus accessible qu'un <nav>qui est imbriqué plus profondément. Cependant, sur quelle base ce jugement est-il porté? Les lecteurs d'écran vont de toute façon à la maison <nav>et aux <a>balises. Le facteur important est l'ordre structurel du HTML. Ensuite, la réactivité. Est-ce que faire du primaire <nav>(ou de tout autre <nav>) un enfant direct de <body>facilite la manipulation? Est-ce du HTML valide? A <nav>est un contenu de section , et est donc un ajustement naturel pour vivre dans une racine de section , comme <body>. Voir W3C HTML5
Anthony Rutledge