RE: MathML-in-HTML5

This all sounds vaguely familiar. When MathML (and Mozilla) were new,
many of us argued for MathML support in Mozilla's HTML parser for many
of the same reasons I see here. We were told by the Mozilla chieftains
that this would only happen over their dead bodies and that XHTML was
the only way we were going to get MathML support. Perhaps it did take us
7 years to get IE to work with a XHTML+MathML but IE has also had a
solution for MathML embedded in HTML for even longer. 

While Microsoft may have (nasty) business reasons for not supporting
XHTML, they may also have made the argument that the world wasn't ready
to change all their pages into XHTML just for some gain in "purity".
Sounds like some people on this list are coming around to that same
point of view.

So, as I posted a week ago, why not adopt the Microsoft convention for
embedding MathML (or any other XML language) in HTML? Minus the COM
class id stuff, of course. Basically, this would result in a simple
declaration of the embedded language's namespace. For the reasons stated
earlier, just <math> is not enough. At a minimum, it doesn't allow for
smooth transitions to new versions of MathML. Come on, Microsoft isn't
wrong all the time.

Paul Topping
Design Science

> -----Original Message-----
> From: dev-tech-mathml-bounces@lists.mozilla.org 
> [mailto:dev-tech-mathml-bounces@lists.mozilla.org] On Behalf 
> Of Roger B. Sidje
> Sent: Monday, October 02, 2006 10:48 PM
> To: White Lynx
> Cc: www-math@w3.org; dev-tech-mathml@lists.mozilla.org
> Subject: 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
> > 
> _______________________________________________
> 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 06:28:06 UTC