W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2008

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

From: Martin Atkins <mart@degeneration.co.uk>
Date: Wed, 28 May 2008 21:44:35 +0100
Message-ID: <483DC433.3020701@degeneration.co.uk>
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>
> 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.

 > The one attribute that _does_ have any direct effect on the element,
 > contentEditable, is fraught with problems, and has caused us no end of
 > hassle for years.

As an aside, I would suggest that perhaps the main cause of problems 
with contentEditable isn't that it's a global attribute, but rather that 
it requires WYSIWYG editing of a language that has many features that 
cannot easily be represented visually.

Making arbitrary content elements into clickable links seems like a much 
easier problem. Obviously it makes less sense for elements like HTML and 
LINK which generally have no direct representation within the rendered page.
Received on Wednesday, 28 May 2008 13:44:35 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:02 UTC