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

[Ian Hickson]

On Wed, 30 Jul 2008, Simon Pieters wrote:
> > 
> > There are also alternative suggestions, like making <a> contain any 
> > element. Unfortunately, none of these end up working (e.g. for this 
> > proposal, <a><p></a> would create an unexpected DOM -- we'd have to 
> > make </p> end tags not optional when the next end tag was an </a>, 
> > which would be somewhat confusing).
> 
> The rules for optional end tags are already pretty confusing. I don't 
> think it's a problem to require </p> when the "p" element is the last 
> child of an "a" element.

Ok. Fair enough. I have allowed <a> elements to surround other 
(non-interactive) elements.


On Wed, 30 Jul 2008, James Graham wrote:
> 
> I think <table><a><tr> also causes problems; being able to link whole 
> table rows seems like one of the major use cases for this proposal.

Yes. I don't see how to fix that one.


> Would the implementor feedback that global href is a bad idea still 
> apply if instead of "global" it was "large set of elements" where the 
> large set would explicitly not include things like form elements?

Yeah -- the problem isn't so much the number of elements, as the 
complexity of doing a link. Resolving URLs, making it match 
:link/:visited, handling clicks, handling base URLs, hover effects with 
status information, etc. Links are hard.


On Wed, 30 Jul 2008, Simon Pieters wrote:
> 
> Perhaps HTMLElement should have a links collection to make it simpler to 
> write the script?
>
>    <tr onclick="links[0].click()">

I don't know that that is all that much better than 
getElementsByTagName('a')[0], or even:

  <tr onclick="link(event)"> ... </tr>

  <script>
   function link(e) {
     var a = e.currentTarget.getElementsByTagName('a')[0];
     if (e.target != a)
       a.click();
   }
  </script>


On Wed, 30 Jul 2008, Smylers wrote:
> > 
> > I don't think the JS is a big deal.
> 
> Compared to <a href="...">, using onlick events generally provides a 
> worse user experience, such as the status bar not being updated to 
> indicate a link's destination in advance of committing to navigate 
> there.

Sure, but that's ok, because the link is still visible and present as a 
link in this case -- it's just that the user can click anywhere to 
activate it instead of only on the text. I don't think that's a 
particularly horrible user experience, I think it's fine. No?


On Wed, 30 Jul 2008, Russell Leggett wrote:
>
> What about an alternative attribute like "navigate" instead of "href". It
> would not carry the full weight of the anchor tag, but would handle the 90%
> use case. It would not allow for the same options as the a tag, and the a
> tag would continue to work the same way that it has been.

The difficulties are in the basic linking ability, not the more esoteric 
features, sadly.


On Wed, 30 Jul 2008, Kristof Zelechovski wrote:
>
> By the current spec, the Anchor element is phrasing content, which is a
> special case of flow content.  Did you mean "transparent content" instead?
> EC! I cannot see any "inline content" in HTML5, at least not in 3.4.1 where
> content models are defined.

HTML5 has no "inline" or "block" concept, indeed.

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