- From: Sam Ruby <rubys@us.ibm.com>
- Date: Tue, 1 Apr 2008 15:40:26 -0400
- To: Ian Hickson <ian@hixie.ch>
- Cc: Bruce Miller <bruce.miller@nist.gov>, David Carlisle <davidc@nag.co.uk>, Henri Sivonen <hsivonen@iki.fi>, public-html@w3.org, public-html-request@w3.org, Robert Miner <robertm@dessci.com>, www-math@w3.org
- Message-ID: <OF5C94F918.283CF133-ON8525741E.0069F26F-8525741E.006C12C5@us.ibm.com>
Ian Hickson wrote on 03/31/2008 08:43:16 PM: > > On Mon, 31 Mar 2008, Bruce Miller wrote: > > > > The proposal seems to be something like: > > an HTML5 page with MathML-ish stuff in it. > > The math in the _text_ of the page > > > > (1) emphatically does not have the MathML namespace, > > I would expect that we would allow the xmlns="" attribute on <math> to > have the MathML namespace, in the same way as we allow xmlns="" on <html> > to contain the XHTML namespace. It wouldn't have any effect, though. Such attributes will have an effect in IE8; and, in fact, as I understand it be necessary for proper interoperation (with what for now is hypothetical) IE8 plugins that might support MathML. There is a tension here. Forgive me as I'm about to use a loaded term. One can take a myopic view and look at simply the requirements for a few specific vocabularies as they are understood at a given moment at time and hope they never change, and optimize for that. Or you can take a farsighted view (which, if the world were fair, would have an equally negative connotation as nearsighted) and not focus on local optimizations but on the big picture: namely that there will always be a need for people to "unilaterally extend the language to address problems we are currently unaware of and that therefore are not covered by existing functionality; Without trampling on the toes of others; and without being beholden to an external entity to provide the enhancements for the author on a timescale that is useful to the author." BTW, I strongly object to these requirements being listed in the "Requirements met" section of this page http://wiki.whatwg.org/wiki/New_Vocabularies If that were true, we woulbd be discussing how we could implement math and graphics solely using div and span elements. Since we are not, that means to me that either the fundamental requirement wasn't adequately captured or the assessment that it was met was faulty. I tend to believe the latter is the case: the requirement is correct and the claim is a wee bit optimistic. > * only <mspace>, <malignmark>, <maligngroup>, <mglyph>, <none>, and > <mprescripts> use the empty element syntax Here is a concrete example of the near/far-sighted tension. The above list is based on a snapshot at this point in time of MathML. It may constrain the future independent evolution of that particular vocabulary. An alternative which would not constrain the evolution in such a matter would be to enter yet another parsing mode when one encounters a given bit of markup. In the IE8 case, that signal is a recognized value for an attribute named "xmlns". I would suggest that this workgroup evalutate such an approach thouroughly before discarding it as it has some nice characteristics. The approach outlined above also doesn't scale, not just over time, but over other vocabularies. If you look at a typical InkScape produced SVG document, you will often see empty <defs/> elements. And in other cases, you will see empty <g/> elements. One can argue that such elements would be unnecessary if hand authored, but they are common place enough and the problems it creates are subtle enough and difficult enough to debug that it probably does make sense to consider a parsing mode for elements in mathml and svg namespaces that can handle not only issues such as these, but potentially also CDATA. - Sam Ruby
Received on Tuesday, 1 April 2008 19:42:29 UTC