On Mon, May 6, 2013 at 10:52 AM, Benoit Jacob <jacob.benoi...@gmail.com>wrote:
> 2013/5/5 Robert O'Callahan <rob...@ocallahan.org> > >> I would also say that one big difference between MathML and a >> hypothetical TeX-based format is that MathML has a DOM and it's not clear >> how to fit TeX into a DOM. That may not matter much for rendering, but it >> does if you want to support editing. >> > > That sounds interesting; could you please expand a little more? > - Do you mean that in order to support editing well, the format must be > naturally parseable into a tree representation? (Why so?) > We expose HTML and SVG content to Web applications by structuring that content as a tree and then exposing it using standard DOM APIs. These APIs let you examine, manipulate, parse and serialize content subtrees. They also let you handle events on that content. CSS also depends on content having a DOM tree structure for selectors and inheritance to work. You definitely need to able to handle events and apply CSS to elements of your math markup. I mentioned editing because I thought you'd want to reuse DOM text node editing in a MathML editor. Introducing a new kind of document markup that can't be manipulated via DOM APIs is a non-starter. And of course, once you've figured out how to expose math content in a DOM API, people are going to expect the source language to use HTML-like angle-bracket syntax like everything else that parses to a DOM. Rob -- q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q" _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
