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

[Tab Atkins Jr.]

On Fri, May 30, 2008 at 12:45 PM, Shannon <shannon at arc.net.au> wrote:

> There's a lot of focus on "use cases". Here is the one that led me to start
> this thread:
>
> http://www.duttondirect.com/automotive/for_sale (disclaimer: I am not
> responsible for the design of this page)
>
> 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.

This is a good point - that style of navigation is indeed very easy and
intuitive for people to use.  You *want* to click on the whole row,
especially with the nice color change on hover; making any particular piece
of the row the 'clickable' portion would actually reduce usability.

> 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.
>
However, I'm still quite aware of the issues with making href= global, which
have been brought up before (the big thing is that href doesn't work in
isolation - it's got a whole bevy of cousin attributes that would have to
move to global as well).

However, has there ever been a  response from browser authors about just
making <a> allow block-level content within it?  The main issue I can think
of with this is default UI - how should it be indicated that a block-level
element is a link?  It's pretty well-established that authors generally hate
the border around images within an <a> (my default stylesheet turns off
image borders just for that reason).  However, it at least gives *some*
indication of a link - should we be bordering all the block-level elements
(and underlining all the inline) within an <a>?  It would be an ugly
default, but one that can be removed pretty trivially - a simple "a * {
border: none; }" rule would remove it and let you style your stuff as you
wish.

As far as I can tell a block-level <a> is already supported just fine, as
you *can* wrap block-level content in an <a> and have it work as expected
right now, and CSSing an <a> into display:block works wonderfully.  It
*appears* that only the standard disallows this at the moment - the actual
browsers handle it just fine.

>
> People on this list should be very careful about claiming properties and
> tags will be abused. Bad interfaces exist already and often as a result of
> missing behaviours in the standard. Wrapping tables and block content in
> <a></a> is just one example (it works, believe it or not). Trying to force
> designers into better layouts by denying features is stupid. It will simply
> drive them into invalid layouts, Javascript, Flash or Silverlight where they
> are free to make even bigger mockeries of standards and interface
> conventions. As far as designers are concerned HTML5 is a *competitor* to
> these technologies. If you cannot compete in terms of features and ease of
> use you'll end up with a proprietary web.
>
>
> In summary then:
>
> Is global href going to create bad layouts?
> Depends. Skilled UI designers can improve their layouts - bad designers can
> make theirs worse.
>
> 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.
>
> Is denying designers features they want going to increase standards
> compliance?
> No. It will reduce compliance.
>
> Regards,
> Shannon
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080530/9f9ca3e2/attachment-0001.htm>