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

[Philip Taylor]

On 28/02/2008, Shannon <shannon at arc.net.au> wrote:
> http://wiki.whatwg.org/wiki/FAQ#Does_HTML5_support_href_on_any_element_like_XHTML_2.0.3F

> So 'backwards-compatibility', as defined by the same document, can be
> achieved by using javascript to walk the DOM and add
> 'window.location(node.getAttribute('link'))' to the onclick handler of
> any nodes with a link attribute. I have done a very similar thing before
> to implement :hover on non-anchor elements in IE.

I imagine the script would have problems with incremental loading - if
someone clicks a link before the page has finished loading and before
the script has executed, then it won't work. Is there a way to avoid
that problem and make it work as well as a real implementation?

There are also tools like search engines that need to recognise links
and can't be fixed by compatibility scripts. (Fortunately it's much
easier to upgrade all the world's search engines than all its web
browsers, so this is a less significant issue than with browsers.)

> A global attribute offers several features that <a>
> does not - most importantly nested links and the ability to hyperlink
> block and interactive elements without breaking validation.

Are there cases where <div ...><a href="..." style="display:block;
width:100%; height:100%"> ... </a></div> is not adequate for making
block links?

> FAQ:      * It doesn't make sense for all elements, such as interactive
> elements like input and button, where the use of href would interfere
> with their normal function.
>
> As long as the spec is clear about which actions take precedence then
> this is not an issue.

Having to make the spec clear is an issue :-)
It would take quite a bit of effort to design and specify the feature
in sufficient detail, and to write test cases, and to update the spec
in response to implementor feedback about what would cause them fewer
problems. That is all much harder when the new feature interacts with
a lot of existing features (inputs, buttons, image maps, iframes, DOM
events, etc), compared to something fairly self-contained (like
<video>).

> How is a global link/href any more
> difficult than the existing implementations of onmouseup/down/whatever?
> It's basically the same thing - only *simpler* (no scripting, events,
> bubbling, etc).

As far as I'm aware, HTML elements currently have at most one default
click-event handler and any number of DOM handlers. The new link
attribute wouldn't be a DOM event handler (since it ought to behave
much more like <a href>), so it would either be an entirely new type
of event handler or it would break the assumption that there is a
single default handler, and I can imagine that that would cause
difficulties. (But I have no implementation experience so I could be
entirely wrong.)

There are cases like

  <button type="submit" link="..." onclick="event.preventDefault()">
  <button type="submit" link="javascript:event.preventDefault()">
  <a href="1" link="2" onclick="window.location=3">
  <a href="1" link="2" onclick="window.location=3; return false">
  etc

where the interaction between several aspects of the event model would
have to be defined (and implemented and tested), requiring some new
complexity on top of the current href+onclick model.


Another issue is that <a href> has a number of other attributes for
links, and it would be bad design if a generalisation of href didn't
allow those attributes on other elements. That includes 'target'
(conflicts with <base target>, <form target>), 'type' (conflicts with
<style type>, <script type>, <embed type>, <object type>), 'media'
(conflicts with <style media>, <link media>), etc.

Is there a nice way to solve those conflicts? Renaming the link
attributes (the same as renaming 'href' to 'link') would be confusing
to people who already know HTML, and it would be hard to find good
names that aren't used already. Defining lots of exceptional cases for
certain attributes on certain elements would make the language harder
to understand and implement and test. Defining exceptions for a
category of 'non-visible elements' (script, style, etc) wouldn't work
since <script style="display:block"> is not non-visible. I'm not sure
how this could be made to work well.

>
> Shannon
>

-- 
Philip Taylor
excors at gmail.com