Sollte sich die Hauptnavigation in HTML5 innerhalb oder außerhalb des <header> -Elements befinden?


167

In HTML5 weiß ich, dass <nav>dies entweder innerhalb oder außerhalb des Masthead- <header>Elements der Seite verwendet werden kann. Bei Websites mit sowohl sekundärer als auch Hauptnavigation scheint es üblich zu sein, die sekundäre Navigation als <nav>Element innerhalb des Masthead- <header>Elements und die Hauptnavigation als <nav>Element außerhalb des Masthead- <header>Elements einzuschließen . Wenn der Website jedoch die sekundäre Navigation fehlt, scheint es üblich zu sein, die Hauptnavigation in ein <nav>Element innerhalb des Masthead- <header>Elements aufzunehmen.

Wenn ich diesen Beispielen folge, basiert meine Inhaltsstruktur auf dem Einschluss oder Ausschluss der sekundären Navigation. Dies führt eine Kopplung zwischen dem Inhalt und dem Stil ein, die sich unnötig und unnatürlich anfühlt.

Gibt es einen besseren Weg, um die Hauptnavigation nicht von innen nach außen zu verschieben <header>, basierend auf dem Einschluss oder Ausschluss der sekundären Navigation?

Beispiel für Haupt- und Sekundärnavigation

<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 ist eine Beispielseite, die dem obigen Muster folgt.

Geben Sie hier die Bildbeschreibung ein

Hauptnavigationsbeispiel

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

Keyzo.co.uk ist eine Beispielseite, die dem obigen Muster folgt.

Geben Sie hier die Bildbeschreibung ein

Auszüge aus der Einführung von HTML5 - Hinzugefügt am 02.02.11, 07:38 Uhr

Die Einführung von HTML5 von Bruce Lawson und Remy Sharp hat Folgendes zu diesem Thema zu sagen:

Der Header kann auch eine Navigation enthalten. Dies kann für die Site-weite Navigation sehr nützlich sein, insbesondere bei vorlagengesteuerten Sites, bei denen das gesamte <header>Element aus einer Vorlagendatei stammen könnte.

Natürlich ist es nicht erforderlich, dass die <nav>in der <header>.

Dies hängt weitgehend davon ab, ob Sie der Meinung sind, dass die Site-weite Navigation in den Site-weiten Header gehört, und auch von pragmatischen Überlegungen zur einfachen Gestaltung.

Basierend auf diesem letzten Satz scheint Bruce Lawson - Autor des Kapitels, aus dem diese Auszüge stammen - zuzugeben, dass "pragmatische Überlegungen zur einfachen Gestaltung" eine Kopplung zwischen Inhalt und Stil ergeben.


1
Dies hängt ganz vom Design Ihrer Website ab. Nehmen wir zum Beispiel Twitter, die Homepage (die Seite, die Sie sehen, bevor Sie sich angemeldet haben) hat keine Top-Navigation. Alle ihre "Hauptmenü" Sachen sind am Ende der Seite. Nun, ich weiß nichts über dich - aber ich würde das nicht als Header bezeichnen ...
uSeRnAmEhAhAhAhAhA

Antworten:


84

Es liegt ganz bei Ihnen. Sie können sie entweder in die Kopfzeile einfügen oder nicht, solange die darin enthaltenen Elemente nur interne Navigationselemente sind (dh keine Links zu externen Websites wie einem Twitter- oder Facebook-Konto), ist dies in Ordnung.

Sie werden in der Regel in einen Header eingefügt, nur weil dort häufig navigiert wird, aber nicht in Stein gemeißelt.

Weitere Informationen finden Sie unter HTML5 Doctor .


5
Warum geben Sie an, dass "solange die darin enthaltenen Elemente nur interne Navigationselemente sind (dh keine Links zu externen Websites wie einem Twitter- oder Facebook-Konto erstellen), ist dies in Ordnung"?
Matthew Rankin

7
@Matthew, da das nav-Element nur für die Navigation auf dieser Site vorgesehen ist. Ich war nur klar ist alles.
Ian Devlin

@MatthewRankin Was für ein Schock wäre es, auf einen Anker innerhalb eines <nav>Elements zu klicken , um dann auf eine neue Seite mit völlig anderer Navigation gesendet zu werden. Denken Sie bei Ankern an externen Websites ohne echte Beziehung zu Ihrer eigenen auch an das rel="nofollow"Attribut für Links.
Anthony Rutledge

Ich weiß, dass dies alt ist ... Was ist mit Links zu Subdomains? Zum Beispiel eine Website mit unterschiedlichen Websites (Präsentationssite, Service-Site, Auth-Site usw.), die alle unterschiedliche Strukturen haben. Ich platziere diesen Link innerhalb des <nav>Elements, aber nicht innerhalb des <ul>Elements, und gestalte ihn so, dass er nicht Teil der Hauptnavigationsliste ist. Mit Ausnahme der mobilen Version muss der Link in derselben Liste erscheinen ... Wie auch immer, die Schaltfläche ist beschreibend genug, um zu wissen, dass Sie woanders hingehen ...
Chazy Chaz

5

Es ist ein wenig unklar, ob Sie nach Meinungen fragen, z. "Es ist üblich, xxx zu machen" oder eine tatsächliche Regel, also werde ich mich in Richtung der Regeln lehnen.

Die Beispiele, die Sie zitieren, scheinen auf den Beispielen in der Spezifikation für das nav-Element zu basieren . Denken Sie daran, dass die Spezifikation immer weiter optimiert wird und die Regeln manchmal verworren sind. Daher würde ich wagen, dass viele Leute dazu neigen, nur das zu tun, was gegeben ist, anstatt zu interpretieren. Sie zeigen zwei separate Beispiele mit unterschiedlichem Verhalten, sodass Sie nur so viel hineinlesen können. Haben beide Standorte auch die gegnerische Sub- / Navi-Situation und wenn ja, wie gehen sie damit um?

