How do links around block elements translate in older browsers?

Question

HTML5 allows for links to be wrapped around block elements (one or several), but how exactly will it render in older browsers? Let's say to go as far back as IE6.

I haven't found full details yet (but there are some examples).

The markup would be as follows:

<a href="http://example.com">
  <section>
    <h3>Heading</h3>
    <p>Text</p>
  </section>
</a>

Also, would the most semantic way to make it compatible in older browsers be to wrap the links inside each block element separately? I've seen suggestions to replace the block elements with span, but that'd make it inline and alter the meaning of headings.

I've noticed that even modern browsers (e.g. Safari on iOS 6) do weird things. For example, try clicking on the image in this JSFiddle from your mobile brwoser — even though it shares the link with the caption below, the caption doesn't get highlighted for me. Furthermore, when clicking the caption, the image nor caption get highlighted.

score 2 · Accepted Answer · answered Dec 09 '12 at 00:00

2

As far as I know, the behavior is generally the same as modern browsers. Everything in the sample markup given will turn into a single hyperlink. This is regardless of whether or not you include the HTML5 shiv for older IEs to recognize the new semantic elements.

This is probably because there's nothing in HTML that says a specific starting tag should automatically close an unclosed <a> tag — the end tag is required to denote the end of a hyperlink.

And yes, that's how I'd do it to preserve semantics if I want to conform to an older HTML doctype. It's not required for HTML5 conformance though, since it works based on the assumption that even older browsers already behave this way (backward compatibility and everything).

answered Dec 09 '12 at 00:00

BoltClock

700,868
160
1,392
1,356

Ah, really? Thanks, that explanation would make sense. (Also, I added to the question.) – Baumr Dec 09 '12 at 00:03
Thanks, that makes sense — however, take a look at the question for an interesting test on mobile – Baumr Dec 09 '12 at 00:17
1

@Baumr: That I have no idea — seems like Mobile Safari's doing its own thing with tap highlights. It does still treat both the image and the caption as having the same destination, though, at least. – BoltClock Dec 09 '12 at 00:23

score 2 · Answer 2 · answered Dec 09 '12 at 08:51

Relaxing the content model for a in HTML5 is based on observations on actual browser behavior: the original syntactic requirements were not really enforced. This can be expected to go as far as you can get. (I tested this on IE 6 and Firefox 3.)

So there is no need for compatibility. But it would surely not be “semantic” to split a link element. Two links are semantically different from one link, for any reasonable semantics for “semantic”. It would also be a usability problem, especially when using the keyboard to move between links.

The visual rendering is a different issue. It is not clear at all, from the HTML5 drafts or from practical considerations, how a link should be rendered, in its different states, when it may contain just about anything. This may have been a key reason behind the old syntactic requirement. Browsers do not render such links consistently. This applies at least to underlining. There can be functional differences, too; e.g., on some browsers, the area on the right of the heading text is not clickable, i.e. only the text is “active”, whereas other browsers make the entire area of the element (which is by default the entire available width for a heading) “active”.

So the basic issue, if you wish to use such a link, is to consider how you intend to have it rendered and how to do that in CSS in a manner that works reasonably cross-browser.

How do links around block elements translate in older browsers?

2 Answers2