2013/5/28 Henri Sivonen <hsivo...@hsivonen.fi> > On Fri, May 24, 2013 at 4:33 PM, Benoit Jacob <jacob.benoi...@gmail.com> > wrote: > > I also thought that it was obvious that a suitably chosen subset of TeX > > could be free of such unwanted characteristics. > > So basically that would involve inventing something new that currently > does not exist and are currently isn't supported by Gecko, Trident, > Blink or WebKit. Furthermore, to integrate properly with the platform, > math should have some kind of DOM representation, so a TeX-like syntax > would still need to parse into something DOMish. >
Note that I only brought up the TeX-like-syntax point to show that _if_ we really wanted to do something like MathML, we could have at least have gotten a language with less awkward syntax. (People have argued that MathML was no worse than HTML, but it is very much worse: it is as verbose as if, to write text in HTML, one had to enclose each syllabe and each punctuation or whitespace character in a separate HTML element). "Parsing into a syntax tree" is not an exclusive property of XML; heck, even C++ parses into a syntax tree. "Parsing into something DOMish" is a stronger requirement to place on a language; it is true that a TeX-like syntax would be at a disadvantage there, as one would need to come up with an entirely new syntax for specifying attributes and applying CSS style. When I started this thread, I didn't even conceive that one would want to apply style to individual pieces of an equation. Someone gave the example of applying a color to e.g. a square root sign, to highlight it; I don't believe much in the pedagogic value of this kind of tricks --- that sounds like a toy to me --- but at this point I didn't want to argue further, as that is a matter of taste. So at this point I conceded the TeX point (that was a few dozen emails ago in this thread) but noted that regardless, one may still have a very hard time arguing that browsers should have native support for something as specialized as MathML. More discussion ensued. There really are two basic reasons to support MathML in the browser that have been given in this thread: 1. It's needed to allow specifying CSS style for each individual piece of an equation. (It's also been claimed to be needed for WYSIWYG editing, but I don't believe that part, as again, having a syntax tree is not a special property of XML). 2. It's needed to support epub3 natively in browsers. I don't have much to answer to that as the whole epub thing was news to me: I thought that we were only concerned with doing a Web rendering engine, it turned out that Gecko is rather a Web *and epub* rendering engine. If I understand correctly, the only reason to give epub this special treatment whereas we happily implement our PDF viewer in JavaScript only, is that epub happens to be XHTML. That sounds like XHTML is a sort of trojan horse to introduce native support for all sorts of XML languages (like, here, MathML) into Gecko, but whatever --- I've had enough fighting. Benoit > > On the other hand, presentation MathML is already mostly supported by > Gecko and WebKit, parses into a DOM (from text/html, too) and has had > years of specification development behind it to figure out what the > sufficiently expressive feature set is. > > So instead of being in the point where there's a mature spec and two > of the four engines still to go, we'd go back to zero engines and no > spec. > > Presentation MathML may not be pleasant to write by hand, but we don't > put a Markdown parser in the browser, either, for those who don't like > writing HTML. (And we don't put a JIT for $LANGUAGE for those who > don't want JS.) Those who rather write Markdown can run the conversion > on their server. Likewise, those who rather write a subset of TeX can > run itex2mml on their server. > > -- > Henri Sivonen > hsivo...@hsivonen.fi > http://hsivonen.iki.fi/ > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