Vor allem aber gibt es nichts in der Spezifikation entweder sagt , ist die Art und Weise , es zu tun. Eines der Ziele bei HTML5 war es , [dies zum Vergleich] über Semantik, Anforderungen usw. klar zu machen , daher ist die Auslassung erwähnenswert. Soweit ich sehen kann, sind die Beispiele unabhängig voneinander und gleichermaßen gültig in ihrem eigenen Kontext von Layoutanforderungen usw.

Die Quellposition des Navis bedingt zu haben, ist irgendwie albern (eine weitere rote Fahne). Wählen Sie einfach eine Methode und machen Sie mit.


4

Ich mag es nicht, das Navi in den Header zu setzen . Meine Argumentation ist:

Logik

Die Kopfzeile enthält einführende Informationen zum Dokument. Das Navi ist ein Menü, das auf andere Dokumente verweist . Für mich bedeutet dies, dass der Inhalt des Navigationsgeräts eher zur Site als zum Dokument gehört. Eine Ausnahme wäre, wenn der Nettoinventarwert Forward-Links enthält.

Barrierefreiheit

Ich setze Menüs lieber am Ende des Quellcodes als am Anfang. Ich verwende CSS, um es an den oberen Rand eines Computerbildschirms zu senden, oder lasse es am Ende für Text-Sprach-Browser und kleine Bildschirme. Dies vermeidet die Notwendigkeit von Sprunglinks.


2
Denken Sie daran, dass das Überspringen von Links die OPTION zum Überspringen des Menüs bietet, während das Setzen am Ende nicht die Option bietet, nicht zu überspringen (dh zu navigieren). Daher müssten Sie bis zum Ende warten, um ordnungsgemäß navigieren zu können , richtig?
Julix

2
Um mit @ julix fortzufahren, platzieren Sie das Navi am Ende, aber das Rendern am Anfang macht es für sehende Benutzer unangenehm, durch das Dokument zu tippen.
Jason T Featheringham

3

@ IanDevlin ist korrekt. Die MDN-Regeln lauten wie folgt :

"Das HTML-Kopfzeilenelement" "definiert einen Seitenkopf - enthält normalerweise das Logo und den Namen der Site und möglicherweise ein horizontales Menü ..."

Das Wort "möglicherweise" gibt es Schlüssel. Der Header muss nicht unbedingt ein Site-Header sein. Beispielsweise könnten Sie einen "Header" in ein Popup-Modal oder in andere modulare Teile des Dokuments einfügen, in denen sich ein Header befindet, und es wäre hilfreich, wenn ein Benutzer auf einem Bildschirmleser darüber informiert wäre.

In Bezug auf die implizite Verwendung von NAV können Sie es überall dort verwenden, wo es eine gruppierte Site-Navigation gibt, obwohl es normalerweise im Abschnitt "Fußzeile" für Mini-Navis / wichtige Site-Links weggelassen wird.

Es kommt wirklich auf die persönliche / Teamwahl an. Entscheiden Sie, was Sie und Ihr Team für semantischer und wichtiger halten, und versuchen Sie, konsistent zu sein. Wenn das Navi mit dem Logo und dem "h1" der Hauptwebsite übereinstimmt, ist es für mich sinnvoll, es in den "Header" einzufügen. Wenn Sie jedoch eine andere Designauswahl haben, entscheiden Sie von Fall zu Fall.

Schauen Sie sich vor allem die Dokumente an und stellen Sie sicher, dass Sie verstehen, warum Sie diese bestimmte Entscheidung treffen, wenn Sie sie weglassen oder einschließen.


2

Um zu erweitern, was @JoshuaMaddox im MDN-Lernbereich im Abschnitt "Einführung in HTML" gesagt hat, heißt es im Unterabschnitt " Dokument- und Website-Struktur" (fett / hervorgehoben von mir):

Header

Normalerweise ein großer Streifen über der Oberseite mit einer großen Überschrift und / oder einem Logo. Hier bleiben die wichtigsten allgemeinen Informationen zu einer Website normalerweise von einer Webseite zur anderen.

Navigationsleiste

Links zu den Hauptabschnitten der Website; normalerweise dargestellt durch Menüschaltflächen, Links oder Registerkarten. Wie der Header bleibt dieser Inhalt normalerweise von einer Webseite zur anderen konsistent. Eine inkonsistente Navigation auf Ihrer Website führt nur zu verwirrten, frustrierten Benutzern. Viele Webdesigner betrachten die Navigationsleiste eher als Teil der Kopfzeile als als einzelne Komponente. Dies ist jedoch keine Voraussetzung. Einige argumentieren sogar, dass es für die Zugänglichkeit besser ist, die beiden Funktionen getrennt zu haben, da Bildschirmleser die beiden Funktionen besser lesen können, wenn sie getrennt sind .


1
Ich möchte zustimmen, dass eine <nav>, die flach auf einer Seite strukturiert ist, möglicherweise zugänglicher ist als eine <nav>, die tiefer verschachtelt ist. Auf welcher Grundlage wird dieses Urteil jedoch gefällt? Screenreader gehen sowieso nach Hause <nav>und <a>markieren. Der wichtige Faktor ist die strukturelle Reihenfolge des HTML. Als nächstes Reaktionsfähigkeit. Erleichtert es die Manipulation des primären <nav>(oder eines <nav>) direkten Kindes <body>? Ist das gültiges HTML? A <nav>ist sectioning Gehalt und ist somit ein natürlicher Sitz innerhalb einer lebt sectioning Wurzel , wie <body>. Siehe W3C HTML5
Anthony Rutledge
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.