W3C home > Mailing lists > Public > public-html@w3.org > April 2008

Re: Exploring new vocabularies for HTML

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


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

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:14 GMT