Regarding EPUB3, I don't think anyone said the whole format should be supported natively in browsers. An EPUB file is basically just a set of HTML5 pages (HTML, SVG, MathML and CSS) packed into an archive, together with additional metadata to describe the ebook content (title, author, chapters, pages etc). So browsers are already able to render ebook pages as long as they support HTML5 and you don't need to build a Javascript rendering engine. Of course, the most obvious method to extend HTML5 with metadata is to use an XML format for the whole ebook (XHTML5 mixed with the ebook metadata using namespaces) but again you should not focus on the syntax ; another (non-XML) SGML format could have been used instead...
The key idea is that mobile devices are using Web rendering engines and that Web formats are well-adapted to render documents on the screen, so relying on HTML5 is the most appropriate choice. Gecko is already able to render and edit HTML5 and as a consequence some Gecko-based applications exist to render or edit ebooks (see e.g. the EPUBReader Firefox add-on or BlueGriffon EPUB Edition). On the other hand, most mobile devices are currently WebKit-based and so the rendering quality of mathematical formulas is not very good at the moment. That's why EPUB folks are complaining about the lack of MathML support in browser rendering engines. All the communication around FirefoxOS has been to say that it relies entirely on HTML5 and open standards, as opposed to competitors. So the point is that if Gecko enters the market of mobile devices its good MathML support could be a competitive advantage when presented to EPUB companies that publish mathematical content (education, research , engineering etc) or to users likely to read such ebooks. Of course, this can be generalized to other math applications, not only ebook readers. It seems that Benoit thought that MathML was not used at all and could easily be dropped or replaced. As others have tried to explain that's not true and there are already many concrete projects that have been developed for 15 years, several places where MathML plays a key role and many people keeping asking for MathML support in browsers. Certainly LaTeX can be parsed into a tree for WYSIWYG edition, we can convert ASCIIMath directly to HTML+CSS or accessibility tools could perhaps even read a formula without building a tree at all. But we don't care here since we are talking about the Web and about Gecko-based applications so we want to have an SGML format, a DOM, compatibility with all the HTML5 family and build tools on top of that. There are MathML-based projects to address the needs mentioned in this thread and there are already many pages with MathML content on the Web. So there is no reason to replace MathML by something that will help for the simplest cases (already addressed by existing tools as I said above) but won't work in general and will break all existing MathML contents and projects. The main remaining issue is the lack of browser support so dropping MathML from Gecko would definitely be the wrong choice and a very negative signal to the Web community, especially since one of the argument given is that Gecko should follow what Blink does. Mozilla should be prude to have had volunteers involved in MathML projects during all these years and see that as a benefit. Fortunately, I see that the majority of comments in this thread go in that direction. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
