En HTML5, ¿la navegación principal debe estar dentro o fuera del elemento <header>?

167

En HTML5, sé que <nav>se puede usar dentro o fuera del <header>elemento de encabezado de la página . Para los sitios web que tienen navegación secundaria y principal, parece común incluir la navegación secundaria como un <nav>elemento dentro del <header>elemento de cabecera con la navegación principal como un <nav>elemento fuera del <header>elemento de cabecera . Sin embargo, si el sitio web carece de navegación secundaria, parece común incluir la navegación principal en un <nav>elemento dentro del <header>elemento de cabecera .

Si sigo estos ejemplos, mi estructura de contenido se basará en la inclusión o exclusión de la navegación secundaria. Esto introduce un acoplamiento entre el contenido y el estilo que se siente innecesario y antinatural.

¿Hay alguna manera mejor de no mover la navegación principal de adentro hacia afuera del <header>elemento de cabecera según la inclusión o exclusión de la navegación secundaria?

Ejemplo de navegación principal y secundaria

<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 es un sitio de ejemplo que sigue el patrón anterior.

ingrese la descripción de la imagen aquí

Ejemplo de navegación solo principal

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

Keyzo.co.uk es un sitio de ejemplo que sigue el patrón anterior.

ingrese la descripción de la imagen aquí

Extractos de la presentación de HTML5 : agregado el 02-feb-11, 7:38 a.m.

La presentación de HTML5 por Bruce Lawson y Remy Sharp tiene esto que decir sobre el tema:

El encabezado también puede contener navegación. Esto puede ser muy útil para la navegación en todo el sitio, especialmente en sitios controlados por plantillas donde todo el <header>elemento podría provenir de un archivo de plantilla.

Por supuesto, no se requiere que <nav>esté en el <header>.

Si depende en gran medida de si cree que la navegación en todo el sitio pertenece al encabezado de todo el sitio y también de consideraciones pragmáticas sobre la facilidad de diseño.

Con base en esa última oración, parece que Bruce Lawson, autor del capítulo del que provienen esos extractos, admite que las "consideraciones pragmáticas sobre la facilidad del estilo" producen un acoplamiento entre el contenido y el estilo.

Matthew Rankin
fuente
1
Depende completamente del diseño de su sitio web. Tomemos Twitter, por ejemplo, su página de inicio (la página que ves antes de iniciar sesión) no tiene navegación superior. Todas sus cosas del "menú principal" se encuentran al final de la página. Ahora, no sé sobre ti, pero no diría que es un encabezado ...
uSeRnAmEhAhAhAhAhA

Respuestas:

84

Depende completamente de usted. Puede ponerlos en el encabezado o no, siempre que los elementos dentro de ellos sean solo elementos de navegación internos (es decir, no se vinculen a sitios externos como una cuenta de Twitter o Facebook), entonces está bien.

Tienden a colocarse en un encabezado simplemente porque ahí es donde a menudo va la navegación, pero no está escrito en piedra.

Puede leer más al respecto en HTML5 Doctor .

Ian Devlin
fuente
55
¿Por qué afirma que "mientras los elementos dentro de ellos sean solo elementos de navegación internos (es decir, no se vinculen a sitios externos como una cuenta de Twitter o Facebook), entonces está bien"?
Matthew Rankin
77
@Matthew porque el elemento de navegación es solo para navegar por ese sitio. Estaba siendo claro, eso es todo.
Ian Devlin
@MatthewRankin Qué sorpresa sería hacer clic en un ancla dentro de un <nav>elemento, solo para ser enviado a una nueva página con una navegación completamente diferente. Para las anclas a sitios externos sin una relación verdadera con la suya, recuerde también el rel="nofollow"atributo de los enlaces.
Anthony Rutledge
Sé que esto es viejo ... ¿Qué pasa con los enlaces a subdominios? Por ejemplo, un sitio web que tiene diferentes sitios (sitio de presentación, sitio de servicio, sitio de autenticación, etc.), todos tienen una estructura diferente. Lo que estoy haciendo es colocar ese enlace dentro del <nav>elemento pero no dentro del <ul>elemento, dándole un estilo que no forme parte de la lista de navegación principal. Con la excepción de la versión móvil, el enlace debe aparecer en la misma lista ... De todos modos, el botón es lo suficientemente descriptivo como para saber que vas a ir a otro lado ...
Chazy Chaz
5

No está claro si está pidiendo opiniones, por ejemplo. "es común hacer xxx" o una regla real, así que me inclinaré en la dirección de las reglas.

Los ejemplos que cita parecen estar basados ​​en los ejemplos en la especificación del elemento nav . Recuerde que las especificaciones se modifican constantemente y las reglas a veces son complicadas, por lo que me atrevería a decir que muchas personas tienden a hacer lo que se da en lugar de interpretar. Está mostrando dos ejemplos separados con un comportamiento diferente, por lo que solo hay mucho que puede leer en él. ¿Alguno de esos sitios también tiene la situación opuesta de sub / nav, y si es así, cómo lo manejan?

