Treehouse

HTML5: Wrap Block-Level Elements with A’s

By on  

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!

ydkjs-6.png

Recent Features

  • Creating Scrolling Parallax Effects with&nbsp;CSS

    I generally dislike ESPN because they're the McDonalds of sports news but they recently did a piece on Luis Suarez that was eye-catching.  The content itself was great but their use of parallax and imagery was outstanding.  They've employed this technique...

  • 5 Awesome New Mozilla Technologies You&#8217;ve Never Heard&nbsp;Of

    My trip to Mozilla Summit 2013 was incredible.  I've spent so much time focusing on my project that I had lost sight of all of the great work Mozillians were putting out.  MozSummit provided the perfect reminder of how brilliant...

  • Send Text Messages with&nbsp;PHP

    Kids these days, I tell ya.  All they care about is the technology.  The video games.  The bottled water.  Oh, and the texting, always the texting.  Back in my day, all we had was...OK, I had all of these things...

Incredible Demos

  • JavaScript Copy to&nbsp;Clipboard

    Providing your users the ability to copy text to the clipboard can make your website much more convenient and valuable. Unfortunately Flash 10 broke most of the methods for doing so. Luckily a great library named ZeroClipboard...

  • MooTools Wall&nbsp;Plugin

    One of the more impressive MooTools plugins to hit the Forge recently was The Wall by Marco Dell'Anna.  The Wall creates an endless grid of elements which can be grabbed and dragged, fading in elements as...

  • Create Your Own Dijit CSS Theme with LESS&nbsp;CSS

    The Dojo Toolkit seems to just get better and better.  One of the new additions in Dojo 1.6 was the use of LESS CSS to create Dijit themes.  The move to using LESS is a brilliant one because it...

Discussion

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

    • mack

      I feel great about this. Perfect example of the spec changing to suit new designs and usability trends.

  2. 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 :)

  3. 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.

  4. 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…

  5. Phil

    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.

  6. Gappa

    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…

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

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

  9. 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.

  10. @Tim Wright: I wouldn’t mind that either.

  11. 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.

  12. 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 :-)

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

  14. EmEhRKay

    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 :)

  15. 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. :)

  16. @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!

  17. Gappa

    @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?

  18. kolin

    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!

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

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

  21. Will not use it any soon…

  22. 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.

  23. 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.

  24. 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.

  25. 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.

  26. Miles

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

  27. thinsoldier

    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.

  28. finrod

    really nice thing didn’t knew its possible

  29. 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.”

  30. 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.

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

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

  33. Igor Szyporyn

    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.

  34. 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.

  35. Trevor Saint

    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

    • Arie Putranto

      Blame it on Firefox. Designers design based on standards, not on browser

  36. 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.

  37. John Milmine

    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?!

  38. 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.

  39. 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!

  40. Luka

    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 :)))

  41. I love it! There’s absolutely no reason why this should not be legal. It’s a much needed improvement which will simplify code wherever multiple elements need the same link.

  42. I am so glad it’s validate now.
    There is no reason to use JS as “hack” for simple things.
    Semantic is ok with me For this kind of use .

  43. This is excellent! Are you people crazy? Do you also think that world is flat?

    From my perspective, this makes perfect sense in HTML. Everything in the A tag is relevant to the content it takes you to. It’s easy for me (1 year in to coding) to understand this. I have no problem with it (maybe for ten seconds I did, and then I got over it and moved on to the good parts – so easy!).

    I agree with some commenters – just have to make sure that a user knows what it means when the arrow changes to a hand and (maybe suddenly) they could go somewhere with a click.

  44. Jade Lester

    Feels dirty at first because its undoing years of knowing not to do this! But it makes sense, and its cleaner in a sense of not having to use JS to do such a simple task. I’m going to use it now on a project I’m just doing!….

  45. Already using it on this website. Have some others in the pipe which follow suit. Its a much needed simplification. Native handling is cleaner and much faster.

  46. You do not need to use JavaScript for this, people!
    See my example:
    HTML:

    	
    

    CSS:

    #example {height: 100px; width: 100px}
    #example a {display: block; height: 100px; width: 100px}
    

    Note the display: block on the a tag.
    That’s it! Pure and simple.

  47. That last comment didn’t quite work. I wanted the p tag to be a div instead, with an id of “example.”

  48. Fra

    Wrap block-level elements with A tags!! Ohh, wow!!

    Been there, done that, welcome to the club.

    Been using that for around 20 years and always worked, on any browser since Netscape 1. Oh, it did not validate, OMG, how could I live with that? It was the right way, and a perfectly logical way, and it worked everywhere. So I just explained it to my clients, and most didn’t really care.

    The funny thing is you still feel uncomfortable with it, even if it is now allowed, just because they have been telling you nono so many times in the past. So funny. If they invented a new tag called CLICKABLE, instead of A, you would feel much better. Haha. And you used javascript for it.. Hohoho.

  49. I think this is a very useful and needed addition. Restricting a tags to only wrap inline elements makes sense from the point of clarity. A blue text that I click on leads me to another page. Very simple, very easy to understand. Now when you apply the tag to a block and someone accidentally clicks on it, is is much harder to figure out why this action occurred and what is clickable and what not. I think it is good to give developers and designers the freedom to do this now, leaving the burden on the design to make clear where to click and when sth is clickable. I.e. table rows that change their bg-color on hover are a perfect example of UI and clickability being in sync and it’s clearly useful and understandable why an a tag is around the element. On the other hand putting an a-tag around your contact information with no hover-effects is very confusing. What an I clicking on? Your name? Do I send you an email? Or do you redirect me to somewhere else with a contact form? I would consider your example bad, because it is not immediately clear that I can click it – and should click it (the probably more problematic aspect for you).

    Overall I like giving the designers and developers a lot of freedom, as long as they know what basic principles should still stay intact.

    [fixed previous comment - feel free to delete it. Accidentally opened an a-tag and it was parsed instead of escaped. My bad]

  50. SarahC

    Well, it doesn’t work with tables still. =(

    <html>
    <body>
    <table>

    <a href=”TEST”><tr><td>
    Testing!
    </td></tr></a>

    </table>

    </body>
    </html>

  51. Yes, thanks so much – it was really overtime!
    And since HTML5 has been around for a couple of years now, there should be no problems with browser support…

Wrap your code in <pre class="{language}"></pre> tags, link to a GitHub gist, JSFiddle fiddle, or CodePen pen to embed!

Use Code Editor