“Block-level” links in HTML5

by .

One new and exciting thing you can do in HTML 5 is wrap links round “block-level” elements.

Imagine you have a front page with lots of teasers for news articles, each of which leads to a page devoted to the full text of that article. Obviously, each story needs a heading and you’ll want an image too, and you’ll want them all clickable. In current mark-up you’ll probably have something like this:

<div class="story">
<h3><a href="story1.html">Bruce Lawson voted sexiest man on Earth</a></h3>
<p><a href="story1.html"><img src="bruce.jpg" alt="full story. " />A congress representing all the planet's women unanimously voted Bruce Lawson as sexiest man alive.</a></p>
<p><a href="story1.html">Read more</a></p>
</div>

Note that you have three identical links (or two if, like the BBC News site, you assume your readers don’t need a “read more” link).

In HTML 5, you code it like this:

<article>
<a href="story1.html">
<h3>Bruce Lawson voted sexiest man on Earth</h3>
<p><img src="bruce.jpg" alt="gorgeous lovebundle. ">A congress representing all the planet's women unanimously voted Bruce Lawson as sexiest man alive.</p>
<p>Read more</p>
</a>
</article>

Now the single link surrounds the whole teaser, removing duplication and creating a much wider hit area to click.

Two points to make about accessibility in passing: firstly, you don’t need to worry that each "read more" goes to a different destination (see WCAG 2) because the whole story is the link, so the link text is unique. Secondly, note that I’ve changed the alternate text on the image, as in the first instance the image is a link so I described its destination, whereas the second is just a picture so I describe the image itself—”gorgeous lovebundle”—and thereby give more information to a screenreader user.

Shiny, but not new

What’s also very interesting about this technique is that actually this isn’t new: you can do it now. XHTML 2 had a similar mechanism, which allowed href on any element Eric Meyer called for this to be adopted in HTML 5 but, of course, this isn’t backwardly compatible. One of his other solutions to the same problem was changing the rules for a, and my test page shows that it works now in all the browsers.

That’s one of the interesting things about HTML 5—it documents existing browser behaviour. As the browsers already handle wrapping links around block-level elements, and there is an obvious use-case, there was no reason to artificially keep the structure as invalid.

(One irony: Eric Meyer’s original use-case was to link all cells in a table row. This doesn’t work in HTML 5; you need script for that.)

