RE: MathML-in-HTML5

Hi.

I have a couple of things to add to the discussion.  Ian wrote:

> It's just that anything with namespaces causes authors 
> confusion. I don't see the advantages here outweighing the
disadvantages.

The main benefit to allowing namespace prefixes on the math elements in
HTML5 is interoperability with Internet Explorer.  This is a key point,
so I hope you will forgive me if I explain at length.

Ian also posted a few days ago that pragmatism was a major motivation
for HTML5. Pragmatically speaking, the single greatest challenge I see
for people wanting to use MathML in web pages is browser
interoperability.  My own view is that this limits the use of MathML in
web pages today more than any other single factor, and if you could
address that in HTML5 I think you will be making a great contribution.

Since I started working on MathML more than a decade ago, I've had the
opportunity to talk to many, many people and companies interested in
publishing mathematical content to the web. The threads that have been
reprised on this list in the last weeks have been present in those
discussions since the beginning: terse input syntax like TeX vs explicit
markup, presentational vs semantic representation, HTML vs XHTML. They
are important and people have strong views.  

But in practice, the decision about what format use for publishing math
almost always rests on the question of browser interoperability.  Most
people interested in putting stuff on the web regard reaching a broad
audience as a requirement, and thus it is a requirement that their pages
work decently on most browsers.  This means that MathML usage for web
publication today is limited to situations where the author has some
special relationship with the audience and can thus require
MathML-capable browsers, or where the author has some other need for
MathML (e.g. backend workflow, searching, accessibility, computer
algebra) that make the extra effort of dealing browser interoperability
worth it.

Let me explain the interoperability situation as I see it in a little
more detail.  I'll focus on just IE with MathPlayer, IE without
MathPlayer and Firefox for simplicity, though obviously the full picture
would need to include Opera and Safari and so on as well:

IE without MathPlayer 
--------------------------------------
* application/xhtml+xml without an XSLT stylesheet just shows the parse
tree
* application/xhtml+xml with an XSLT stylesheet works, but can only show
math via HTML/CSS/JavaScript/font hacks, or point to an alternative
format
* text/html obviously works, but can only show math via
HTML/CSS/JavaScript/font hacks, or point to an alternative format

IE with MathPlayer
--------------------------------------
* application/xhtml+xml document and MathML renders via MathPlayer, but
XTHML support is limited to pretending it is HTML with syntax errors in
the usual IE way
* application/xhtml+xml with an XSLT stylesheet works, with MathML
properly rendered* text/html works with MathML properly rendered.  NOTE:
this only works if the MathML markup uses a namespace prefix!

Firefox
--------------------------------------
* application/xhtml+xml works with MathML properly rendered 
* application/xhtml+xml with an XSLT stylesheet works with MathML
properly rendered
* text/html works, but the MathML doesn't render

Thus, the choices facing a potential content publisher are:

* application/xhtml+xml without a stylesheet is a non-starter, since you
cannot even show a decent error message to IE users without MathPlayer.
You can have two versions (e.g. HTML+images and XHTML+MathML) and a
gateway page.  But many potential publishers regard that as
unacceptable.

* application/xhtml+xml + XSLT is a possibility.  You can hit all
platforms and generally achieve the best math rendering possible for a
given UA.  But this is a complicated solution, requiring a lot of web
programming and XML/XSLT knowledge, often involving two versions (since
the HTML fallback for IE without MathPlayer and other non-MathML capable
browsers is usually not high enough quality, so you have to publish the
PDF anyway or whatever).  This takes it out of range for many
prospective content publishers.

* text/html works fine and is what the huge majority of people do.
Unfortnately, because MathML is only supported in text/html by
IE+MathPlayer, it is too narrow an audience for most publishers, and
thus we get text/html + images, or in some cases, two versions of the
content.  This is why we are having this discussion.

If I understand correctly, Roger and Ian are proposing that (possibly a
subset or 'profile') of MathML be incorporated into HTML5 in the default
namespace.  In other words, something like this:

<html>
...
<p>Consider the the case where
<math><mi>n</mi><mo>=</mo><mn>2</mn></math>
...
</html>

