Eric Range hat sich mit dieser Blog-Post-Idee gemeldet. Ist es besser, ein Header-Tag in einen Ankerlink einzubetten oder umgekehrt? Unter der Annahme von HTML5 sind beide völlig gültig.
Link im Header
<h1>
<a href="#">
Ten Ways to Have Yourself a Merry Little Christmas
</a>
</h1>
Header im Link
<a href="#">
<h1>
Ten Ways to Have Yourself a Merry Little Christmas
</h1>
</a>
Also, wofür entscheiden Sie sich? Ich würde sagen, das kommt darauf an.
Klickbarer Bereich
Standardmäßig ist das Anker-Tag ein Inline-Element und der Header ein Block. Ohne dies mit CSS zu ändern, ist der klickbare Bereich für h1 > a der hellrote Bereich hier

Im Gegensatz zum Ansatz a > h1, bei dem der Block-Header vollständig klickbar wird.

CSS könnte den Link im oberen Beispiel leicht auch zu einem Block-Element machen, aber das wäre der normale Standard.
Sie denken vielleicht: „Mehr klickbarer Bereich! Das ist gut!“, was legitim ist, aber es wirkt sich auf Folgendes aus
Textauswahlfreundlichkeit
Wie wichtig das ist, überlasse ich Ihnen. Aber ich bin ein „von unten rechts“-Selektor und hasse Block-Level-Links aus diesem Grund immer.

Layout-Kuriosität
Sie können dies einfach beobachten und sicherstellen, dass Sie dies in CSS berücksichtigen, aber es gibt eine seltsame Fallstrick, wenn Sie den Ansatz a > h1 wählen, bei dem ein Innenabstand des Links zu einer Situation wie dieser führen würde.

