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

[Ian Hickson]

On Wed, 27 Feb 2008, Shannon wrote:
>
> With the capabilities of modern browsers it seems to me that a specific 
> tag for hyperlinks is no longer required or useful and could be 
> depreciated with a more versatile global "link" attribute.

This has been proposed several times but several browser vendors have 
indicated that they would not implement such a feature.

In practice, if we look at existing global attributes, we find that 
historically only attributes that have a very orthogonal effect on the 
document are successful. For example, class="", lang="", and id="" have no 
direct effect on the element, style="" and dir="" are equivalent to CSS 
rules, and title="" is implemented as an orthogonal UI feature.

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.


> I believe that hyperlinks now have more in common with attributes such 
> as ONCLICK than they do with tags since in web applications links often 
> define actions rather than simply being a part of the document 
> structure. The <A> tag would continue its role as an anchor but the HREF 
> attribute would be phased out making <A> a more consistent element 
> (since links and anchors are really quite separate concepts). Below is 
> an example of the proposed link attribute in action:
> 
> <li><a href="foo.html">Foo</a></li>
> 
> could be written as:
> 
> <li link="foo.html">Foo</li>
> 
> No useful semantic information is lost however the markup is cleaner and 
> the DOM drops an unnecessary node (which could speed up certain 
> applications).

I am not convinced that this clutter is a big problem that we need to 
solve.


> 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>

(Note that the <ul> or <ol> elements would be far more appropriate 
elements here.)

I don't think that making an entire list into a link is really something 
that is useful from a usability point of view.


> In the example above clicking anywhere on the table except 'C' brings up 
> a generic page, whereas 'C' has dedicated content. The following nested 
> links would also be valid:
> 
> <span link="foo.html">click anywhere on this line except <b 
> link="bar.html" title="Go to bar instead">here</b> to visit foo.</span>

That seems like terrible UI.


> The link attribute would make adding hyperlinks to DOM nodes easy:
> 
> node.link = 'http://foo.bar.baz'; /* Create a hyperlink on an element */
> nodes_with_a_link = document.getElementsByAttribute('link'); /* Get all links.
> This method doesn't exist in the draft but can be written in javascript using
> iterators */

Again, turning individual elements into links doesn't seem like a big 
problem. DOM ranges with selectNode() and surroundContents() could easily 
be wrapped in a utility function if that was really needed, and it would 
even allow you to linkify spans of text rather than only elements.


> I believe a link attribute would be a significant improvement to HTML. 
> The only reasons I can think of not to add this would be the added 
> complexity for browsers and authors during the transition period. The 
> advantages include less markup, simpler DOM structure, nested 
> hyperlinks, onclick fallbacks and better consistency in the spec.

I don't really understand what is more consistent than using href="" on 
<a>, <area>, and <link>. I further don't think that nested hyperlinks are 
a good idea. onclick fallbacks can already be done using <a>, which also 
provides a better user experience on existin UAs. The remaining advantages 
are definitely not, IMHO, outweighed by the significant costs.


> Being such a common element web authors will probably keep using <a 
> href> for many years to come regardless of the standard but that should 
> not be a problem since <a href> and link should coexist quite easily in 
> valid HTML. Once awareness has spread then future drafts could 
> depreciate the href attribute on anchors.

I think we're adding enough new features that we shouldn't be adding 
features that don't really add anything substantial.


On Thu, 28 Feb 2008, Shannon wrote:
> 
> FAQ:  * Browser vendors have reported that implementing it would be 
> extremely complex.
> 
> I find this claim incredible.

To be blunt, it doesn't matter. If the browser developers say no, there's 
not much point trying to change their mind, it just causes them to ignore 
us. We only have any power so long as we tell them to do things they are 
willing to do -- when we start telling them to do things that they are not 
in fact willing to do, they start ignoring us.


On Thu, 28 Feb 2008, Robert O'Rourke wrote:
> 
> I don't understand why buttons should not be allowed an href, obviously 
> when the button or input is to submit a form (ie. explicitly having 
> type="submit" as an attribute) it shouldn't be allowed but I'd find it 
> useful where I've had to style a collection of links and inputs to be 
> similar, for example the steps for a checkout process

Note that WF2 has <button action="" method=""> to do this.

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