[TETENAL]

Can anyone tell why only inline elements but no block elements are allowed inside an anchor tag? Any browser supports block elements anyway (although everyone with different quirks) and one can work around it by defining inline elements as blocks with CSS (which is painful and forces you to mess with the logical structure of the document). So why does the standard make you go through all those hoops to get this done? From a usability standpoint larger click targets are better, so when it makes sense a block as links is simply better.

So does anyone know what the actual reasoning is for not allowing this?

[besson3c]

Well, it would create a whole lot of hassles with Javascript event capturing/bubbling, for starters, sandwiching another object into the mix.

I'm not sure why you would want to do this though? Why not create the links via an ordered or unordered list? Maybe I'm not understanding you completely...

[TETENAL]

Originally Posted by besson3c 

Well, it would create a whole lot of hassles with Javascript event capturing/bubbling, for starters, sandwiching another object into the mix.

Creating hassle for the browser or the web developer? The only difference between a block and an inline element is the way it is displayed. And since blocks are rectangles, event handling is actually easier than on irregularly shaped runs of inline elements.

I'm not sure why you would want to do this though? Why not create the links via an ordered or unordered list? Maybe I'm not understanding you completely...

Take the following example from a typical news site:

There are 3 blocks with an image, a header and regular text. Each block links to one article, so it would be ideal to make the whole block a link to create large targets for the user to click on. But that is not allowed, so the link can only be within the header leaving a much smaller click target for the user.
In the actual site the image is also a link, but the developers had to create two links to the identical target, because one linke can not embrace the image and the header because a header is a block element. It's a workaround that is against the logical structure of the document.

So the question remains, what is the original reasoning for not allowing blocks inside anchor tags?

[besson3c]

What happens if you want the word "Oscars" to be a link? What if you want to provide a little widget in here that is activated on mouse click? The best way to do this is to use Javascript and learn about event bubbling and capturing so that you have complete control over how this would work.

[TETENAL]

If you want to make "Oscars" into a link, you make it into a link. There is zero difference of whether this is inside an inline element or a block element that is within a link. Except the latter doesn't validate.

Javascript is not a solution since onclick() doesn't trigger the browser's contextual menu for regular links. But that is not the issue. I already told you I know how to work around it using CSS.

My question is, why do I even have to work around it? What is the original reasoning for not allowing it?

[besson3c]

Originally Posted by TETENAL 

If you want to make "Oscars" into a link, you make it into a link. There is zero difference of whether this is inside an inline element or a block element that is within a link. Except the latter doesn't validate.

This is true, I can't explain why inline elements support tags of their own either, because they shouldn't. In this case you'd have a conflict of two hrefs that are invoked when you click on the item. Which should take precedence?

My thinking is that tags on inline elements are permitted because it is possible that they would just be used for text formatting (which should still be handled in CSS), but this is just speculation.

Javascript is not a solution since onclick() doesn't trigger the browser's contextual menu for regular links. But that is not the issue. I already told you I know how to work around it using CSS.

My question is, why do I even have to work around it? What is the original reasoning for not allowing it?

You would have to give up seeing the link in the browser's status bar (which I'm assuming is what you meant), but this would indeed work. You could even have the cursor pointer change to the finger to show that the item is clickable.

I don't have the original reasoning behind it, but I've given you a possible, perfectly valid reason. This would be a bad practice even if it were possible for the reason I gave.

[TETENAL]

Originally Posted by besson3c 

This is true, I can't explain why inline elements support tags of their own either, because they shouldn't.

Huh? They support tags because HTML supports nested tags. That's one of its main features.

In this case you'd have a conflict of two hrefs that are invoked when you click on the item. Which should take precedence?

I would say obviously the inner one.

You would have to give up seeing the link in the browser's status bar (which I'm assuming is what you meant)

No, that's not all you would have to give up. You give up the context menu with "Open in new tab", "Download link" or what not the browser might support. You give up command-clicking to open in a new tab etc. Faking links with Javascript sucks.

I don't have the original reasoning behind it, but I've given you a possible, perfectly valid reason.

No, you have given a reason why an anchor tag should not be allowed within an anchor tag (valid is up to discussion). You haven't given a reason why a block element is not allowed within an anchor tag. If anyone knows this, it would be great to hear.

[besson3c]

Originally Posted by TETENAL 

Huh? They support tags because HTML supports nested tags. That's one of its main features.

Not when it potentially creates these sorts of problems

I would say obviously the inner one.

Well this isn't obvious. IE does it one way, other browsers do it another. Read up on Javascript event capturing vs. event bubbling (which would apply if that inline widget I used in my example was controlled by Javascript and wasn't just a link to another page).

No, that's not all you would have to give up. You give up the context menu with "Open in new tab", "Download link" or what not the browser might support. You give up command-clicking to open in a new tab etc. Faking links with Javascript sucks.

True.

No, you have given a reason why an anchor tag should not be allowed within an anchor tag (valid is up to discussion). You haven't given a reason why a block element is not allowed within an anchor tag. If anyone knows this, it would be great to hear.

