HTML5: Wrap Block-Level Elements with A’s

Dirty. Much prefer href attributes for any element, though I realize that there are semantic/accessibility issues there as well.

At first, it feels a bit icky. Since I’m used to the standards suggesting that you shouldn’t put block level elements inside anchor tags. But it does make sense, as most people (like me) end up just wrapping clickable chunks with a div tag, adding cursor:pointer in the CSS and then assigning a click event via JavaScript.

It makes sense that anchor tags should be able to be used like this, now it’s just adjusting to it :)

I have mixed feelings about this as well, but I think it makes more sense to handle this natively than with all the workaround options. Native anchor tags also bring small advantages like the default cursor: pointer and the use of the URL address bar.

I guess the question is whether it even matters to keep inline and block elements separate in the markup. These days devs just mess around with display: block / display: inline CSS to get around validation issues, when I would argue that it might be better to have invalid code than to jump through all these unnecessary hoops.

I have been doing this for a while now.

It’s actually very valuable, especially in context of mobile sites, where you you need to create large clickable lists with images and text hierarchy.

And for the record, I am super anal about HTML, so it’s not like I just don’t care. Furthermore, in CSS, I often turn my <a tags into block level elements anyways.

IMO adding href's to other elements would be muddying up the html, since it is adding extra interactive functionality to other elements. Also, it wouldn't be backwards compatible, and therefore could cause serious breakage on current browsers. Just imagine trying to support that…

Surely it only feels dirty because it’s been taboo for so long?

I for one am glad that we’ll be able to start using block-level elements inside anchors.

The js and display:block workarounds were okay but I prefer to use the browsers built in functionality wherever possible. It frustrated me when I can’t use context menus or drag/drop.

It’s fokkin awesome. Wonder why they didn’t accomplish this in ’4′…

May seem a bit wrong at first, but imagine doing visually the same as in the example code using only spans with display: block. Then turn CSS off and voilá – what a nice mess of elements we have! :)

Google has been doing this for a while I think (in their ads), so why not start as well…

It will take some getting used to, but it is a welcome change!

The Spec says its right but my mind says its wrong because it used to be wrong. It is ok now, so everyone: switch!

I know there was a fight to make href available for all elements. I think that’s a little more useful, but if the goal is to help create larger hit areas for mobile applications, this works fine.

I can see it being misused a bit. Not that anything is stopping them from misusing it now. I just want it to be clear on a page what I can click on that will end up taking me somewhere else. I don’t like surprises and neither do other visitors. CSS can be used to make this example presentable in a way that would clearly show it’s clickable, but I can see it becoming horrible as well, especially from less experienced designers. I doubt I’ll see myself making use of this. I haven’t had a need so far.

I actually really like this. Why use JS when it can be done with pure HTML?
And as it’s valid per Doctype why not use it? I started using html5 doctype quite a while ago. And doesn’t “standards compliant” actually mean “doctype-compliant”? the web evolves, so let’s evolve with it :-)

Finally! I am excited, now I really get to have fun with :fucus

Have you read A Book Apart’s HTML5 For Web Designers? Great little read, will take about an hour to go through the whole thing. It actually reads a lot like a series of blog entries — Dave, you should put a book together :)

I did not know this! And I’ve been using HTML5 for months.

I have absolutely no problem with it. I try to write clean code, but don’t sweat ‘validation’.

Awesome. :)

@Tim Wright: Wow, totally agree. That would save even more time. Now you have me dreaming about something that probably won’t see the light of day until HTML 7!

@David Walsh: When I first saw the proposal I quite liked it, but then I read some article about it mentioning how backwards compatibility would be affected – in a bad way. No older browsers would be able to make use of the href – and thats a “no go”.

Why break something that is the essence of the web – links?

I don’t like it, it just feels wrong. surely a link in a textual context should just be a small 2 or 3 words, with the title being a little more descriptive to screen readers.

nah, not feeling it at the moment. maybe it’s just an engrained developer thing. after all, lots of people are scared of change!

