Re: Linking (chapter 6.4.3) probably underspecified

David Carlisle <davidc@nag.co.uk> writes:

> . . .
> 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.

Yes.

> Ie I think we could perhaps change

Yes.

> However, links on elements that do not correspond to any part of a
> visual rendering should be avoided

Yes.

I've just done some testing with FF 3.6 in Linux.  There are 3
techniques that have at least some bare thread of provenance.

  1.  Xlink, which was working in Firefox 2, no longer works.

  2.  href as an attribute on MathML elements does not work.

  3.  Mix and match namespaces: use the xmlns attribute with
      mtext to place its contents in the xhtml namespace and
      then place an html anchor inside the mtext (but this
      presents a strong challenge to browsers that enable mathml
      as an embedded object, e.g., IE/MathPlayer).  This works
      in Firefox 3.6 just as it has worked in Firefox, I believe,
      since the beginning.

As to (2), I would suggest for semantic reasons that href be
incorporated as an attribute in presentation MathML but only for
mtext so that (a) the implications for a CAS importing presentation
markup or for up-translation to content markup are minimal and
(b) traditional html-like visual link rendering can be sanely provided.
I do intend here that when an mtext has an href, its content should
be the visual text for a web link.

                                    -- Bill


P.S.  The GELLMU didactic production system originally used (3), but
when I was yelled at, I provided an option for using (1), which was
then made the default -- and presently still is the default.  However,
(3) is used when the environmental variable GELLMU_XLink has the
value 0.

Received on Wednesday, 14 April 2010 19:51:13 UTC