Welcome to the MacNN Forums.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

You are here: MacNN Forums > Community > MacNN Lounge > What is the reasoning for not allowing blocks inside an anchor tag?

What is the reasoning for not allowing blocks inside an anchor tag?
Thread Tools
TETENAL
Addicted to MacNN
Join Date: Aug 2004
Location: FFM
Status: Offline
Reply With Quote
Mar 8, 2009, 06:21 PM
 
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
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Mar 8, 2009, 06:38 PM
 
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  (op)
Addicted to MacNN
Join Date: Aug 2004
Location: FFM
Status: Offline
Reply With Quote
Mar 8, 2009, 07:06 PM
 
Originally Posted by besson3c View Post
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
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Mar 8, 2009, 07:13 PM
 
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  (op)
Addicted to MacNN
Join Date: Aug 2004
Location: FFM
Status: Offline
Reply With Quote
Mar 8, 2009, 07:38 PM
 
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
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Mar 8, 2009, 07:44 PM
 
Originally Posted by TETENAL View Post
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  (op)
Addicted to MacNN
Join Date: Aug 2004
Location: FFM
Status: Offline
Reply With Quote
Mar 8, 2009, 08:14 PM
 
Originally Posted by besson3c View Post
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
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Mar 8, 2009, 08:40 PM
 
Originally Posted by TETENAL View Post
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
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Mar 8, 2009, 09:08 PM
 
never mind...
     
besson3c
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Mar 8, 2009, 09:26 PM
 
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
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Mar 8, 2009, 09:28 PM
 
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  (op)
Addicted to MacNN
Join Date: Aug 2004
Location: FFM
Status: Offline
Reply With Quote
Mar 8, 2009, 09:53 PM
 
Originally Posted by besson3c View Post
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
Moderator Emeritus
Join Date: Mar 2004
Location: Copenhagen
Status: Offline
Reply With Quote
Mar 8, 2009, 10:00 PM
 
Originally Posted by besson3c View Post
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
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Mar 9, 2009, 05:26 PM
 
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
Addicted to MacNN
Join Date: Feb 2001
Location: Your Anus
Status: Offline
Reply With Quote
Mar 9, 2009, 06:01 PM
 
Because of the internet?

My sig is 1 pixel too big.
     
Synotic
Mac Elite
Join Date: Oct 2000
Status: Offline
Reply With Quote
Mar 11, 2009, 04:41 PM
 
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
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Mar 12, 2009, 08:45 PM
 
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
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status: Offline
Reply With Quote
Mar 12, 2009, 09:23 PM
 
Originally Posted by Synotic View Post
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.
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
     
TETENAL  (op)
Addicted to MacNN
Join Date: Aug 2004
Location: FFM
Status: Offline
Reply With Quote
Mar 12, 2009, 10:37 PM
 
Originally Posted by besson3c View Post
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  (op)
Addicted to MacNN
Join Date: Aug 2004
Location: FFM
Status: Offline
Reply With Quote
Mar 12, 2009, 10:44 PM
 
Originally Posted by Chuckit View Post
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
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Mar 13, 2009, 01:43 AM
 
Originally Posted by TETENAL View Post
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
Mac Elite
Join Date: Apr 2001
Location: Minneapolis, MN
Status: Offline
Reply With Quote
Mar 13, 2009, 02:24 AM
 
It's an obvious security risk. Duh.
     
Synotic
Mac Elite
Join Date: Oct 2000
Status: Offline
Reply With Quote
Mar 13, 2009, 03:25 AM
 
Originally Posted by Chuckit View Post
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 View Post
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.
     
   
Thread Tools
 
Forum Links
Forum Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Top
Privacy Policy
All times are GMT -4. The time now is 11:35 PM.
All contents of these forums © 1995-2017 MacNN. All rights reserved.
Branding + Design: www.gesamtbild.com
vBulletin v.3.8.8 © 2000-2017, Jelsoft Enterprises Ltd.,