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
