[whatwg] Proposal for a link attribute to replace <a href>
ian at hixie.ch
Wed May 28 04:05:04 PDT 2008
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
I am not convinced that this clutter is a big problem that we need to
> 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>
(Note that the <ul> or <ol> elements would be far more appropriate
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.
> 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg