I didn’t know that. http://html5doctor.com/block-level-links-in-html-5/.
I think I’ll make the switch.
I find this to be an extremely difficult concept to understand since XHTML tells us not to do this, I have been working with jQuery Mobile which uses the technique but I just can’t get used to it.
Sent from my iPhone using Tapatalk
See the following:
[quote=“Stephen Chapman,post:35,topic:24264”]
That’s the second best demonstration of HTML 5 stupidity that I have come across so far. The best being the “mandatory empty” input field definition at the bottom of my sig.[/QUOTE]
Obviously I was purposely demonstrating at least two nonsense ideas there, that would be perfectly valid. No doubt you’ll get some idiots wrapping TABLE in anchor.
It’s known as the principle of “paving the cowpats”. 
This is a very good idea. But does it work? I remember seeing if it was possible a couple of years ago and it always broke things in firefox.
@chris.upjohn that’s interesting. Why does XHTML tell us not to do this? I can’t see the reasoning for it.
This is a very good idea. But does it work? I remember seeing if it was possible a couple of years ago and it always broke things in firefox.
Works very well on mobile but older browsers such as IE have a hell of a time trying to render things right if you don’t make the anchor display: block
@TomB; Block level elements in XHTML are strictly for layouts E.g. containers for headers, content wrappers and such, using a block level element within an inline element is wrong because you are changing the design of what an inline element is supposed to be used for hence you have already written bad markup for doing so. HTML5 gets around this by adding one extra section to the specification that says we can do this but it still goes against the reasoning why an anchor element is inline in the first place, personally I feel that an anchor tag should be used for nothing else but text and span elements for icon purposes since they are both inline but anything like a <div>, <canvas> etc… should be made clickable another way.
That reasoning is fine, but only because of the way we’ve already defined block and inline. From a practical perspective, linking a block or group of elements makes perfect sense. Semantically, there’s nothing wrong with wrapping a element in an anchor.
In fact, I’d argue that it’s a poor separation of concerns that inline/block should be a consideration when marking up a document because it’s display only.
Except that I’m seeing people wrap all sorts of blocks in anchors including blocks of code that already contain other anchors!!
It just opens up all sorts of problems not to mention rendering problems in certain well known browsers and is best left alone. I agree it would be handy in some cases to link a block of heading and text content but than can often be confusing for users (and I should think confuse screen readers) if not done correctly. In most other cases though it is unnecessary to do that.
Not that <a> is the reason I’m switching. I just think its time. Ill start with the doctype and meta character set for now. And work the semantic tags in over time as I get to know their correct usuage.
But that’s viable at the moment. Inline elements can contain other inline elements. There’s nothing to stop someone putting an anchor in an anchor at the moment! I don’t really think that’s enough of a reason on it’s own. The DTD should specify what elements are allowed in others and the validator would be able to pick up nested anchors wheer they’re inline or block.
An A element cannot contain another A element in HTML 4.01 and that actually is a normative markup language.
Like I mentioned above you no doubt you’ll get some idiots wrapping complex tables with an anchor. Imagine the craziness of a whole structural data table defining a hypertext link, etc.
X(HT)ML ‘block’ and ‘inline’ elements have little to do with display if anything (markup wise) they are structural. Block-level elements typically contain inline elements and other block-level elements. Inherent in this structural distinction is the idea that block elements create “larger” structures than inline elements.
People too often get overly confused with the CSS ‘display’ property, which is a Style Sheet Language and that would actually cover Separation of Concerns, as its ‘display’ not ‘structural’ content.
Well people could of always done it they just for the most part didn’t because of the validation error. I think anything that prevents all the css hacks that used to happen to make valid is a good thing.
Do you guys use html5 now? I’ve been holding off but I think it’s time on new projects. I won’t go and recode all my old stuff. The only problem is ie8 tide to XP. I still have an XP as an example. Therefore ie8 will be around for a while to come. html5 shim then you say. No, I’ve never been a fan of that mentality of thinking. XHTML as an example. That’s why I always chose html. Even my web design site which presumably is mostly web designers has 60-70% ie visitors. Purposefully designing in a way that demands making work-arounds for the majority of your users makes no sense to me. Mine as well just take the simple route. Hence my hesitance for html5.
Its a pity that XHTML 2 died to be replaced with XHTML 5.
XHTML 2 had done away with the <a> tag completely and allowed the href attribute to be added to any tag that you also wanted to be a link. That idea makes far more sense now than having the <a> tag. After all browsers have already got rid of one of the two uses for the <a> tag by allowing an id on any tag to be used as the destination for a link so why not do away with the other one and allow any tag to be a link.
Do I author non normative HTML5? The answer is; no; the only place you’d see me write any h5 would be answering a forum question on Fred5. I’d have a similar opinion to Stephen regarding the XHTML 2 hyperlink approach over the h5 anchor solution. Though I believe either two methods would be misused and wasn’t that thrilled over the XHTML 2 idea either at the time.
The reason HTML5 allowed the “anchors wrapping blocks” thing, really, is because
- authors have been doing this since the beginning of time (even tho it was wrong and even tho IE and FF puked chunks when they saw it)
- browsers have been dealing with this bad markup since the beginning of time (error rendering)
Because all browsers had some kind of error rendering to deal with inline anchors around blocks, and because so many people were using this bad markup for a reasonable idea (making a whole chunka somethin clickable to a single URL, instead of multiples of the same URL), when they were writing their Unified Error Rendering, the vendors realised they could set the same behaviour cross-browser for this. And apparently this was easier than adding working href attributes to non-anchors (they looked at that, with <nav> and then directly <li href=“blah”> inside).
So while they were at it, they mumbled something about smelly cowpaths and legalised it. Kinda like embed.
I’ve gone ahead and started even using the crappy new tags, only because in my eyes they’re good for just one little thing: they add an easy anchor (for browsers) for the accessibility layer.
And because of this (mostly, there were other reasons too), Steve Faulkner proposed a new element: <main>. And just to be difficult, I decided to add <main> to a page I was rewriting anyways. It’s <main role=main>. W00ts.
So far as I know, the other new elements aren’t used by any other software. At least not like we were so promised with diamonds in the sky. That was the dream, right? We wanted more semantics so other software could figure out what kind of data our web page/app content was? The dream’s still a lie, with the small exception (slowly getting there) of screen readers and probably Dragon Naturally Speaking (not sure about anything else though).
So the new elements otherwise don’t give us any real semantics. They let us style based on tag, which is cute (I like it), and they make IE required to run Javascript (not cute).
So I figured, if I’m going to use crappy meaningless tags, I’ll add <main> just because it’ll not only help map the role=main to a tag, but unlike nav and header and footer, it’ll probably help software like Readability, stuff that takes out the meat of the page and removes all the crap and chrome and junk around it. I like that. Sounds nice.
And since browsers and other software don’t really otherwise have any clue what any of this all means, and IE needs JS, I just do a
document.createElement(‘main’);
and make a <main role=“main”>
and style with
[role=main] {display: block; background-color: #080;}
(which does work in IE7 so long as it runs JS and after you make it a block element of course)
and now I can officially call myself a hipster, but a hipster with a heart of gold cause I’m doing it for a Good Cause. Righteousness, brotha!
Off Topic:
It’s like the Browser Wars in reverse.
I should stop now with the madness, because I may be setting a barrier for this little guy
then again I’m one of these
Since browsers work around it anyway it makes absolutely no difference with HTML 5 that they allow it.
Where it does make a difference is with XHTML 5. Sonce XHTML does not try to patch up junk code the only way to allow that particular coding practice in XHTML was to allow it in XHTML 5.
So you could say that this particular change is more for future use in XHTML since it has long been allowed by browsers in HTML and so with HTML 5 it is just a matter of dejeure catching up with defacto.
True, except the unified error rendering thing is kinda new. Someone (or a few intrepid someones) actually crawled through tests and vomit to see how browsers dealt with all sorts of errors. And they were all different. And this was not good. And the WHATWG were Displeased. And so they said, “Let there be Unified Error Rendering”. And So It Was Done. And they agreed it was Good. Or something. So I heard, once. Rumours on teh interwebs. And actually, it wasn’t really unified error rendering, but more the idea that how browsers deal with errors also belongs in the HTML specs, so they added it.
Maybe, I dunno. Since XHTML (even 5) still uses XML parsing, they would have to actively change parsing for that. I know they made some changes for “XHTML5” (but they were really arcane and weird and had to do with tokens and schemas and stuff I don’t understand cause actually I no speak-a de XML) but I dunno if they were planning to do that for anchors wrapping blocks. Probably not. Part of the whole “cowpaths” thing is partially the reluctant admission that, yeah, HTML is sloppy and silly by nature and is meant for nose-picking dreambeaver-using humans to mutilate and modify and get wrong, because, well, it must be good because Postal’s law something something. Or in other words, correct HTML must not be placed above making sure your Tumbler’s 10px-font-sized rage against, like, the system man, or what you think about some celebrity shows up to grandma who clicked a link. Cause grandma’d be all like, “what’s this ‘XML error’ thing mean? What did I do wrong? I don’t get it.” <back button> So everyone’s all like POSTAL’S LAW DON’T BREAK IT! IT’S SAVIOUR OF TEH INTERNETS
Or whatever.
XML/XHTML wasn’t like 'Nam, man. There are rules.
Anchors are the most important element on the web, this change makes perfect sense to me. Why not be able to link a block of content? It’s also becoming important because of newer devices that require large hit targets. I like interfaces where you can click anywhere. e.g.
It’s a trend that will continue for good reason and all new browsers handle it well.