- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Fri, 3 Apr 2009 12:44:27 +0300
- To: David Carlisle <davidc@nag.co.uk>
- Cc: public-html@w3.org
On Apr 3, 2009, at 12:16, David Carlisle wrote: >> Actually, the parsing side of xlink:href in HTML5 is a solved >> problem. > > Henri, sorry if this is a silly question, but do you mean it's > solved in > Gecko or solved in the html5 specification? Solved in the HTML5 spec and on the parser layer in HTML5 parser- enabled Gecko builds. However, the above-DOM linking behavior is broken, so it doesn't help much yet that the parser part is working. > And aside from any hopefully temporary problems with xlink in mathml > in > Gecko. Have you any thoughts on whether we should allow href > everywhere > in mathml. Introducing a duplicate-namespace mechanism for a thing that already had a mechanism turned out to be a very bad idea in the case of id and xml:id. I hear that the issues with xml:id are now recognized in the SVG WG. I wonder if the Math WG could avoid the problem entirely and not introduce xml:id into MathML at all. I dislike XLink and Namespaces, but my initial reaction is that introducing a duplicate mechanism is trouble compared to defining xlink:href semantics on MathML (and SVG) nodes independently of XLink and zapping generic XLink from browsers. Linkness is very different from IDness, though, so I'm not sure if having a duplicate mechanism for xlink:href in MathML (and SVG) is as bad as having a duplicate mechanism for id. A duplicate mechanism for xlink:href might be harmless, but I'm not ready to say so yet, because I haven't thought about it carefully and I'm predisposed to assume it's not harmless. > Was for example the xhtml2 style of href on all html elements > considered > and rejected for html5, or has it just not come up? Considered and rejected. (It comes up very often.) -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Friday, 3 April 2009 09:45:15 UTC