[whatwg] Proposal for a link attribute to replace <a href>

[Ian Hickson]

Every now and then, the issue of a global href="" attribute for all 
elements comes up. There are many valid use cases for this, like being 
able to make all cells in a table row act like a link, or making a banner 
ad act like a single block of a link.

Unfortunately, I've been told over and over by implementers that a global 
href="" is a bad idea, and at the end of the day, the implementors are the 
ones who have the final say, so that's just a non-starter.

There are also alternative suggestions, like making <a> contain any 
element. Unfortunately, none of these end up working (e.g. for this 
proposal, <a><p></a> would create an unexpected DOM -- we'd have to make 
</p> end tags not optional when the next end tag was an </a>, which would 
be somewhat confusing).

So I apologise again for rejecting these proposals, and hope that it 
doesn't discourage you from contributing further to other aspects of 
HTML5.


I haven't included all the feedback on this topic that I received, but 
here is a sampling with some responses:

On Wed, 28 May 2008, Martin Atkins wrote:
>
> I agree that this is an unconvincing example, but consider instead 
> banner ads that are created from a bunch of HTML markup rather than a 
> single image; they generally want the entire banner rectangle to be 
> "clickable" but make use of tables and all sorts of other strange 
> things.

Just do:

   <div class="ad" onclick="this.getElementsByTagName('a')[0].click()">
    ...<a href="...">Buy viagra!</a>...
   </div>

(Note that .click() is new in HTML5.)


On Thu, 29 May 2008, Frank Hellenkamp wrote:
> 
> But I step over different kinds of teaser (news- and article-teasers) 
> during my work, that are made out of images, text and headlines.
> 
> Now, you have to do this (without javascript):
> 
> <div class="teaser">
> 	<a href="link.html"><img src="image.png"></a>
> 	<h3><a href="link.html">newsteaser</a></h3>
> 	<p><a href="link.html">Text</a></p>
> 	<p><a href="link.html">Text</a></p>
> </div>
> 
> If you are good, you also set the a-elements to "display: block" so that
> the whole area is clickable, not only the text.
> 
> It would be *much* more simple/useful to have something like this:
> 
> <div class="teaser" href="link.html">
> 	<img src="image.png">
> 	<h3>newsteaser</h3>
> 	<p>Text</p>
> 	<p>Text</p>
> </div>
> 
> Or this:
> 
> <a href="link.html">
> 	<div class="teaser">
> 		<img src="image.png">
> 		<h3>newsteaser</h3>
> 		<p>Text</p>
> 		<p>Text</p>
> 	</div>
> </a>

You could just do:

   <article class="teaser" 
            onclick="location = this.getElementsByTagName('a')[0]">
    <h3><a href="link.html">News Teaser</a></h3>
    <figure>
     <img src="image.png" alt="...">
     <legend>...</legend>
    </figure>
    <p>Text</p>
    <p>Text</p>
   </article>

...or some such (<article> and <figure> are new in HTML5).


On Thu, 29 May 2008, Frank Hellenkamp wrote:
> 
> In the best case the whole rectangle of the teaser is clickable. At the 
> moment you need some javascript or an a-tag with "display: block" for 
> it, to get this behavior (see example in my last mail).

I don't think the JS is a big deal.


On Sat, 31 May 2008, Shannon wrote:
> 
> http://www.duttondirect.com/automotive/for_sale
> 
> The table hover effect is not easily acheived without global href. My 
> client likes it, the users like it and it is perfectly obvious 
> navigation (despite being non-standard). At the moment I am acheiving 
> the effect with event bubbling but I consider this approach to be 
> bloated, ineligant, prone to breakage and lag on slower devices. It also 
> suffers from the poor compatibility of the event.button property 
> (activates on right/middle-click instead of just left). Nonetheless it 
> improves the ease of navigation for most users.
> 
> A global href would allow me too turn the whole mess of event code into:
> 
> <tr href="foo.html"> ... </tr>
> 
> ... and all the issues I just mentioned would vanish.

Sure. What's wrong with doing this, though?:

   <tr onclick="location = this.querySelector(":link,:visited")">...</tr>

(querySelector() is new in the Selectors API spec.)


> Is global href a burden on browser vendors?
> Unlikely. It's behaviour is nearly identical to onclick="window.location=foo"
> which is already supported on the majority of modern browsers except Lynx.

We don't get to decide if it's a burden or not, they do.


On Fri, 30 May 2008, Ernest Cline wrote:
> 
> What about adding a third non-metadata hyperlink element, say <anchor>, 
> which would be a flow content element with flow content allowed in it?  
> This would seem to cover the use cases presented, while preserving <a> 
> as being phrasing content only.  The only issue I see if this were 
> added, is whether it would be better to have the ismap attribute of 
> <img> only work with <a> or to have it work with the new element as 
> well.

We already have three elements that do linking in HTML5, adding a fourth 
seems like a lot.


On Sat, 31 May 2008, Anne van Kesteren wrote:
> 
> The <a> element can already do this and it would be backwards 
> compatible.

As far as I can tell this breaks down for <a><p>...</a>.


On Sun, 1 Jun 2008, Ernest Cline wrote:
> 
> Backwards compatible with some user agents but not with the specs.  The 
> following fragment has never been valid according to the specs in any of 
> HTML 1.0, 2.0, 3.2, or 4, or the current draft of HTML 5, despite <a>, 
> <h3>, and <p> appearing in all of them.
> 
> <a href="foo.html">
>  <h3>Heading</h3>
>  <p>Text</p>
> </a>
> 
> The specs have always called for <a> to only have inline content save 
> that for some reason, HTML 2.0 did allow <h1> to <h6> inside <a> though 
> that was not recommended, and that was reverted back to inline only in 
> 3.2.
> 
> While changing the specs to match user agent behavior is a possibility, 
> it is not one that should be taken lightly. (Nor should adding a new 
> flow content hyperlink element, be taken lightly either.)

Changing the specs to match user agent behavior is the whole way HTML5 
works, so that's not a big problem. The problem is that the current parse 
model results in odd behaviour if we allow <a> as a flow-content element.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'