i like it … feels wonderfull … i will use it from now on … whats the problem guys?!

It could be terrible for screen readers and spiders and it must be used carefully and in a responsible manner.

Will not use it any soon…

I like it. I don’t really see a reason that block level elements shouldn’t be wrapped in “a” tags. I understand the idea of inline but links seem like those tags/types that are were “inline only” for arbitrary reasons. This makes sense to me.

I like it. There is no reason that we shouldn’t be able to wrap block level elements with an A tag. I don’t know how many times I’ve made a div with a header and a paragraph and a link, and then positioned that link absolutely and gave it a width/height of 100% so the entire element is click-able. It would be much more semantically correct to just wrap the objects with the A element.

Like a bunch of others, it feels a bit strange and just looks wrong but that’s because we’ve been taught to see it that way.

Like kcmr says above though, the effect that this could have on screen readers concerns me.

I probably won’t use it too often though. I like trying new things to blaze new paths, but in this case I think I’ll hold off until/if it becomes a bit more widespread and accepted.

I agree with others who say it only seems wrong because that’s been convention up until now – it’s a great idea and yet more of the ‘back to basics’ approach that’s accompanied other HTML5 additions.

As for why anyone would assign click events rather than make your anchor elements display:block with CSS is beyond me.

I’m a relitavely new web designer so its perfect for me needed this for a website i am currently designing.
2 thumbs up….

The main idea that brought about this decision was the ability to wrap entire table rows in anchors and/or put the href attribut on the table row tag. The decided not to allow any of that but they did decide to allow [a] to wrap anything. Sort of pointless imo.

On a quick simple page I’d probably use it. But on a dynamically built page the way I loop through and build my html strings I could see it actually getting in the way.

I prefer to keep the [a] inside the containing block and absolutely position it top:0; left:0; width: 100%; height:100% so that the anchor covers everything else in the containing block.

really nice thing didn’t knew its possible

I usually turn anchor tags into block-level elements via CSS, and use inline elements inside that. It has been working for me fine and is not hacky at all.

However there are times when you see the need to use something such as a div to separate stuff inside an anchor tag. I think the reason HTML5 allows you to do this is now is for the reason we all see this as a wrong practice: standards. If you’re going to semantically markup your HTML, might as well be able to use whatever tags you see fit inside anchors.

Of course we shouldn’t see this as a reason to wrap heading tags with anchors, but it simply gives us more freedom as to how we can semantically markup a “big link.”

What? Dirty? I’ve been doing this for a long time. Tough-titties that it did not validate. It is better that code works and is simple, rather than use a bunch of JS to squirm one’s way around the rules (yer still cheat’n smart-rat!). Better to break the rules directly, so that the powers-that-be get the message and check their values. In this case – who says that an A-tag has to be an in-line element, not a block element – and cannot in fact be both! Why is the distinction so important? And why not an exception to prove the rule? Nothing could be more *exceptional* than the trusty ‘lil A-tag, I say.

I like it! I wont wont have to use JavaScript to achieve such a simple task cause the validator don’t like it :S

I think it’s great but right now would only use for smart phone applications because it’s not backwards compliant.

Is the anchor element now block level?

If that has not changed then its just a supported hack more or less.

Personally I do not like it, and will not be using it – just as easy to make a JS framework function – like a jQuery plugin and control it via classes.

As in every element with the class “is-link” looks for a anchor href inside and applies this to a click event on self.

Well, I’m so used to make my “HTML Validator” show a green symbol … X-)
On the other hand I don’t care using CSS hacks and js workarounds in my code, so why shouldn’t I wrap blocklevel elements in an inline anchor-tag?

You can use span-tags inside an a-tag and make them block level elements with CSS, instead of using divs or other “not so important” semantic block elements, but I wouldn’t like to replace a headline-tag with that method.

But how about the semantic meaning of an a-tag, it’s not only the validation it self that would give me a bad feeling about that. Think about search engines, screen reader and stuff like that. Using an “A” for a bigger text space just for the link function is not the real sense of HyperText … well thats what I think.