Re: MathML-in-HTML5

On 28/09/2006 10:44 PM, White Lynx wrote:

> I consider switching from XML to text/html as inappropriate and
> pointless development, morover it is damaging in long term perspective.

Damaging to what? To MathML? Not really in my opinion. What damage could 
there be to have plenty of MathML formulas on the web?!? But to the 
XML/XHTML agenda, possibly. And that has been the real "problem" since 
the beginning, and which I alluded to in my opening post. It wasn't a 
fight fitted for a niche MathML that was already struggling to make a 
name for itself.

Interested in using MathML? First pass that XHTML barrier, and that 
wasn't even a small barrier. It was a significant barrier, taking seven 
years before IE understood application/xhtml+xml. As for the fact that 
"the people that yesterday argued that we all must switch to XHTML, 
today argue that HTML5 is the only way to go". Speaking generally (or 
specifically w.r.t. MathML)? People had to switch to XHTML to get MathML 
-- it wasn't even a matter of choice. C.f. again this very insightful 
post on the matter.
http://groups.google.com/group/netscape.public.mozilla.mathml/msg/4d58c35217afcb54?dmode=source

So after all these years making the case for something else (XHTML), 
what this thread is about is to make <math>...</math> works everywhere, 
especially where it still matters the most today, and that is HTML5. As 
I indicated, my original take is for <math>...</math> to work as-is -- 
as we have come to know and enjoy it. But it is obvious that this new 
mixing has to be defined somehow, even if we later come to a conclusion 
saying that it is an opaque <object>, or a profile of some sort.

But I hope that as further insight is gathered through the 
proof-of-concept, it turns out that <math>...</math> is just fine, and 
that interoperability issues won't be thrown at an already special niche 
technology. While on this, I should stress that tag-soug is possible 
anywhere, although this is often not mentioned because the extent is 
much different. Well-formed tag-soup (as odd as it sounds...) is 
possible, which is why these reddish "invalid-markup" messages sometimes 
pop in Gecko's MathML rendering. Such things are left undefined by the 
spec. However, in the case of MathML where the markup is generated 
automatically by software, there is no particular reason to believe that 
these generators will suddenly start to generate an indigestible 
tag-soup. So it is not quite realistic to over-emphasize this issue.

MathML already works in XML/XHTML and this proposal is not going to 
break that. But there is little else to gain there (as far as MathML in 
concerned). Publishers who use XML in their back-end production line can 
continue to do what they have been doing.

However, MathML stands to win more (especially individual users) in the 
front-end by being in HTML (HTML5 for that matter). This might also 
encourage those building HTML authoring tools to consider interfacing 
MathML (either with free or commercial plug-ins) because the XML/XHTML 
barrier won't be standing right at their face. (On the issue of the 
verbosity of MathML, this wouldn't be much of an issue if people didn't 
have to stare at the MathML. In fact, when I look at HTML+Javascript+CSS 
pages these days, they are also quite cryptic... It is possible to have 
invisible/collapsible MathML in an editor interfaced to a plug-in? 
Surely for people who have experience building comprehensive editors. 
But with the XHTML barrier they can't even chime in...)

I am sure by now that it should be evident that it is XML/XHTML that 
stand to lose with MathML enabled in HTML5. Anyway, XHTML doesn't seem 
to be going anywhere. (How often does one stumble on a page served as 
application/xhtml+xml -- if it isn't a page with MathML?) In any case, 
as I indicated, it will still work there, maybe not just as _the_ 
selling argument that it is now. (Many math pages wouldn't have bothered 
with XHTML if it had been possible to have MathML in HTML, and that's 
where their loss might come from. But does it really matter? Read Robert 
Miner's earlier post again.)

To advance MathML, we contributed a great deal to XML/XHTML and pushed 
for them so much that it is very easy to forget the initial focus. 
MathML-in-HTML5? Worth a try. The thread is now about the issues in 
prototyping this, and the benefits (or otherwise) for MathML and math on 
the web. And I must say I don't see that much disadvantages in enabling 
MathML everywhere at this point.
---
RBS

> 
> 
> First of all it is unclear where this idea comes from, as MathML
> community has no legacy text/html content that one should care about.
> All MathML content is wellformed (by definition), which means that one
> has less errors in MathML documents comparing to what one would have in
> tagsoup approach, it also means that all MathML content can can be
> handled with XML tools, can be processed with XSLT, matched using
> XPath, mixed with other XML based markup languages (OpenMath, SVG) etc.
> There is no single MathML implementation that supports text/html
> tagsoup, but does not support X(HT)ML, while inverse is not true, there
> are XML only MathML implementations that by definition have nothing to
> do with HTML legacy.
> 
> Further it is not clear for me why this has to be done today, after
> paying price for wellformedness and tackling XML related problems for
> seven years, when finally MSIE/MathPlayer accept application/xhtml+xml
> and thus allow people to deliver the same XHTML+MathML to
> MSIE/MathPlayer and Mozilla (one can add Opera with UserJS) someone
> decides to revert (more precisely convert) everything to tagsoup.
> 
> Profiling policy is sounds unclear and strange to me. Solving issue on
> the level "I'm happy to drop/add any tag to this list. Just give me the
> list you want" or based on MathML support level on some particular
> implementation seems to be irresponsible.
> There are at least two subgroups in W3C Math WG that one could drop a
> message with profile proposal to after looking at "wrong table".
> One is called liason with WhatWG subgroup and as name suggests is
> expected to ensure that needs of MathML are addressed in WhatWG specs.
> Another is liason with CSS subgroup, which is expected to define MathML
> profile suitable for usage in XML+CSS framework and a few CSS
> extensions needed to format proposed MathML profile.
> There is also subgroup that deals with compound document formats. My
> opinion is that profiling of MathML should be coordinated with these
> units as irresponsible steps may spoil W3C efforts in the same area.
> 
> One more thing that sounds unlogical and rather strange is that
> Mozilla/WhatWG try to move MathML further from XML+CSS framework,
> by converting XML to tagsoup with ad hoc parsing rules and embracing
> constructions like mstyle, mpadded in "proposed" profile.
> 
> _______________________________________________
> dev-tech-mathml mailing list
> dev-tech-mathml@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-mathml
>

Received on Tuesday, 3 October 2006 20:54:29 UTC