From: Robert Miner <robertm@dessci.com>

Date: Wed, 4 Oct 2006 09:06:25 -0700

Message-ID: <D1EFB337111B674B8F1BE155B01C6DD6013A7539@franklin.corp.dessci>

To: "Ian Hickson" <ian@hixie.ch>, "Roger B. Sidje" <rbs@maths.uq.edu.au>

Cc: <www-math@w3.org>, <dev-tech-mathml@lists.mozilla.org>, "David Carlisle" <davidc@nag.co.uk>

Date: Wed, 4 Oct 2006 09:06:25 -0700

Message-ID: <D1EFB337111B674B8F1BE155B01C6DD6013A7539@franklin.corp.dessci>

To: "Ian Hickson" <ian@hixie.ch>, "Roger B. Sidje" <rbs@maths.uq.edu.au>

Cc: <www-math@w3.org>, <dev-tech-mathml@lists.mozilla.org>, "David Carlisle" <davidc@nag.co.uk>

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

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:27:38 UTC
*