Re: Linking (chapter 6.4.3) probably underspecified

2010-04-13 16:54 David Carlisle <davidc@nag.co.uk>:
> On 13/04/2010 15:23, Christoph LANGE wrote:
> > With<mo>  that works fine, using @xlink:href (Gecko does not
> > yet support @href.)
> 
> what version?  xlink support has been disabled since FF3, see
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=427990
> 
> unless this got fixed in some new release without being logged in
> bugzilla??

No idea, but I'm using 3.6.3, and @xlink:href works.  That's also what MathML
3 recommends, isn't it?  I.e. that @href should be preferred, but @xlink:href
still supported.  In any case, @href is not yet supported.  At least when I
try it, it doesn't work, and there is still an open ticket for it:
https://bugzilla.mozilla.org/show_bug.cgi?id=534968.

> As for your main point about nested links. I fear that the only thing
> that the spec could say is that you should not nest links, although the
> schema does not enforce it. That would match the behaviour for  html
> (and xlink simple links) xhtml extended links would support more exotic
> link times but they are largely unimplemented.

Not sure how it is specified for HTML, but this is how Firefox implements it:
I tried a nested link in normal HTML, linking the outer one to
javascript:alert('outer'), and the inner one to javascript:alert('inner').
Clicking on the inner link opens three alert boxes, in order: inner, outer,
outer.

> In a browser context especially it would be difficult to specify linking
> behaviour too different from the html linking behaviour and HTML
> (certainly html4 I failed to find an exact reference in html5) any
> nested link elements are formally a syntax error.
> 
> Ie I think we could perhaps change
> 
> However, links on elements that do not correspond to any part of a
> visual rendering should be avoided
> 
> to
> 
> However, links on elements that do not correspond to any part of a
> visual rendering, and nested links,  should be avoided
> 
> this doesn't leave things completely specified or help with your actual
> use case, but may the best way for the specification to mention the
> problem leaving the door open for some implementations to offer you
> support, but without mandating that.

That sounds reasonable to me – except, as you say, that it does not yet help
with linking mfrac.

Thanks for discussing this!

Cheers,

Christoph

-- 
Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701