95 Responses on the article ““Block-level” links in HTML5”

  • I’m glad that wrapping an anchor around blocks is acceptable now, I tried barking up that tree on the mailing list once or twice but heard nothing. One thing that I would like to see is the ability to have an href on the BUTTON or INPUT tags. It just makes sense for some forms I’ve had to make in the past where an action only needs to be a link.

  • Alejandro Moreno says:

    Thanks for that!

    And note that the H3 on the first code box has an extra closing Anchor tag at the end.

  • Bruce Lawson says:

    Curses; three of us have proofed the small article, and a code gremlin sneaks through.

    Removed the offending extra tag; thanks Alejandro!

  • Neil says:

    I thought HTML 5 was going to allow for an “href” element on any tag. Has this been dropped from the spec, or was it never on the table?

  • Bruce Lawson says:

    It was never on the table, Neil. (See the article)

  • Chris Griego says:

    I’ve run into an issue where Firefox will intermittently parse an anchor wrapped around a heading and a paragraph as opening and closing many anchors as if trying to recover from using older rules. Is this a known issue and is there a workaround?

  • Bruce Lawson says:

    I’ve heard of the issue, Chris. Do you have a test URL? Which version of Firefox? Have you filed a bug?

  • Chris Griego says:

    I’ve seen the issue with the three colored boxes near the bottom of this page. http://www.getaroom.com/ I’ve experienced it once using Firefox 3.5 on Mac with only the left colored box and another person reported the issue using Firefox 3.0 on Windows with the far right box. I have not filed a bug yet since I have not yet found a reliable test case.

  • Cd-MaN says:

    For many cases you can use an inline element (like span) and style it as a block element.

  • Rick says:

    Regarding accessibility, wouldn’t this make the link “text” rather long. Granted, it would be unique so the “Read more” need not be unique … because it is part of a very long, unique link descriptor.

    How will the accessible browsers deal with an image embedded in the link that is not itself a link but does have an alt attribute? Actually, how will they address elements embedded in the link (, , , ). I assume they accessible browsers are working toward dealing with this?

  • horuskol says:

    two words that always make me shudder in standards discussions – ‘backwards compatibility’ – either you’re coding in HTML4 or in HTML5, so what’s the problem in discarding elements or changing behaviour in HTML5?

    Of course – it all comes down to what the point of the standard is – is it to make the development of semantically formed and descriptive documents and improve the user experience of the internet? Or is it to make browser manufacturers’ lives easier?

    I always agreed with Eric Meyer’s idea that href should be a universal attribute – it makes for tidier code by removing the need to wrap a block in yet another element – but browsers don’t currently support that, and don’t want to have to support that, so it doesn’t get considered for reasons of ‘backwards compatibility’.

  • Ben Ward says:

    horuskol: The pragmatic philosophy behind HTML5 is that you’re not coding HTML4 or HTML5, you’re coding HTML.

    There are no ‘versions’, perhaps think of the ‘5’ as the ‘edition’ or ‘revision’ rather than ‘version’ (a `version` attribute was rejected very early in the HTML5 process and was probably the cause of the first huge W3C+HTML5 discussion).

    The very principal of the web is that content rules, and the accessibility of that content rules. Browsers will be able to implement the HTML5 spec to support all previous HTML content, and one day they’ll implement the HTML6 specification to support all previous HTML content. The web is a content platform, and so it evolves in the direction of content. As in this case, that sometimes dictates less optimised code for authors.

    To spec `href` on all elements is _so_ backwards incompatible that it would be like publishing pages without any links at all. That’s the price of evolution, but I think it’s a fair one.

  • horuskol says:

    @Ben Ward – I understand what you’re saying about the ‘non-version’ aspect of the specification, but I still have a problem with the idea of ‘backwards compatibility’

    HTML5 is already introducing a huge increase in markup that browsers do not understand – so backwards compatibility is already broken to some degree (yes, rendering as a block level div is not a problem – but what about , for example).

    Also – if you insist, you could allow or href anywhere.

    And surely href anywhere wouldn’t be hard to accomplish in a modern browser?

    Just as a side note – on the idea of backwards compatibility – when is HTML5 going to bring back – that’s HTML, too…

  • horuskol says:

    dang – didn’t expect the comments editor to parse my HTML – <a href=””>

  • mynthon says:

    horuskol is right. If we can introduce new elements like article, section, footer, header (well ie doesnt support them, so it is not bacwart copatible) why we cannot allow href on any element? a tag can be allowed around block elements but href on every element can be possible too.

    Every article, every note im more sceptic about html5. Introducing few new (very confusing imo) element is not much step forward. Video element will not have default codec. footer and header are really confusing. Article sound like it is only for blogs – what about ecommerce? Font tag isnt allowed but browser have to support it – well, what stops people from using it if broser still support it? Shorter doctype, canvas, allow to multiple H1 is only benefit of html5. Im starting to think that this entire html5 was intended for browser vendors (well, browser vendors play main role in creating this “standard”).

  • Ben Ward says:

    Mynthon: The difference is one of impact. New elements can be phased in, or used in combination with existing supported elements. The absence of support in the browser of a new element does not render content invisible, or broken. However, a piece of functionality like an @href, that breaks. It is invisible to users, there have no way of knowing anything is there at all, and the browser will do nothing, nor expose anything.

    That change to @href would be a change, with no graceful degradation.

    `canvas`, `video` and `audio` can all degrade gracefully to their specified fallback content in existing browsers, too. The new DOM methods can be supported with conditional progressive enhancement just like the previous generation of scripting enhancements.

    Support for `font` — perhaps a good case for a ‘Why is `font` in HTML5?’ article — is there for browsers alone. It’s deprecated for authors and authoring validation tools will report report as such. But, if you were to start writing a browser today, to render content on the web, you have to parse `font` tags or else you cannot render the web. Remember that this specification is for rendering, not just authoring.

    Documentation that comes with HTML5 that’s focused on authors will make no mention of `font` tags, except to document their deprecation.

  • Régis Kuckaertz says:

    I suppose I’m a little late on this, but how can wrapping an A element around block-level elements be backward compatible with a specification that describes A as an inline element?

  • Bruce Lawson says:

    Régis – you’re not late; I only posted this yesterday!

    I should have been clearer; the HTML 5 spec isn’t backwardly compatible with the HTML 4 spec. Rather, the “block level links” markup is backwardly compatible with current browsers– it works now, with no need to change them. “href everywhere” needs every browser to be recoded and everyone in the world to use one, otherwise they get no links.

    As Ben Ward says [and his comments and contributions are so good he’s an honourary Doctor], if you come to an html5 page with an “old” browser – the one you’re using today – content in a footer, header, article will still render. You can see that now, as this site uses those elements. So they;re “backwardly compatible”. But if we used “href anywhere”, all links coded that way would not render at all, making the content useless.

  • horuskol says:

    These are all good rationalisations – and I hope I don’t come across as being difficult for the sake of it – but shouldn’t HTML5 be a specification on how we want HTML to work in years to come as opposed to simply a formalisation of how browsers currently work?

    Couldn’t the w3c set a date for adoption and, with developers who actually have to work with the specification everyday, lobby the browser vendors to work towards it? Or am I being too much of an idealist here?

    I certainly don’t see how browsers (and developer/user experience by association) will approve if it’s all just “business as normal”. What happened to the effort that produced the HTML4/CSS2 standard (which was incredibly broken by browsers at the time).

  • Régis Kuckaertz says:

    @Bruce thanks a lot for making this clearer, you cow-boy of the Wild Wild Web ;)

  • Bruce Lawson says:

    Horuskol: “shouldn’t HTML5 be a specification on how we want HTML to work in years to come”. yes, indeed. And part of getting there is defining how HTML and browsers work now.

    Also, we want HTML 5 to work in current browsers (as far as possible). Not everyone can upgrade their browsers, either because they don’t have admin access to a machine, or because their machines are old and comparatively low-spec. (For example, no-one on an older Windows machine can upgrade past IE 6).

  • zcorpan says:

    “Secondly, note that I’ve changed the alternate text on the image, as in the first instance the image is a link so I described its destination, whereas the second is just a picture so I describe the image itself—”gorgeous lovebundle”—and thereby give more information to a screenreader user.”

    alt text isn’t intended to describe the image. It is intended to be a replacement of the image. When replacing the image with the alt text, the paragraph would read:

    “gorgeous lovebundleA congress representing all the planet’s women unanimously voted Bruce Lawson as sexiest man alive.”

    In this case I would guess that the image is just illustrating the article and as such seems to most closely match http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-0.html#a-purely-decorative-image-that-doesn't-add-any-information which says you must use alt=””.

  • HrvojeKC says:

    unfortunately this does not work in Safari 4 and Webkit nightlyes on Mac OS X

  • HrvojeKC says:

    It renders all elements as linked but does not provide the “button” effect as the whole element area is not recognised as a link

  • Bruce Lawson says:

    @zcorpan A screen reader would say “image: gorgeous lovebundle” which may add information (eg that there’s an image of me there). Blind people I know have different preferences with these kind of images. One blind guy I know says that there’s no need for alt text there as the image doesn’t add information. A blind woman I know (who, like the guy was not blind from birth) likes to have the images described. Therefore, I err on the side of describing, but not *over”-describing (so not “gorgeous lovebundle, imagine George Clooney or Cary Grant with a hint of Sean Connery’s danger” although that would be entirely accurate).

    @HrvojeKC – then I’m pretty sure that’s a regression as I tested the page in Safari when I wrote it.

  • zcorpan says:

    Still, presumably you’d want a full stop and a space so that it doesn’t run together with the next sentence in e.g. Lynx?

  • Bruce Lawson says:

    @zcorpan Yes, perhaps. To be honest, though, I get tired of authors having to muck around coping with the deficiencies of crappy user agents. If Lynx/ JAWS can’t understand that the alt attribute should be separated from other text, either by brackets (in Lynx) or with a terminating pause (JAWS) they are doling their customers a disservice.

    But it’s pretty churlish of me not to add a full stop and a space, so I’d advise doing so, yes. And I’ve changed the article above – thanks.

  • […] important thing to note is that links in SVG can be wrapped around anything, a little like block level linking in HTML5. This is a great feature as it allows for a larger clickable area for those that need it and you […]

  • oli says:

    One thing I noticed is CSS might not affect the link as you expect. If you apply ‘block’ styles (background, border etc) things either don’t get applied, or get weird (ie empty border boxes before and after, background-color only working on a linked <p> if there’s another inline link inside the <p>). ‘Inline’ styles like font-style, font-weight, and color are inherited fine. I needed to style the link contents to fake a background color, eg:

    section a h1 {background-color: #F9FDA2;} /* section a {} didn’t work */

  • bruce says:

    Thanks Oli

    yeah, there are a few styling wierdnesses going around. (Which browser were you using?)

  • Mike T. says:

    I ran into an interesting problem with this today–which I believe is a Firefox 3.5 bug (reported already…). Wrapping a in an anchor works just as expected, but trying to wrap a list-item in an anchor fails to make the entire a link.

    Here’s a test page: http://miketaylr.com/test/block_anchors.html

    The good news is that if you enable the html5 parser in the latest build of Minefield, it works like every other browser currently does.

  • Blarala says:

    @Mike T.

    The only element allowed as a child of an UL is a LI. You have to wrap the A around the contents of the LI, not the LI itself.

    You have to respect the elements content models.

    http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-ul-element
    http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-li-element

    @Bruce Lawson

    To quote the spec: “It is important to realize that the alternative text is a replacement for the image, not a description of the image.” Only if the author of a document does not conform to this, there is a need for brackets. Sometimes the textual alternative for an image is the empty string.

    http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-0.html#alt

  • Mike T. says:

    @Blarala

    Bingo! Thanks for the links and explanation.

  • Although I like the new method of programming in HTML5, I really don’t understand this example. Or atleast, the example given is wrong…

    This is because I never, and I repeat never, want the content itself be a link. While in your example the content (second paragraph) is a link too. Besides that, assuming it’s a blog article, there will only be 2 links to the main article; the heading and the read more link. The images for example should not have an URL, unless it goes to an expanded version of the same image.

    The only way I would use a block-level link is with thumbnails or menu buttons where everything should be clickable, eg:


    Item with link

    a small description

  • […] Link: “Block-level” links in HTML 5 | HTML5 Doctor […]

  • […] lets users wrap block-level elements with <a> tags to create block linking areas. Basically, we’ll be able to wrap the entire <hentry> contents with an anchor and have […]

  • […] lets users wrap block-level elements with <a> tags to create block linking areas. Basically, we’ll be able to wrap the entire <hentry> contents with an anchor and have […]

  • […] lets users wrap block-level elements with <a> tags to create block linking areas. Basically, we’ll be able to wrap the entire <hentry> contents with an anchor and […]

  • […] lets users wrap block-level elements with <a> tags to create block linking areas. Basically, we’ll be able to wrap the entire <hentry> contents with an anchor and have it […]

  • […] lets users wrap block-level elements with <a> tags to create block linking areas. Basically, we’ll be able to wrap the entire <hentry> contents with an anchor and have […]

  • sam says:

    Surely the point about the ALT attribute in the first (non A tag wrapped) is that you should not have:
    alt=”full story. “

    You should have a TITLE attribute on the A that is wrapped around the IMG, and the TITLE should describe where the link will take the user.

  • […] lets users wrap block-level elements with <a> tags to create block linking areas. Basically, we’ll be able to wrap the entire <hentry> contents with an anchor and have […]

  • […] lets users wrap block-level elements with <a> tags to create block linking areas. Basically, we’ll be able to wrap the entire <hentry> contents with an anchor and have […]

  • […] lets users wrap block-level elements with <a> tags to create block linking areas. Basically, we’ll be able to wrap the entire <hentry> contents with an anchor and have […]

  • […] Es gibt neue, befreiende Verschachtelungsregeln. […]

  • Oli says:

    Hi All,

    I’ve encountered some block-level link weirdness in Firefox 3.5.2. When the block-level link contains an HTML5 element, the DOM gets fubar. Here’s the test case:
    Firefox closes block-level links when encountering HTML5 elements
    And it’s bug #514122 on Bugzilla.

    @bruce sorry for not replying—I forgot to subscribe. This was in Safari and Firefox off memory, but in filing this bug report I found that setting {background:inherit;} for contained elements did the trick.

    peace – oli

  • bruce says:

    Excellent Oli, thanks!

  • Oli says:

    Doh, for some reason I completely didn’t make the connection to Remy’s Vomit Bug—this looks like a variant. Chunder galore! :|

  • SelenIT says:

    IE (including IE8) has a minor, but annoying problem with anything inside the links, which is displayed as blocks (even originally inline elements like span set to display:block via CSS). When right-clicking these elements, not the link context menu, but the default page context menu is displayed, so the user is unable to open the link in the new tab/window etc. Of course, user still can use middle-click or shift/ctrl + left click… but the expected link behavior becomes significantly broken, IMHO.

  • Bruce Lawson says:

    Gracious me – a bug in IE?

    Fortunately, it doesn’t break the rendering of the page, but significantly breaks the UI.

  • […] It looks like amongst a lot of other cool stuff HTML5 will bring us also block-level links. […]

  • […] Posted by iandevlin Erm where did you see that? I keep up on HTML5. “Block-level” links in HTML5 | HTML5 Doctor __________________ Professional, accessible, and search engine friendly web site development by […]

  • […] Posted by iandevlin Erm where did you see that? “Block-level” links in HTML5 | HTML5 Doctor __________________ Professional, accessible, and search engine friendly web site development by […]

  • […] позволяет пользователям заключать в тэг <a> целые блоки информации. Так что мы можем заставить весь элемент <hentry> вести […]

  • Adal Design says:

    Pfiou!
    Half of me is SO happy that development is so spread out and that it seems almost anyone who cares enough can have a word to say about how things work.
    The other half of me wishes so strongly that Browser companies and the W3C could get along better and truly communicate efficiently so that I wouldn’t have to code for 10 different realities.
    The third half of me, because I’m obviously over-complete, wishes we could just force-install the most popular, light and standard-compliant browser on every single computer in the world and all to use it.

    Is there no way to make browser companies more responsible for what they do??? How about an IE that’s LITE and works on old machines AND is easy to install over an old version?

  • Kenny Graham says:

    Seems I’m a bit late, but still:

    @Bruce: I don’t consider it a flaw for user agents to not wrap/separate image alt text. Images, when inline, should be treated as inline. A good example is an image as a dropcap. The UA shouldn’t render it as “[W] ord”, it should render it as “Word”. For this reason, I’m also opposed to screen readers specifying “Image” beforehand, though I suppose it makes pragmatic sense.

  • […] wrap an <a href="…"> around the other tags. It’s called block-level linking, and we’ve written an article about […]

  • […] lets users wrap block-level elements with <a> tags to create block linking areas. Basically, we’ll be able to wrap the entire <hentry> contents with an anchor and have it […]

  • […] lets users wrap block-level elements with <a> tags to create block linking areas. Basically, we’ll be able to wrap the entire <hentry> contents with an anchor and have it […]

  • […] the HTML 5 creators took advantage of an against-spec ability that current browsers already had: block level anchors. Browsers at least back to IE 6 will happily make “flow content” placed in an […]

  • […] something which will actually produce an error to the end user. For example, block level linking http://html5doctor.com/block-level-links-in-html-5/ or having a start attribute on an ordered list […]

  • […] liking the semantic implications of using a div as a link. Just seems wrong. Especially now that HTML5 supports block level links __________________ Rippy: Today, I did something stupid and moaned about it on a website because […]

  • […] lets users wrap block-level elements with <a> tags to create block linking areas33. Basically, we’ll be able to wrap the entire <hentry> contents with an anchor and have it […]

  • Kevin says:

    When I was trying to wrap with an anchor tag, it won’t work in Firefox 3.6

  • Bruce Lawson says:

    Care to link to a minimal test case, Kevin? And does Matt Wilcox’s page help you out http://mattwilcox.net/sandbox/html5-block-anchor/test.html ?

  • […] lets users wrap block-level elements with <a> tags to create block linking areas. Basically, we’ll be able to wrap the entire <hentry> contents with an anchor and have it […]

  • […] I used an HTML5 doctype, I experimented with the now legal application of the <a> tag around a block element. In this case, I have code that looks like […]

  • […] can get around it regulating block-level links like so (but bear in mind some browsers have difficulty with block-level […]

  • […] lets users wrap block-level elements with <a> tags to create block linking areas. Basically, we’ll be able to wrap the entire <hentry> contents with an anchor and have it […]

  • […] lets users wrap block-level elements with <a> tags to create block linking areas. Basically, we’ll be able to wrap the entire <hentry> contents with an anchor and have it […]

  • […] is conforming in HTML5 for links to include block level elements such as headings and paragraphs, this was forbidden in […]

  • Thnaks so much, Bruce! Nice piece:)

  • It does work nicely because I use it as a method to wrap the figure tag that may be encompassing a thumbnail. My only gripe is it does require some extra code for IE7 to get the entire link hoverable however where the image is, the link is still unclickable. Doesn’t seem to make any sense but if you goto the portfolio section of my site in IE7, then you’ll understand.

  • […] or in simpler terms – make more sense to how designers think. For example, <a> tags can be wrapped around an entire block of code to avoid repeatedly linking titles, words or “read more” […]

  • Mary Wilkins says:

    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 :)
    http://9pillsonline.com/

  • Anonymous says:

    Why don’t we have hrefable table rows yet?
    Wrapping block level elements with anchors is nice but why don’t they implement the proper alternative for people who know for sure that 100.00% of the users on the site are going to use modern, up to date browsers?
    Even for public facing sites accessibility could be done with regressive enhancement.

  • […] (10)“Block-level” links in HTML5 […]

  • Gus says:

    How about just using to make the link to cover the whole teaser (wrapper). This way we keep it semantic.

    Check it out http://cdpn.io/nvedt

    I agree with Eric Meyer to allow any element to have a href.

    I think for now the solution I’ve presented is good.

    Let me know what you think!

    Thanks

  • Jakob E says:

    @Gus I do the same – hence I like :)

  • PhilK says:

    Oops, I didn’t pay attention to the HTML allowed, let’s try again:

    In all probablility it’s just that I haven’t found the correct way to do this yet, but how does one center a block element using HTML5?

    In older HTML we could center a block element using align=”center” within a table <td> tag but this is no longer in HTML5 so what’s a coder to do?

    I’d also like to see this in CSS, how about a corresponding “block-align:center” method?

    Case in point, I want a block element to be centered within another element, say a <td> of a table. I can now use

    <colgroup>
    <col style="width:40%; text-align:center;">
    </colgroup>

    and the text in the corresponding <td> aligns correctly, BUT if I put a block element within that TD it is NOT centered.

    So, why isn’t there a corresponding block-align element?

    <colgroup>
    <col style="width:40%; block-align:center;">
    </colgroup>

    or at least some way in HTML5 to align a block on the page without using deprecated, no longer allowed methods such as <td align=”center”> ?

    What am I missing, haven’t found yet?

    Thanks!
    PhilK

  • PhilK says:

    Thanks Dr. Bruce that’s what I’ve been using but to center a table one needs to put that in a div, or to center a block such as a user control one needs to put that in a div with the width being the same (or very close to it) as the user control “inside” the div. It is such a pain! Why can’t they add block-align similar to text-align? Oh-well, not your problem.

    Thanks again.

  • I’m glad this is not considered “verboten” anymore, because it really comes in handy, especially for avoiding the repetitious “read more” links on excerpts.

    I have, however, come across an issue that makes me think twice before wrapping a bunch of things in an a tag: it can make text inside of those elements difficult or impossible to select.

    When you go to click and drag, it activates the link instead of selecting the text within. If you start your drag outside of the anchor tag it tends to work OK, but if you have a grid of anchor tags with text elements inside and little or no margin between them, it can be next to impossible to select the text.

    Here’s an example (try to select the text in the blocks).

  • Praky says:

    Is there any workaround for the issue that @Gabriel has pointed out? I’m facing a similar issue.

  • Aik Boba says:

    Guys, I don’t see trouble to use block-level links in html of earlier versions (4 and low). Reed W3 specification: http://www.w3.org/TR/html4/struct/links.html – there are restricted tag in only :) So… I don’t know what this article for.

  • SelenIT says:

    Aik Boba, the HTML4 and earlier clearly defined the content model of <a> element as ‘inline’:

    <!ELEMENT A – – (%inline;)* -(A) — anchor –>

    So all elements not listed in ‘inline’ definition weren’t allowed inside it.

  • CJ says:

    6 years later and some rich text editors (eg; CKEditor) still won’t allow this markup.

    Instead, they will unhelpfully place the anchor ‘inside’ each block element.

    *sigh*

  • Savannah says:

    This is pretty useful but do you use the block-level in just links or is it used in other things?

  • Join the discussion.

    Some HTML is ok

    You can use these tags:
    <a href="" title="">
    <abbr title="">
    <b>
    <blockquote cite="">
    <cite>
    <del datetime="">
    <em>
    <i>
    <q cite="">
    <strong>

    You can also use <code>, and remember to use &lt; and &gt; for brackets.