Because that block element has its own Javascript properties that support event handlers and other hooks that could cause problems. The real answer involves reading up on the DOM, but I think I'm on the right track here.

This is bad practice because of the reason I have mentioned here.

[besson3c]

never mind...

[besson3c]

Let me take another stab at this...

What you could do is put your HTML inside an li or div tag, include regular anchor tags for the image and text in the standard way, and include an event observer for the surrounding block area. This event observer will be passed the object where the click originated. If the node is either the image or the link, it returns and does nothing. If it isn't, it cancels the click and navigates to the new page.

This way, you can have your standard image + text with the status bar and the ability to load these into new tabs, as well as the ability to click on the surrounding area to extend the size of this target.

[besson3c]

One way you can tell where the click originated is by also attaching observers to the image and text. If you use Prototype (don't know if this applies to standard Javascript or not), you can pass this observer the originating object.

[TETENAL]

Originally Posted by besson3c 

Because that block element has its own Javascript properties that support event handlers and other hooks that could cause problems. The real answer involves reading up on the DOM, but I think I'm on the right track here.

No you're not. A block and an inline element get the same representation in the DOM. And they also have the same hooks for Javascript. All you can do with Javascript on a DIV you can also do on a SPAN. It makes no difference.

[Oisín]

Originally Posted by besson3c 

Because that block element has its own Javascript properties that support event handlers and other hooks that could cause problems.

Is this not true for inline elements, as well?

If I can nest a span element inside an anchor element, why not a div element (other than semantic reasons—I’m just using these two, since they’re nearly identical, apart from their display type)? What event handlers do divs have that spans don’t?

If I want to have a link that contains, for example, a list, why shouldn’t I be able to?

It makes sense that nested anchors are not permitted (which is most likely the reason different browsers handle nested anchors differently); but I don’t see the sense in not allowing any block-level element inside an anchor. The specs even say specifically that the rule that inline objects may not contain block-level objects is only “generally”, not a universal rule.

[besson3c]

I guess that makes sense... you can do a document.getElementById on any element that has been assigned an ID.

I don't really know why this is illegal, but I maintain that it is a bad practice anyway.

[ort888]

Because of the internet?

[Synotic]

HTML 5 has it covered:

Originally Posted by Jeffrey Zeldman

Eric chose HTML 5 because it permits any element to be an HREF, and this empowered him to solve complex layout problems with simple, semantic markup.

Originally Posted by Eric Meyer

HTML5 was originally picked in order to be able to wrap anchor elements around things like paragraphs.

Also, This thread is altogether too confusing.

It's not so much that spec disallows blocks inside of links, but that the spec disallows blocks inside of inlines, which links are. I'm not sure that some kind of contextual link that turned block-level or inline-level based on its context could work cleanly, or even make sense.

The solution that HTML 5 took (which admittedly might be nonobvious since we're used to using traditional links) is to just give the ability to attach an HREF to any arbitrary element. Including, in your case, Tetenal, an enclosing DIV.

The whole capturing vs. bubbling discussion is not particularly relevant since the spec is very explicit about nested links —

12.2.2 Nested links are illegal

Links and anchors defined by the A element must not be nested; an A element must not contain any other A elements.

This is referring to A elements, but I'm assuming that this would extend to all forms of nested linking.

So the real answer is that it's a product of their being inline and it was a use case that just wasn't considered until HTML 5. In fact, due to browser bugs, it's still not possible (read the link above for details). It's not an unreasonable request (and the example you give is the exact reason people bring this up), but it's not possible just yet.

[besson3c]

I disagree that capturing vs. bubbling is irrelevant. If nested links are an illegal part of the HTML spec, that's fine, but this still doesn't address what happens when an onclick event handler is attached to items within the a element. How does simply changing the legality of this solve these sorts of problems with these conflicts?

[Chuckit]

Originally Posted by Synotic 

The solution that HTML 5 took (which admittedly might be nonobvious since we're used to using traditional links) is to just give the ability to attach an HREF to any arbitrary element. Including, in your case, Tetenal, an enclosing DIV.

Do you know where in the spec it says that? I think Zeldman was confusing HTML5 with XHTML 2, a totally different spec with a very different design philosophy. What HTML5 does is allow anchor links to encompass almost any set of elements, like TETENAL was wishing for in the OP.

[TETENAL]

Originally Posted by besson3c 

If nested links are an illegal part of the HTML spec, that's fine, but this still doesn't address what happens when an onclick event handler is attached to items within the a element. How does simply changing the legality of this solve these sorts of problems with these conflicts?

OK, that is a problem, but what does that have to do with inline and block elements? Absolutely nothing. Yet that was the question. This kind of problem is exactly the same one way or the other, so that doesn't explain at all why block elements are not allowed.

[TETENAL]

Originally Posted by Chuckit 

Do you know where in the spec it says that? I think Zeldman was confusing HTML5 with XHTML 2, a totally different spec with a very different design philosophy.

I couldn't find this in the HTML5 spec either, but I had a look at the site it links to (http://www.aneventapart.com/). They have the same design as the news-site example I posted earlier. 3 blocks that should be a link as a whole. And they came up with the same solution I used: put spans inside and set everything to display:block using CSS. I still think it's more than silly that one hast to work around this like that.

What HTML5 does is allow anchor links to encompass almost any set of elements, like TETENAL was wishing for in the OP.

Are you sure it does? The W3C validator complains when you do this in HTML5.

[besson3c]

Originally Posted by TETENAL 

OK, that is a problem, but what does that have to do with inline and block elements? Absolutely nothing. Yet that was the question. This kind of problem is exactly the same one way or the other, so that doesn't explain at all why block elements are not allowed.

It provides a possible reason why thus far this has been illegal and not a part of the spec. This problem needs to be solved in order for what you want to do to really work as it should. Like I said, you shouldn't embed inline elements inside a div tag either, although I can't explain why one is legal and the other isn't.

[awaspaas]

It's an obvious security risk. Duh.

[Synotic]

Originally Posted by Chuckit 

Do you know where in the spec it says that? I think Zeldman was confusing HTML5 with XHTML 2, a totally different spec with a very different design philosophy. What HTML5 does is allow anchor links to encompass almost any set of elements, like TETENAL was wishing for in the OP.

You're right. It looks like Eric and Zeldman were saying two different things. I'm still a little unclear on whether the display type of the anchor element changes depending on context (if it's wrapped around a paragraph element, it can't really be inline anymore). I might be reading the spec wrong but it doesn't seem to specify this. Here is the specific part of the spec:

The a element may be wrapped around entire paragraphs, lists, tables, and so forth, even entire sections, so long as there is no interactive content within (e.g. buttons or other links). This example shows how this can be used to make an entire advertising block into a link:

...followed by an example (which includes block elements).

Originally Posted by TETENAL 

Are you sure it does? The W3C validator complains when you do this in HTML5.

The validator says that HTML 5 support is experimental, so it might not be working just yet, but the spec does give that specific use case.

Originally Posted by besson3c

This is true, I can't explain why inline elements support tags of their own either, because they shouldn't. In this case you'd have a conflict of two hrefs that are invoked when you click on the item. Which should take precedence?

My thinking is that tags on inline elements are permitted because it is possible that they would just be used for text formatting (which should still be handled in CSS), but this is just speculation.

Besson — I was a little confused by what you wrote here, but I forgot to mention it. What do you mean by "inline elements supporting tags"? Do you mean attaching events to inline elements? Or adding an HREF attribute? Or just nesting inline elements?

Originally Posted by besson3c

It provides a possible reason why thus far this has been illegal and not a part of the spec. This problem needs to be solved in order for what you want to do to really work as it should. Like I said, you shouldn't embed inline elements inside a div tag either, although I can't explain why one is legal and the other isn't.

I still think there's some confusion in terminology here. I'm pretty sure that you're not actually saying that you shouldn't nest inline elements in DIV tags... STRONG, EM, and A are all inline elements elements, and I'd be surprised if you could design an entire site without putting a link in a DIV tag...

I think you're referring to adding an event (say a click event) to an inline element, and how that might conflict with the events of the parent (say, block) element. Or arguing that you should never be able to attach events to inner elements.

--

An aside — the HTML 5 spec also explicitly forbids "interactive content . . . e.g. buttons or other links" within a link and I would probably define something that has an onclick event as a button, so we could also say that this problem is a nonproblem.

That said, I think the more general events-on-inline-elements discussion is an interesting one, so...

--

I wouldn't necessarily consider this conflict a problem — the entire event capturing/bubbling model exists to let the developer take advantage of this "conflict."

Consider modeling the desktop with an unordered list. The list would represent the physical space and list items represent the icons. You would want both the desktop and the icons to have click events associated with them. If you click on the desktop, then all existing icons are deselected. If you click on the icon, you hop on the bubbling phase, select your icon, and then stop the propagation of the event (so that it isn't immediately deselected).

Another case might be visually representing threaded messages (as in Mail.app), where you would hop on the capturing phase. Selecting a message in a thread first selects the thread itself, and then the event continues down and selects the message (in this case we don't stop the propagation).

So event conflicts can actually be very useful and often necessary in designing widgets.

--

All of that said, you're technically right. Confusion will occur if you add a click event inside a link. In my examples, the actions taken are styling an item so that it looks "selected." With a link, depending on which event model is used, the page it links to may load before the other event can take place. The order that takes place is well-documented and isn't at all specific to links. I don't think that because it's technically possible to put a button (or button-like element) inside of a link that they prohibited it in the spec. This, and any other "interactive content" are prohibited, anyway. I'm still confused, given the flexibility of the HTML 5 spec, whether the A tag is now inline or block (or both, seemingly), but I still think that the reason it wasn't allowed was because (1) it's an inline element and (2) it just wasn't a use case they accounted for.