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

I do not know how common the banner link abuse described is; using a table
for banner layout is abusive enough to make this an edge case.  The
immediate remedy would be to transform the source document so as to
propagate the anchors downwards, i.e. into each table cell.  I am sure the
banner server can do that.
Chris

-----Original Message-----
From: whatwg-bounces@lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Martin Atkins
Sent: Wednesday, May 28, 2008 10:45 PM
Cc: whatwg at whatwg.org
Subject: Re: [whatwg] Proposal for a link attribute to replace <a href>

Ian Hickson wrote:
> 
>> This proposal would circumvent <A>'s main limitation which is its 
>> requirement to not wrap block-level elements or 'interactive' content. 
>> The HTML5 draft requires it wrap 'phrasing content' (essentially 
>> paragraphs) and not wrap 'interactive' content (such as other 
>> hyperlinks) however I see no reason why a link attribute should require 
>> these limits. Links would simply cascade as in the following example:
>>
>> <table link="alphabet.html" title="Alphabetical List">
>>    <tr>
>>       <td>A</td>
>>       <td>B</td>
>>       <td link="c.html" title="More about C">C</td>
>>       <td>D</td>
>>    </tr>
>> </table>
> 
[snip]
> 
> I don't think that making an entire list into a link is really something 
> that is useful from a usability point of view.
> 

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.

In the wild, I've seen advertisers do two different, undesirable things: 
some ignore the rules altogether and just put <table> inside <a>, which 
seems to work with some minor quirks in most browsers, or they just 
attach an onclick event to the root element and let events bubble up to 
it, where the event handler just navigates to the target page.

It could be argued that the quirks you see when nesting <table> inside 
<a> show that implementing a block-level link element is troublesome, 
but I also consider that if browsers can successfully handle the 
bubbling of the click and mouseover event up the DOM tree through block 
elements they ought to be able to do the hit-testing necessary to 
support mouse-based navigation of a block-level link element.

I'm not necessarily arguing for a global link attribute, but it would be 
useful if the A element's content model were extended to allow all 
elements so that there's a markup-only way to easily turn an entire 
block element into a link.

This could also be extended to the LABEL element, which in visual 
user-agents is often interacted with in a way somewhat like a link.

Received on Thursday, 29 May 2008 00:31:33 UTC