- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 02 Apr 2009 20:07:58 -0400
- To: David Carlisle <davidc@nag.co.uk>
- CC: public-html@w3.org
David Carlisle wrote: > (Firefox 3 pulled support for > xlink, thus removing link support from all existing XHTML+MathML pages). Actually, all that happened is that we stopped using generic XMLElement nodes for MathML, and those are the only ones that ever supported "generic" XLink in Gecko. The fact that MathMLElement didn't get the XLink support was just a mistake, and is a bug. Generic XLink continues to be supported on elements in unknown namespaces, for now, but we do plan to remove it. That said, I fully applaud not deferring to the incredibly poorly defined XML Linking specification for any sort of behavior. Per that specification, it's not even clear what <mi xlimk:type="simple" xlink:href="http:.....">text</mi> should do. > Clearly the final decision about MathML design rests with the Math WG, > but (X)HTML(5) integration is a very important goal for us, so we would > be interested to know from the HTML WG, and in particular any browser > vendors considering mathml-in-html support, whether there are advantages > or disadvantages to either of these design choices, or if there are > other options that we could consider. Offhand, restricting linking behavior to only some nodes has certain benefits (e.g. one only needs to worry about a subset of nodes when dealing with visited state). I'm not sure how much of a concern that should be (the main difference is a few words of state per node, basically). If you allow links on all elements, there needs to be a clear definition of how nested links should behave. But I guess you have that problem with just <maction> anyway... One question I do have: what are the main reasons for links in MathML right now in the first place? -Boris
Received on Friday, 3 April 2009 00:08:43 UTC