[whatwg] Proposal for a link attribute to replace <a href>
giecrilj at stegny.2a.pl
Thu May 29 00:31:33 PDT 2008
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.
From: whatwg-bounces at 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">
>> <td link="c.html" title="More about C">C</td>
> 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.
More information about the whatwg