Benoit Jacob wrote: > Can we focus on the other conversation now: should the Web have a > math-specific markup format at all? I claim it shouldn't; I mostly > mentioned TeX as a "if we really wanted one" side note and let it go > out of hand. > > How many specific domains will want to have their own domain-specific > markup language next? Chemistry? Biology? Electronics? Music? Flow > charts? Calligraphy?
I hope that all those subjects develop their own domain-specific markup languages. In fact, many of them have: there's MusicXML for Music, and OpenType for caligraphy, for example. Things that can help people convey the true meaning of information to each other and that can give machines the necessary assistance to understand that information are generally good. I think the more important issue is whether browsers should have built-in support for all these things. I think we should make the platform flexible enough and powerful enough that web pages can render, edit, and manipulate the information without any built-in knowledge of the markup from the browser. However, unless/until we ship that, I don't think there should be a rush to remove MathML. I mean no disrespect to the people who worked on pdf.js, but I have to admit that many frustrating experiences with pdf.js have convinced me that it is even more important than I originally thought to get people publishing scientific and technical writing *natively* in HTML as soon as possible. Simply, we are not "there" yet as far as "render and edit it with your own JS code" goes. Until we are "there," IMO we have to get the web publishing content natively in HTML. That means we should be aiming for high-fidelity (perfect) and high-performance dvi-to-html (and even docx-to-html and xslx-to-html) conversion at a minimum. (For all the good things about pdf.js, "high fidelity" and "high performance" do not describe it, in my experience.) > start saying "no", and at that point, the exception made for math > will seem unjustified. I think eventually we could say the same thing about SVG (why not just have JS code render Adobe Illustrator drawings using canvas or even WebGL?) and quite a few other things we've built into the platform. We definitely should do what you suggest and improve the core parts of the platform to make such specialized built-in interpreters unnecessary. But, that seems quite far off; we want the web platform to be competitive with various native apps sooner than we can demonstrate success with that strategy. > If tomorrow a competing browser solves these problems, and renders > MathJax's HTML output fast, we will obviously have to follow. That > can easily happen, especially as neither of our two main competitors > is supporting MathML. Sure. Nobody's arguing that we shouldn't make MathJax fast. I would argue, though, that we shouldn't remove MathML until there's a viable (equally-usable, equally-round-trippable, equally-performing) replacement. > School children are only on the reading end of math typesetting, so > for them, AFAICS, it doesn't matter that math is rendered with MathML > or with MathJax's HTML+CSS renderer. School children traditionally have been on the reading end of math typesetting because they get punished for writing in their math books. However, I fully expect that scribbling in online books will be highly encouraged going forward. School children are not going to write MathML or TeX markup. Instead they will use graphical WYSIWYG math editors. The importance of MathML vs. alternatives, then, will have to be judged by what those WYSIWYG end up using. WYSIWYG editing of even basic wiki pages is still almost completely unusable right now, so I don't think we're even close to knowing what's optimal as far as editing non-trivial mathematics goes. Cheers, Brian _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