Zwei Header, ein Link
Wenn Sie jemals einen verknüpften Titel und Untertitel benötigen (und Sie keinen Untertitel mit einem Kind-Span oder Ähnlichem verwenden möchten), könnte der umschließende Anker nett sein.
<a href="#">
<h1>Cheese is favorite holiday gift</h1>
<p class="subtitle">From a one-person survey held in central Wisconsin</p>
</a>
Zugänglichkeitsbedenken
Ich bin mir nicht sicher, fürchte ich. Gibt es welche?
Gewinner?
Ich neige dazu, h1 > a zu mögen, und eine informelle Umfrage zeigt, dass die überwiegende Mehrheit der Leute das auch tut.
Dennoch eine Überlegung wert.
Ich liebe den kleinen Ragequit-Tanz, den Ihr Cursor macht, wenn Sie versuchen, den verknüpften Header auszuwählen.
Mehr zum Thema: Ist es nicht an der Zeit, dedizierte <a>nker-Tags ganz abzuschaffen und einfach die href="" und target="" Parameter für alle Elemente zuzulassen?
Veralten, nehme ich an
Relevant: http://meyerweb.com/eric/thoughts/2008/07/23/any-element-linking-demo/
In Google Canary alles gut mit der Auswahl, scheint es mir
Mist, löschen wir doch den vorherigen Kommentar und versuchen es nochmal, diesmal mit der Vorschau…
Ich liebe den kleinen Ragequit-Tanz, den Ihr Cursor macht, wenn Sie versuchen, den verknüpften Header auszuwählen… so klassisch und ach so vertraut!
Mehr zum Thema: Ist es nicht an der Zeit, dedizierte
<a>nker-Tags ganz abzuschaffen und einfach diehref=""undtarget=""Parameter für alle Elemente zuzulassen?* Veralten, nehme ich an
Michael: das ist ein guter Punkt. Warum kann nichts klickbar sein?
Zusammen mit Chris' Link habe ich noch ein wenig mehr recherchiert. Es scheint, dass es wirklich auf die Semantik zurückgeht, wie diese Erklärung auf Stack Overflow zusammenfasst.
Um Dave's Frage zu beantworten: „Warum kann nichts klickbar sein?“
Denn dann müsste alles auch per Tastatur fokussierbar sein. Das würde die Benutzerfreundlichkeit und Barrierefreiheit erheblich beeinträchtigen.
Alles *kann* verlinkbar sein. Es muss auch nicht die Barrierefreiheit beeinträchtigen, solange Sie bereit sind, auf Benutzer ohne JavaScript zu verzichten.
Fügen Sie [role="link"] zu jedem als Link behandelten Element hinzu, lösen Sie
open(url, target)aus, um Links zu verarbeiten (stellen Sie nur sicher, dass ein Linksklick standardmäßig auf _self und ein Mittelklick auf _blank gesetzt wird) und fügen Sie [tabindex="0"] hinzu, um das Element in die Tabulatorreihenfolge aufzunehmen.Vielen Dank, dass Sie einige der UX-Probleme mit jedem Ansatz hervorgehoben haben. Wichtiger als persönliche Präferenzen oder Internetumfragen ist es vielleicht, fallweise und unter Berücksichtigung der Erwartungen der Benutzer zu bauen. Zum Beispiel bietet Bootstrap Collapse, das Codebeispiele mit dem A-Tag innerhalb des H4 (ja, H4) liefert, wenig in Bezug auf Tipp-Affordanzen, da es sich auf Fitts' Gesetz bezieht und wie Benutzer mit collapsing panels interagieren erwarten – die ohnehin typischerweise als Display-Block angezeigt werden.
Ich habe vielleicht wenig bis gar keine Ahnung von Barrierefreiheit, aber ich denke, es ist alles eine Frage der Semantik.
a > h1würde implizieren „Dieser gesamte Header ist ein Link“, währendh1 > aimplizieren würde „Es gibt einen Link in diesem Header.“Das Problem mit der Textauswahl ist genau der Grund, warum ich die genaue Auswahl von Dingen aufgegeben habe und dazu übergegangen bin, den Text am Ziel zu ändern.
Haha! Ich bin auch ein „von unten rechts“-Selektor! Ich bin auch ein „h1 > a“-Typ, nur viel besser, denke ich. Ich stimme auch Orangestar zu und den geäußerten Kommentaren zur Barrierefreiheit – es sollte eigentlich kein Problem sein, aber ‚h1> a‘ wäre wahrscheinlich ‚ordentlicher‘.
Ich mag falsch liegen, aber ich dachte immer, es sei ungültig, Block-Level-Elemente (
h1) in Inline-Elemente (a) einzufügen?Es war für HTML <= 4 ungültig, aber es ist gültiges HTML 5. (Und selbst wenn es in HTML 4 technisch ungültig war, wurde es von Browsern unterstützt.)
Ich dachte, das wäre auch eine semantische Regel.
Ich benutze „h1 > a“ … es gibt Ihnen auch die Möglichkeit, mehrere Links innerhalb des h2 zu haben.
Es war früher ungültig. Mit HTML5 nicht mehr.
Ich schätze, ich bin ein Dinosaurier :P Danke!
Block-Level innerhalb von Inline ist ziemlich seltsam. Bald werden wir Code wie diesen sehen
http://codepen.io/anon/pen/QwKwgO.html
Der Browser kann es rendern, aber für mich ist das nicht sehr semantisch. (Markdown versteht es nicht einmal)
Jetzt, wo Dinge wie diese gültig sind, bedeutet das auch, dass Sie Code schreiben können, wie Sie wollen.
@Kyrodes, „Dinge wie diese“ sind immer noch ungültig,
ulkann immer noch nurli(oderscript) direkt enthalten, und ‚Block-Level‘ innerhalb von ‚Inline-Level‘ sind immer noch ungültig (erstens, weil es keine ‚Inline‘- oder ‚Block‘-Elemente *in HTML* mehr gibt, es gibt *Formulierungselemente*, um Text-Semantik auszudrücken, und strukturelle/gruppierende Elemente, um den Text in Absätze und Abschnitte zu gruppieren, die entweder mit Inline-Level- oder Block-Level- *CSS-Boxen* angezeigt werden können). Aber dasa-Element ist kein ‚Formulierungs‘- (‚ex-Inline‘-) Element mehr, es ist jetzt wie HTML4'sinsoderdel– sein Inhaltsmodell hängt von seinem tatsächlichen Inhalt ab. Natürlich sollten Sie ihmdisplay:blockgeben, wenn Sie etwas mitdisplay:blockdarin platzieren wollen, aber das ist nur eine CSS-Sache.Kyrodes, großartiger Punkt mit diesem Beispiel. Ich werde das einfach mit meinem Codepen einbetten, damit andere nicht den externen Link anklicken müssen.
http://codepen.io/bl4ckdu5t/pen/JoRXdY
Siehe den Pen JoRXdY von Joseph Rex (@bl4ckdu5t) auf CodePen.
Egal wie oft ich das nachschlage, ich kann garantieren, dass ich es beim nächsten Mal sowieso wieder vergesse und wieder hier bin…
Wahrscheinlich lese ich meinen eigenen Kommentar.
Hallo Nick – schon zurück?
Da Browser Anker standardmäßig als Inline-Elemente behandeln, habe ich das auch zu meinem Standard gemacht. Aber wenn die übliche
h1 > a-Technik zu viel Duplizierung (der gleiche Anker, der 2- oder 3-mal für nebeneinander liegende Elemente wie Thumbnails, Unterüberschriften usw. wiederholt wird) oder mangelnde Offensichtlichkeit hinsichtlich des klickbaren/tappbaren Bereichs führt (siehe Joshs früherer Kommentar), dann wechsle ich gerne die Reihenfolge.Auf Mobilgeräten (zumindest auf iOS) führt die Auswahl von „Header in Link“ zur Auswahl des Link-Elements und nicht des Textes im Header. Das kann wirklich nervig sein!
Ich habe mich immer mit der Textauswahlfreundlichkeit herumgeschlagen und nie daran gedacht, dass es daran lag!
Ich bevorzuge immer noch den
a > h1-Ansatz, einfach weil ich es nie mochte, dass sich mein Cursor beim Hovern zwischen den Zeilen eines Inline-aaufdefaultändert. Der klickbare Bereich fühlt sich einfach etwas schmaler an und als ob ich den Klick wirklich treffen müsste, im Gegensatz zu einem Block-Level, der einenaumschließt. Fühlt sich irgendwie nach einfacherer Navigation an, nehme ich an.Ich bin fest im h1 > a-Lager, und einer der Gründe ist, dass ich denke, dass das Styling von Elementen (Hover, Fokus, Aktiv) innerhalb von Links etwas mühsam ist.
Ich bin hierher gekommen, weil ich dachte, es sei eine Diskussion über das
header-Element, basierend auf dem Titel des Beitrags. Das hat meine Neugier geweckt.Um Verwechslungen zu vermeiden: Für
h1,h2usw. ist ein genaueres Wort Überschriften-Tags oder Überschriften-Elemente. Das W3C-Vokabular bezeichnet diese HTML-Elemente als Überschriften. (Referenz)Entschuldigung, dass ich dieser Typ bin…
Auf jeden Fall ist das eine großartige Diskussion. Ich habe mich schon länger (wahrscheinlich über ein Jahr) mit einer ähnlichen Frage beschäftigt, ob es besser ist, als
strong>aodera>strongzu markieren.Das ist mir noch nie aufgefallen, bis es hier diskutiert wurde, aber ich wähle auch Text auf Webseiten von rechts nach links (oder von unten rechts nach oben links). Wer macht das noch? Das erscheint mir seltsam/kontraproduktiv, wenn ich darüber nachdenke. Das ist eine Usability-Studie, die darauf wartet, durchgeführt zu werden.
Ich habe eine Theorie für meine Rechts-nach-Links-Textauswahlgewohnheit, basierend auf meinen Lesegewohnheiten. Mein Mauszeiger ist nach rechts am Bildschirm geneigt, weil vertikale Scrollbalken normalerweise rechts im Browserfenster liegen. Eine Rechts-nach-Links-Auswahl ist also schneller, basierend auf Fitts' Gesetz.
Du bist der Beste, Bro :) Ich wünschte… ich wünschte… egal, vielen Dank. Und meine Adresse ist http://www.e-kitaphanem.com
Ich mache das auch so. Habe nie viel darüber nachgedacht, aber die Argumentation mit der Selektierbarkeit ist interessant.
Es gibt einige Fallstricke, die man bei der Verwendung von Block-Level-Links in Bezug auf die Barrierefreiheit beachten muss. Roger Johansson hat vor einiger Zeit einen großartigen Artikel dazu geschrieben.
Aber es gibt auch Vorteile, besonders wenn man an den Vanilla-Anwendungsfall denkt (ein Header mit einem Absatz und einem „Weiterlesen“-Link)
erhöhte Benutzerfreundlichkeit: nur ein Link mit größerem klickbarem/tappbarem Bereich
erhöhte Barrierefreiheit: „Weiterlesen“ in einem Screenreader ist so nützlich wie ein Schokoladenkeks
Ich dachte, es gäbe keinen Unterschied zwischen den beiden. Übrigens, nachdem ich das gelesen habe, bevorzuge ich h1 > a. Weil es viel mehr Sinn ergibt und auch benutzerfreundlich ist.
Wow! Schönes Dilemma XD
Semantisch bevorzuge ich es, weil ich denke, es ist ein generischerer Tag als <a>, und in diesem Fall, aus SEO-Gründen, benötigt HTML nur ein h1 pro semantischer Gruppe, aber Sie können mehr als eines mit verschiedenen <a>s enthalten. (Bitte verzeihen Sie mein Englisch :S)
Die im Artikel erwähnte „Layout-Kuriosität“ ist tatsächlich das korrekte Verhalten des visuellen CSS-Modells gemäß der CSS2.1-Spezifikation. Es hat nichts mit der Art der verwendeten HTML-Elemente zu tun, es ist nur das, was passiert, wenn man versucht, eine Block-Level-CSS-Box (alles mit
display:blockoderdisplay:tableoderdisplay:flex) in einen Inline-Formatierungskontext (alles mitdisplay:inline) zu platzieren. Im folgenden kleinen Demo habe ich versucht zu erklären, was hier passiert: http://jsfiddle.net/h0ws2c2h/2/HTML5 erlaubt es nicht, „Blocks in Inline zu stecken“, es verwendet nur nicht die *Begriffe* „Block“ und „Inline“ :). Diese Begriffe werden jetzt nur noch in CSS verwendet, und in CSS kann man immer noch keine „Blocks“ innerhalb von „Inline“-Dingen haben, Blocks können nur in Block-Containern leben (obwohl manchmal der CSS-Renderer sie implizit für Sie erstellt, wie in diesem Fall). Das Verschachteln von *HTML-Elementen* und das Verschachteln von *CSS-Boxen* haben jetzt getrennte Logiken, aber beide sollten korrekt verschachtelt werden. Eine gute Faustregel, um anonyme Blöcke und ihre „Kuriositäten“ zu vermeiden, ist daher,
display:block(oderinline-block) auf alles anzuwenden, das etwas mitdisplay:blockenthält, unabhängig von der Art des HTML-Elements, solange die HTML5-Spezifikation eine solche Verschachtelung von Elementen zulässt.Einige relevante Links: HTML5 Check it before you wreck und HTML5 Accessibility Chops: Block Links
Ich bevorzuge
h1 > awegen der Kompatibilität. In Browsern mit keiner oder begrenzter HTML5-Unterstützung (hust hust IEhust) kanna > h1auf meist vorhersehbare, aber auch seltsame und überraschende Weise fehlschlagen.Warum sollte man überhaupt einen Link in einen
H1oder umgekehrt einfügen?H1ist doch der aktuelle Seitentitel, oder? Wo sollte der Link hinkommen?Ich denke, die Tatsache, dass der Artikel über
h1spricht, ist irrelevant. Denken Sie eher daran als an jede Überschrift,h1-h6. Und es gibt Szenarien, in denen Sie dies tun möchten, zum Beispiel eine Blog-/Nachrichtenübersicht, in der Sie einen Titel + Teaser pro Beitrag sehen. Sie möchten vielleicht, dass der Beitragstitel zu der vollständigen Beitragsseite verlinkt ist. Das vereinfachte Markup-Muster dafür könnte so aussehen:<article class="article-stub">
<h2><a href="postpage.php">Mein Blogbeitrag</a></h2>
<p>Lorem ipsum…</p>
<p><a href="postpage.php">Mehr erfahren</a></p>
</article>
h1 ist mit dem HTML5-Outline-Algorithmus nicht mehr unbedingt der aktuelle Seitentitel.
nichts Konstruktives zu sagen, ich war sehr amüsiert von Ihrer sichtbar frustrierten Maus im Textauswahl-GIF.
Ich habe Block-Elemente immer als Container für Inline-Elemente betrachtet, daher fühlt sich „a > h1“ für mich seltsam an.
Ich sehe es definitiv als eine Überschrift, die verknüpften Inhalt enthält, und nicht als einen Link, der Überschrifteninhalt enthält. Es wird normalerweise als Überschrift und nicht als Link gestylt, daher spiegelt das Markup dies wider.
Das
a-Element ist kein ‚Inline-Element‘ mehr. Ab HTML5 hat es das gleiche ‚transparente‘ Inhaltsmodell wieinsunddelin HTML4.Diese Änderung mit HTML 5 war mir nicht bekannt. Danke. Das ändert irgendwie alles.
Beeinflusst
a > h1nicht negativ die SEO? Kommentare zu iOS/Touch-Geräten und dem Kopieren von Links anstelle von Text sind ebenfalls gut zu bedenken.Ich persönlich verwende die erste h2 (oder h1, das hängt davon ab) wie
<a>Firma Inc. stellt Maschinen für YYY her</a>für bessere SEO und blende den Text mit CSS aus.Dies ist eines von mehreren Dingen, die XHTML 2 behoben hat und die wir beim Sprung zu HTML 5 verloren haben. In XHTML 2 kann *jedes* Element ein
href-Attribut haben (das es mit anderen Ressourcen im Web verknüpft) und *jedes* Element kann einsrc-Attribut haben (wodurch ersetzte Inhalte wie Bilder ermöglicht werden).@Jon
Wir haben nichts verloren, da Browser-Implementierer kein Interesse hatten, es war ein schöner Traum, vielleicht.
Ich bin im h1 > a-Lager, ABER ich bin auch fest im Bootstrap-Lager, das diese Situation meiner Meinung nach perfekt handhabt. Es lohnt sich, es sich anzusehen. Die Sache ist, dass man CSS verwenden kann, um das a-Element passend zum Elternelement zu machen, und ehrlich gesagt, wir haben wichtigere Dinge zu tun, oder?
Nein, „Link im Park“ LOL
In HTML5 ist es auch erlaubt, div in
<a>zu verwenden, oder?