Sin embargo, lo más importante es que no hay nada en la especificación que diga que tampoco es la forma de hacerlo. Uno de los objetivos con HTML5 era ser muy claro [esto para comparación] sobre semántica, requisitos, etc., por lo que vale la pena señalar la omisión. Hasta donde puedo ver, los ejemplos son independientes entre sí e igualmente válidos dentro de su propio contexto de requisitos de diseño, etc.

Tener la posición de origen del navegador condicional es algo tonto (otra bandera roja). Simplemente elige un método y ve con él.

Su '
fuente
4

No me gusta poner el navegador en el encabezado . Mi razonamiento es:

Lógica

El encabezado contiene información introductoria sobre el documento. El navegador es un menú que enlaza con otros documentos. En mi opinión, esto significa que el contenido de la navegación pertenece al sitio más que al documento. Una excepción sería si el NAV mantuviera enlaces hacia adelante.

Accesibilidad

Me gusta poner menús al final del código fuente en lugar del inicio. Utilizo CSS para enviarlo a la parte superior de la pantalla de una computadora o lo dejo al final para navegadores de texto y pantallas pequeñas. Esto evita la necesidad de omitir enlaces.

Otro geek
fuente
2
tenga en cuenta que los enlaces de omisión le dan la OPCIÓN de omitir el menú, mientras que poner al final no le da la opción de no omitir (es decir, navegar), por lo que se verá obligado a esperar hasta el final para poder navegar correctamente , ¿derecho?
Julix
2
Para continuar en el punto de @ julix, colocar el navegador al final, pero representarlo al principio hará que resulte incómodo para los usuarios videntes que examinan el documento.
Jason T Featheringham
3

@IanDevlin es correcto. Las reglas de MDN dicen lo siguiente :

"El elemento de encabezado HTML" "define un encabezado de página, que generalmente contiene el logotipo y el nombre del sitio y posiblemente un menú horizontal ..."

La palabra "posiblemente" es clave. Continúa diciendo que el encabezado no necesariamente debe ser un encabezado de sitio. Por ejemplo, podría incluir un "encabezado" en un modo emergente o en otras partes modulares del documento donde haya un encabezado y sería útil que un usuario en un lector de pantalla lo conozca.

En términos del uso implícito de NAV, puede usarlo en cualquier lugar donde haya una navegación de sitio agrupada, aunque generalmente se omite de la sección "pie de página" para mini-navegaciones / enlaces importantes del sitio.

Realmente se trata de elección personal / de equipo. Decida qué es lo que usted y su equipo consideran más semántico e importante y trate de ser coherente. Para mí, si el navegador está en línea con el logotipo y la "h1" del sitio principal, entonces tiene sentido ponerlo en el "encabezado", pero si tiene una opción de diseño diferente, decida caso por caso.

Lo más importante es consultar los documentos y asegúrese de que si elige omitir o incluir, comprende por qué está tomando esa decisión en particular.

Joshua Maddox
fuente
2

Para ampliar lo que dijo @JoshuaMaddox, en el Área de aprendizaje de MDN, en la sección "Introducción a HTML", la subsección Estructura de documento y sitio web dice (en negrita / énfasis es mío):

Encabezamiento

Por lo general, una gran franja en la parte superior con un gran encabezado y / o logotipo. Aquí es donde la información común principal sobre un sitio web generalmente permanece de una página web a otra.

Barra de navegación

Enlaces a las secciones principales del sitio; generalmente representado por botones de menú, enlaces o pestañas. Al igual que el encabezado, este contenido generalmente permanece constante de una página web a otra: tener una navegación inconsistente en su sitio web solo conducirá a usuarios confundidos y frustrados. Muchos diseñadores web consideran que la barra de navegación es parte del encabezado en lugar de un componente individual, pero eso no es un requisito; de hecho, algunos también sostienen que tener los dos separados es mejor para la accesibilidad, ya que los lectores de pantalla pueden leer las dos características mejor si están separados .

mach128x
fuente
1
Quiero estar de acuerdo en que una <nav>estructura poco profunda en una página puede ser más accesible que una <nav>que está más anidada. Sin embargo, ¿sobre qué base se está haciendo ese juicio? Los lectores de pantalla irán a casa con etiquetas <nav>y <a>etiquetas, de todos modos. El factor importante es el orden estructural del HTML. A continuación, la capacidad de respuesta. ¿Hacer que el primario <nav>(o alguno <nav>) sea un hijo directo de <body>hace que sea más fácil de manipular? ¿Es eso HTML válido? A <nav>está seccionando contenido y, por lo tanto, es una forma natural de vivir dentro de una raíz de seccionamiento , como <body>. Ver W3C HTML5
Anthony Rutledge