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

[Shannon]

Pawe? Stradomski wrote:
 > W li?cie Shannon z dnia czwartek 28 lutego 2008:
 >How should nested links
 > work? Suppose I put href="http://a" on <p> element and 
href="http://b" on a
 > <span> inside that <p>. What should happen when the user clicks on that
 > <span>? That's the reason why nested <a>'s are forbidden by HTML 4 and
 > XHTML 1.
 >
 > I'm not against href on every element, but then nesting elements with 
href
 > attribute should be forbidden. Similarly href should be forbidden on
 > interactive elements (buttons etc.), so making it global would be a 
problem.

Browsers were a lot more primitive back then. I have used nested 
onclick() handlers in the real world and had  no problems, nor did my 
users. I have also safely used onclick on form elements. The browser 
always knows which element is directly under the mouse (that's why 
:hover works). Only the link directly under the mouse should trigger. 
Again, this is behaviour that onclick and :hover already perform in all 
major browsers. As I've said before, href should not be forbidden on 
interactive elements, the spec should define the event hierarchy, eg:  
event->input->link/href


Chris wrote:
 >
 > Tables should be used to present tabular data. 
 > Tabular data is something the user may want to meditate or to copy;
 > their content cannot be grasped in a glance.
 > Hyperlinked text should be a concise description
 > of the content of the other page;
 > a table does not meet that requirement.
 > This design violates the least surprise principle.
 >
 > ...
 >
 > It would be difficult to style a hyperlink within a hyperlink;
 > moreover, a hyperlink that contains another hyperlink is not concise,
 > see above.

You'll never eliminate bad design by putting these limitations in the 
spec. What you'll do is make bad designers work around them (using 
onclick() or <a><table>...</table></a>). I've seen it happen before more 
times than I can count. Bad designers don't validate their code either. 
On the other hand designers who do know what they are doing can be 
artificially restricted or forced into non-compliance by these sorts of 
rules. What "makes sense" is really a matter of context (or clients), 
and cannot be discussed in abstract like this. The point is there _are_ 
situations I have experienced myself where link/href would be a better 
alternative than <a> or  onclick() and situations where nested 
interaction is useful and still makes sense to the user. Finally, style 
should follow the stylesheet rules like everything else, nested or not. 
There is not a strong case for making the browser distinguish the 
boundaries between nested links if the designer chooses not to.


Geoffrey Sneddon wrote:
 > While yes, you could rely on something like that, it totally breaks 
in any user agent without scripting support. Nothing else, to my 
knowledge, in HTML 5 leads to total loss of functionality without 
JavaScript whatsoever.

Well nothing except global/session/database storage, the "irrelevant" 
attribute, contenteditable, contextmenu, draggable, the video and audio 
elements, canvas and the connection interface. Some of these can't even 
be done in Javascript. Despite the efforts of this group 
backwards-compatibility is ultimately the authors responsibility. eg:

<!-- Modern content -->
<div link="foo.html">foo</div>
<!-- Fallback / Search-engine content. Not rendered in HTML5 compliant 
browser -->
<a href="foo.html" irrelevant>foo</a>

 > Nothing else reinvents the wheel for something with which we already 
have a perfectly fine solution already.
   
If it were perfectly fine designers wouldn't be asking for this. My view 
is that <a> and onclick do not solve all cases where hyperlinks are needed.


Overall I'd say that most objections to a global href tend to focus on 
all the bad things a designer could do with it. However I deal with many 
designers, good and bad, and I can categorical state that the bad ones 
have no qualms about mangling pages using the Javascript, plugins and 
non-compliant markup already at their disposal. Everytime you deny them 
a feature to make them "behave" you just encourage them to go out and 
write another hack. Making the language more flexible will not make 
things any worse. Using bad designers as a reason to deny features is 
basically an argument for aborting all work on new HTML5 features. I 
could name 100 ways to abuse the storage proposals yet we persist 
because they are useful. Global href is useful, and it should be 
discussed on the basis of correct usage and what its behaviour should be 
(ie, my first post).


Shannon