HTML5: Wrap Block-Level Elements with A’s
HTML5 presents a simpler line of thought with HTML than XHTML. And quite honestly, it's a much needed simplification. One of those simplifications is the ability to wrap block-level elements like DIVs, H-tags, and P's with basic A elements. You read that correctly: wrap block-level elements with A tags.
HTML5 Code
<body> <a href="/about-page.php"> <div class="article"> <h1>About David Walsh</h1> <p> I'm a 27 year old Web Developer and jQuery & MooTools Consultant working from Madison, Wisconsin. I am Founder and Lead Developer for Wynq Web Labs. I don't design the websites, I just make them work. </p> </div> </a> </body>
There you have it. A simple A element wrapping DIVs, H1's, and P's. Note that you may not wrap A elements with larger A elements.
What Do You Think?
I have mixed feelings about wrapping block-level elements with A tags. Taking a quick look at the HTML makes me feel as though the code is dirty or wrong. On the flip side, we've been using JavaScript to skirt around doing this for a long time. My Clickables class aims to accomplish this task. Using HTML to make something clickable is more natural and doesn't require JavaScript. I guess my question is: how do you feel about this practice? Will you use it right away? Please share!
Comments
Be Heard!
Share your thoughts without being a jerk! And wrap your code in <code> tags, f00!
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: pointerand 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: inlineCSS 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.
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.
@Tim Wright: I wouldn’t mind that either.
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 disagree, I think this way makes it more clear than the hacks of old. People become used to clicking any part of a “block” of content to see that content in more detail, and previously your only option was to put the content of each block element inside its own anchor (meaning multiple links to the same content; messy) or to use JavaScript which doesn’t show the URL in the status bar, doesn’t apply default “click” styles (which can be forgotten) and isn’t available to everyone. This method is far less open to abuse, and as people are saying it is only taboo because it has been taboo.
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.
Yes it feels very dirty.
I was at first very reluctant to even style an element in this way.
However keeping up with the HTML5 trends, I decided yes I would give it a go. Everything was looking great at first.
But then… Random out of the blue the nicely designed element suddenly decided to act very strange Looking further into the issue i noted that Firefox was adding a whole bunch of dodgy code which was messing things up big time for me.
So I had to revert back to the old drawing board. Those without js would get the functionality, but those with js would get the look and feel to accompany it.
The firefox issue is as below:
http://oli-studio.com/bugs/mozilla/block-level-links.html
If Firefox wouldn’t have thrown chunkies in the past I’d incorporated that one even before HTML5. This a-tag around block elements cleans up lots of code, makes it more structured and reuseable and additionally adds a lot of usability when done right. I.e. you can click a whole article teaser with photo, headline, intro text to get to the article instead of clicking on some tiny words showing “Read more…”
Normally I solved that by shoving a lot of official inliners in there and styling them as block, like say give a span a div behaviour. which was ridiculous. (but using Javascript would have been worse).
I can understand that it was a heritage flaw… since the a-tag started out as text and inline, the guys at wc3 wanted to keep the declarations clean and sensible, but it’s much better this was.
I don’t think elements should actually be inline/block elements in the first place. HTML is markup not style. Every element should be display agnostic.
I have no problem with the above approach and think it brings clarity betweeen structure (HTML) and style (CSS).
I will definitely use this.
I don’t see how href on every element is a good idea, it breaks down the definition of the element, as now a definition list is also a link???. Just so you can keep block/inline elements?!
As long as it is accessible and it isn’t used as a “trick”, I guess it should be allowed.
I’m very happy that it is allowed now. I often run into the problem where I have a navigation where each “link” consists of a heading, an image and a paragraph.
I’m all about it! As most, I’ve been writing javascript for clickable divs. The concern that brought me here, is that I wanted the links to be available to search engines as well as people. I’m so glad HTML 5 allows wrapping most elements in an ‘a’.
Good discussion, btw!
Mixed feelings about what??? 10 years ago or not that long ago people had mixed feelings about DIVs agains TR and TD and xHtml against HTML,;now it’s ridiculous to even mention old approaches…
One link can be clickable, One Div can be clickable, One column (should be clickable)… see no problem :)))