Whether HTML5 allows it or not this is just a bad idea BECAUSE:
I would advise wrapping CONTENTS of the DIV and treating the DIV as the wrapper. It is after all also quite valid to do: <A><P> ,<A><UL>, and so forth.
[font=verdana]Sorry but I really don’t see your objection here. Yes, it’s illegal to nest an anchor inside an anchor, but it’s just as possible to do it with <a> tags being allowed inline only. You could still end up with illegal code such as
<p>Here is <a href="#">an anchor <b>with some text bold <a href="#">and another anchor</a> nested</b> inside</a> it.</p>
if your editor doesn’t enforce correct code structure. There’s no reason why this should be any more likely with block-level anchors. You should only be making a block anchor where it’s clear what you want to link to, so there shouldn’t be a whole load of problems where you even want to nest another anchor inside it. I can think of plenty of examples where it would be appropriate to wrap an anchor round an <li> tag, particularly if the <li> itself includes block elements.[/font]
Sorry but I really don’t see your objection here.
My objection is that in the case you have listed the nested anchor most likely occurs out of either lack of knowledge or willful negligence. Kinda like someone nesting a UL inside a P.
However because DIVs contain … well anything … its possible to create templates that will on occasion INADVERTENTLY nest anchors, or paint you into a corner where you have nested anchors. Like I said above this is likely to happen ONLY in the case of CMSs or when you hand your templates off to a clients for them to populate with content, but still is something that should be considered
My objection is that in the case you have listed the nested anchor most likely occurs out of either lack of knowledge or willful negligence. Kinda like someone nesting a UL inside a P.
This is a separate problem to changing a rule about what can nest within an anchor.
This is the problem of stupid people, ignorant people, mistakes by non-stupid and non-ignorant people, and stupid things (machines) writing code. Though honestly I would think following validation rules is something a stupid machine could do. Machines are pretty good at blindly following rules. You’d think they could follow rules of HTML, whichever ones you choose to give them.
Preventing a change in rules does not prevent the above problem. You’re just hoping that not changing the rules will lead more letting the current set of rules to still work despite the above problem: that is, if a stupid CMS wrote everything in divs, it couldn’t possibly fail validation so long as it could follow basic nesting rules. It wouldn’t need to know what the tag was.
But HTML is not a regular language*; it has complex rules and I’m generally not against changing those rules, provided there are good reasons. Whenever you get more complex rules (“some thingies may be nested within other thingies, except when the nested is the same type as the nestee, if either are any of the following types of thingies”), yes you’ll get more errors. But there was a point to the rules being that complex in the first place, and we like the benefits we get from them, and we cannot stop the Stupid People Problem simply by reducing complexity here cause then we’ll lose our benefits. We likeses our benefitses, we likeses them.
And the reasons people state for wanting anchors to be able to wrap block chunks of stuff? I can see the same requirement for forms (containing subforms and non-form things, the latter of which too many people do already) for large applications. The old HTML+HTTP GET/POST set of options stops working when you have chunks of things that need to act like forms yet still have an over-arching “submit” button who can send all the other separate forms’ data as one thing. Today people just use Javascript for this instead, sometimes with many small forms, more often without any forms at all.
Anything that allows for more flexibility to adjust to whatever the situation demands is a good thing in my eyes. Just because you can doesn’t mean you have to. But it does give the option which is good in my opinion.
I much prefer this idea as well, shame it never happened
I agree, the reason would have been because most browsers out there already supported links around block level elements. So the only thing that needed changing were the validation rules.
Still, I don’t understand the arguments against this. The fact is that you should be able to link any type of content. Whether that content can best be described best using block or inline HTML elements is completely irrelevant.