Eric Range wrote in with this blog post idea. Is it better to wrap a header tag in an anchor link, or the other way around? Assuming HTML5, both of these are completely valid.
Link in header:
<h1>
<a href="#">
Ten Ways to Have Yourself a Merry Little Christmas
</a>
</h1>
Header in link:
<a href="#">
<h1>
Ten Ways to Have Yourself a Merry Little Christmas
</h1>
</a>
So which one do you go for? I’d say it depends.
Clickable area
By default, the anchor tag is an inline element and the header is a block. So without altering that with CSS, the clickable area for h1 > a
is the light red area here:

Versus the a > h1
approach where the block level header becomes entirely clickable.

CSS could easily make the link in the top example block-level too, but this would be the normal default.
You might think “More clickable area! That’s good!”, which is legit, but it does affect this:
Text selection friendliness
How big of a deal this is, I’ll let you decide. But I’m a “from the bottom right” selector and I always kinda hate block level links for this reason:

Layout weirdness
You can just watch for this and make sure you account for it in CSS, but there is a weird gotcha if you take the a > h1
approach where padding on the link would cause a situation like this:

Two headers, one link
If you ever needed a title-and-subtitle that is linked (and you didn’t want to subtitle with child span or something), the wrapping anchor might be nice.
<a href="#">
<h1>Cheese is favorite holiday gift</h1>
<p class="subtitle">From a one-person survey held in central Wisconsin</p>
</a>
Accessibility concerns
I’m not sure, I’m afraid. Are there any?
Winner?
I tend to like h1 > a
and an informal poll shows that the vast majority of folks do too.
Still, worth thinking about.
I <3 the little ragequit dance your cursor makes when trying to select the linked header.
More on topic, doesn't it seem like it's time to do away with* dedicated <a>nchor tags altogether and just allow the href=”” and target=”” parameters on all elements?
Deprecate, I guess
Relevant: http://meyerweb.com/eric/thoughts/2008/07/23/any-element-linking-demo/
in Google Canary all good with selection I seem
Doh, let’s just delete that previous comment and try again, using the preview thing this time…
I <3 the little ragequit dance your cursor makes when trying to select the linked header… so classic, and oh so familiar!
More on topic, doesn't it seem like it's time to do away with* dedicated
<a>
nchor tags altogether and just allow thehref=""
andtarget=""
parameters on all elements?* Deprecate, I guess
Michael: that’s a great point. Why can’t anything be clickable?
Along with Chris’ link, I did a little bit more research on the subject, it looks like it really goes back to semantics as this explanation on Stack Overflow sums it up.
To answer Dave’s question: “Why can’t anything be clickable?”
Because then everything should be focusable with a keyboard, too. It would make a great mess of usability and accessibility.
Anything can be linkable. It doesn’t have to lose accessibility either, so long as you’re willing to forgo users without JavaScript.
Add [role=”link”] to any element being treated as a link for semantics, trigger
open(url, target)
to handle links (just be sure that left click defaults to a target of_self
and a middle click defaults to a target of_blank
), and add[tabindex="0"]
to include the element in the tabbing order.Thanks for highlighting some of the UX concerns with each approach. Perhaps more important than personal preference or internet polls is to build on a per case basis and with user expectations in mind. For example, Bootstrap Collapse, which provides example code with the A tag inside the H4 (yes, H4) does little in the way of tap affordance as it relates to Fitt’s law and how users expect to interact with collapsing panels – which typically display block-level anyhow.
I might have little to no grasp on accessibility, but I think its all a matter of semantics.
a > h1
would imply “This entire header is a link” whileh1 > a
would imply “There is a link inside this header.”The text selecting problem is exactly why I’ve given up on exactly selecting stuff and resorted to modifying the text at the destination.
Haha! I’m a “from the bottom right” selector too! I am a ‘h1 > a’ person too, just much better I think. I also agree with Orangestar and the accessibility comments made – It shouldn’t really be an issue, but ‘h1> a’ would probably be ‘tidier’.
I may be wrong but I always thought it was invalid to put block-level elements (
h1
) inside an inline ones (a
)?It was invalid for HTML <= 4, but it's valid HTML 5. (And, even while being technically invalid in HTML 4, browsers supported it.)
I thought that was a semantic rule as well.
I use “h1 > a” … it also gives you the ability to have multiple links within the h2.
It used to be invalid. Not any more with HTML5.
Guess I’m a dinosaur :P Thx!
Block-level inside inline is pretty weird. Soon we will see code like this:
The browser can render it, but to me this is not much semantic. (Markdown don’t even understand it)
Now things like this are valid this also means you can write code anyway you want.
@Kyrodes, «things like this» are still invalid,
ul
still can’t contain directly anything butli
(orscript
), and ‘block-level’ inside ‘inline-level’ are still invalid, too (first of all because there are no more ‘inline’ or ‘block’ elements in HTML, there are phrasing elements to express text-level semantics and structural/grouping elements to group the text into paragraphs and sections, which can be displayed with either inline-level or block-level CSS boxes). But thea
element is not a ‘phrasing’ (‘ex-inline’) element any more, it’s like HTML4’sins
ordel
now — its content model depends on its actual content. Of course you should give itdisplay:block
if you want to place something withdisplay:block
inside it, but it’s just CSS thing.Kyrodes great point with that example. I’ll just embed that with my codepen to save others from having to click the external link
See the Pen JoRXdY by Joseph Rex (@bl4ckdu5t) on CodePen.
No matter how many times I look this up I can guarantee I will forget next time anyway and be back here…
Probably reading my own comment.
Hi Nick – back so soon?
Because browsers tends to treat anchors as inline elements by default, I’ve adopted that as my default as well. But when the usual
h1 > a
technique results in a lot of duplication (the same anchor repeated 2 or 3 times for adjacent elements like thumbnails, subheads, etc.) or a lack of obviousness in terms of the clickable/tappable area (see Josh’s earlier comment), then I happily switch up the order.On mobile (well at least on iOS) selecting header in link causes the select of the link element and not the text in the header. It can get really annoying!
I’d always stumbled with the text selection friendliness issue and never thought it was due to this!
I still personally prefer the
a > h1
approach simply because I’ve never liked having my cursor change todefault
when hovering between lines on an inlinea
. The clickable area just feels a bit narrower and like I reeeally need to nail the click, opposite to just having a block level wrappinga
. Sort of feels like easier navigation, I guess.I’m firmly in the h1 > a-camp, and one of the reasons is that I think styling elements (hover, focus, active) inside links is a bit of a pain.
I went here thinking it was a discussion about the
header
element based on the title of the post. That piqued my curiosity.To avoid confusion, for
h1
,h2
, etc. a more accurate term is heading tags or heading elements. W3 vocabulary refer to these HTML elements as headings. (reference)Sorry for being that guy…
In any event, this is a great discussion nonetheless. I’ve been wondering a similar question (for probably over a year now) of whether it’s better to mark up as
strong
>a
ora
>strong
.I’ve never noticed this until it was discussed here, but I also select text on web pages from right to left (or bottom-right to top-left). Who else does this? It seems odd/counter-intuitive when I think about it. This is a usability study waiting to happen.
I have a theory for my right-to-left text selection habit, based on my reading habits. My mouse pointer is biased to the right of the screen because vertical scroll bars are usually on the right of the browser’s viewport. So a right-to-left selection is faster based on Fitts’s Law.
you are the best bro :) ı wish… ı wish.. whatever ty so much. and my adres http://www.e-kitaphanem.com
I do it like this too. Never thought about it much, but the argument with the select-ability is interesting.
There are some pitfalls that you must be aware of when using block-level links, in terms of accessibility. Roger Johansson did a great write-up a while ago.
But there are advantages as well, especially if you think about the vanilla use-case (a header with a paragraph and a “read more” link):
increased usability: only one link with a greater clickable/tappable area
increased accessibility: “read more” in a screen reader is as useful as a chocolat teapot
I thought there is no difference between the two. BTW, after reading this, I prefer h1 > a. Because it makes much sense and also user friendly.
Wooow! Nice dilemma XD
In semantic terms, I prefer because I thing is more generical tag than <a>, and in this case, by SEO arguments, html only needs one h1 by semantic group, but you can put more than one containing different <a>. (Please forgive my english :S )
The ‘layout weirdness’ mentioned in the article is in fact the correct behavior of CSS visual model according to CSS2.1 spec. It has nothing to do with the type of HTML elements used, it’s only what occurs when one tries to place a block-level CSS-box (anything with
display:block
ordisplay:table
ordisplay:flex
) into inline formatting context (anything withdisplay:inline
). In the following small demo I tried to explain what happens here: http://jsfiddle.net/h0ws2c2h/2/HTML5 doesn’t allow ‘putting block into inline’, it just doesn’t use the terms ‘block’ and ‘inline’:). These terms are now used only in CSS, and in CSS you still can’t have ‘blocks’ inside ‘inline’ things, blocks can live only in block containers (although sometimes the CSS renderer creates them for you implicitly, like in this case). Nesting of HTML elements and nesting of CSS boxes have now separate logics, but both should be nested correctly. So a good rule of thumb to avoid anonimous blocks and their ‘weirdnesses’ is to set
display:block
(orinline-block
) to anything that contains anything withdisplay:block
, no matter of what type of HTML element it is, as long as HTML5 spec permits such nesting of elements.Some relevant links: HTML5 check it before you wreck and HTML5 Accessibility Chops: Block Links
I prefer
h1 > a
for compatibility. In browsers with no our limited HTML5 support (ahemIEcough),a > h1
can break in mostly predictable, but also odd and surprising ways.Why would you put a link inside a
H1
, or vice versa, at all?H1
is the current page title, isn’t it? Where would the link go?I think the fact that the article talks about
h1
is irrelevant. Think more of it like any heading,h1
–h6
. And there are scenarios where you would want to do this, for example a blog/news index where your seeing a title + blurb per post. You may want the post title to be linkable to the full post page. The simplified markup pattern for this may be something like this:<article class=”article-stub”>
<h2><a href=”postpage.php”>My blog post</a></h2>
<p>Lorem ipsum…</p>
<p><a href=”postpage.php”>Learn more</a></p>
</article>
h1 isn’t necessarily the current page title anymore, with the HTML5 outlining algorithm.
nothing constructive to say, i was very amused by your visibly frustrated mouse in the text selection gif.
I’ve always thought of block elements as being containers for inline elements so “a > h1” feels weird to me.
I definitely see it as a heading that contains linked content rather than a link that contains heading content. It’s usually styled as a heading rather than a link so it makes for the markup to reflect this.
The
a
element is not ‘inline element’ any more. As of HTML5, it has the same ‘transparent’ content model asins
anddel
elements had in HTML4.I wasn’t aware of that change with HTML 5. Thanks. That kind of changes everything.
Isn’t
a > h1
negatively affecting SEO? Comment about iOS/touch devices and copying link instead of text is also good to think about.Personally, I use the first h2 (or h1, it depends) like
<a>Company Inc. creates machines for YYY</a>
for better SEO and hide the text with CSS.This is one of several things XHTML 2 remedied that we lost in the jump to HTML 5. In XHTML 2, any element can have an
href
attribute (linking it to other resources on the Web) and any element can have asrc
attribute (enabling replaced content such as images).@Jon
We didn’t lose anything as browser implementers were not interested, it was a nice pipe dream, maybe.
I am in the h1 > a camp BUT I am also firmly in the Bootstrap camp, which handles this situation perfectly, imo. It’s worth checking out. The thing is, you can use css to make the a element fit the parent element and really, we have bigger things to worry about, don’t we?
No, “link in park” LOL
In html5 it’s also valid to use div inside
<a>
right?