I like this idea in the abstract, and lobbied for it in both HTML 3.1
and HTML 4.0 (losing both times obviously).  However, note that
currently the only way to get IE to hand off the MathML to a plugin like
MathPlayer is to use a namespace prefix. Here I really mean a prefix in
the source markup, e.g. <m:math>, as their binding mechanism actually
associates plug-in renderers with namespace prefixes.) Thus, if you add
MathML without a prefix to HTML5, the compatibility issue will remain.
In IE *with or without MathPlayer* the MathML won't render.  That is
actually worse than the current application/xhtml+xml situation in some
ways, since you couldn't reach any IE users at all.

On the other hand, if in HTML5 you permit markup like

<html>
...
<p>Consider the the case where
<m:math><m:mi>n</m:mi><m:mo>=</m:mo><m:mn>2</m:mn></m:math>
...
</html>

then we would have interoperable HTML+MathML documents between major
platforms.  True, for the platforms without MathML support of any kind,
you will still have to resort to some sort of content negotiation and
display images or something.  However, since we are in the familiar and
powerful HTML+JavaScript+CSS setting, this is pretty easy, via
document.write() commands or whatever. Not nearly so intimidating as
dealing with server MIME configuration and XSLT and so on. 

If your interest is in parsing character data to infer token types, or
having your favorite shorthand input syntax, or any of the other similar
ideas that have been expressed on this list, packages like JSMath and
ASCIMathML show how to let authors type things like

<p>Suppose `ax^2+bx+c=0` and `a!=0`</p>

in their HTML and have JavaScript process it on the client.  Clearly
content negotiation for non-MathML UAs is no big deal for packages like
this.  What would be a big deal is that all of a sudden they would go
from being tools only for people who could reasonably exect their
readers to set up a MathML capable browser, to tools for most anyone
wanting to put math on the web. 

I should add that I haven't tried to think through the implications of
allowing markup like <m:math>...</m:math> in HTML5, since I know you are
concerned about complicating your parser and error handling and so on.
While I don't want to claim that two terrible hacks make a good
solution, I'd even settle for basically thinking of them as elements
named m:math and so on, and not allowing any of the rest of the full
namespace apparatus.  But obviously I defer to you guys on these
details.  As I'm sure you have grasped by this point, all I care about
is having a single HTML +MathML work properly across browsers.

To sum up: 

1) To have the greatest impact on math on the Web, HTML5 should try to
achieve better browser interoperability, since from a pragmatic point of
view, that is generally the critical factor for publishers considering
how to publish mathematical content.

2) To the best of my knowledge, Internet Explorer's mechanism for MathML
support (which is a special case of it's general XML island support)
requires that math markup use a namespace prefix on the tags.  

3) Since I'm arguing that interoperability is important, I oppose
suggestions to introduce parsing of token data, Tex-like input syntaxes
and so on.  I could, however, live with support only for a subset or
profile of MathML.


--Robert


Robert Miner
Director, New Product Development
W3C Math WG co-chair

Design Science, Inc.
140 Pine Avenue, 4th Floor
Long Beach, California  90802
USA
Tel:  (651) 223-2883
Fax:  (651) 292-0014
robertm@dessci.com
www.dessci.com
~ Makers of MathType, MathFlow, MathPlayer, WebEQ, Equation Editor,
TexAide ~

 

> -----Original Message-----
> From: dev-tech-mathml-bounces@lists.mozilla.org 
> [mailto:dev-tech-mathml-bounces@lists.mozilla.org] On Behalf 
> Of Ian Hickson
> Sent: Tuesday, October 03, 2006 6:43 PM
> To: Roger B. Sidje
> Cc: www-math@w3.org; dev-tech-mathml@lists.mozilla.org; David Carlisle
> Subject: Re: MathML-in-HTML5
> 
> On Wed, 4 Oct 2006, Roger B. Sidje wrote:
> >
> > On 4/10/2006 9:19 AM, Ian Hickson wrote:
> > > 
> > > So basically, it's the same as tag soup. I don't really see an 
> > > advantage to going down that route (with its complexities like 
> > > namespace prefixes, etc)
> > 
> > Is it because you are thinking globally w.r.t. multiple mixings?
> 
> No. It's just that anything with namespaces causes authors 
> confusion. I 
> don't see the advantages here outweighing the disadvantages.
> 
> -- 
> Ian Hickson               U+1047E                
> )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   
> _\  ;`._ ,.
> Things that are impossible just take longer.   
> `._.-(,_..'--(,_..'`-.;.'
> _______________________________________________
> dev-tech-mathml mailing list
> dev-tech-mathml@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-mathml
>

Received on Wednesday, 4 October 2006 16:06:43 UTC