Re: We should drop MathML
Let me go on a bit of a rampage about TeX for a bit. TeX is not a markup format. It is an executable code format. It is a programming language by design! (It's a very poor programming language, but let's ignore that for the moment.) You run a TeX program to generate the rendered output. This has some major implications: -- It's very hard to write a universal WYSIWYG editor. While I was still in research I tried various WYSIWYG TeX editors. They all sucked because it's an intractable problem. That's not a problem for programmers, mathematicians and scientists who are used to writing everything in plaintext with emacs. It is for everyone else. -- You have an edit/compile/debug cycle and your Tex can fail with compilation/runtime errors. Catastrophic fail document content models (like XML) really suck for Web content. (Yes, MathML is XML, but people can and should use the HTML embedding which avoids this problem.) (Because I like WYSIWYG and I don't like edit/compile/debug cycles and TeX is atrocious as a language, I tried to avoid it in my research. I published a POPL paper full of type theory written in Mircrosoft Word (which is totally unheard of), and wrote my thesis which also include a lot of semantics and type theory in FrameMaker, which was actually pretty good but is very dead. (I had an officemate who wrote his thesis in Scribe, which was very dead even in the mid-90s!)) You could try to fix TeX's problems in a new math language, but computer scientists have been talking about that for decades and nobody has. Of course, computer scientists and mathematicians would probably continue to prefer a Turing-complete language, which is fine for them but again, not suitable for normal users for the above reasons. And of course, to the extent you change TeX, you break compatibility with TeX, which is much of its appeal in the first place. 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
Re: We should drop MathML
On Mon, May 6, 2013 at 6:14 PM, Robert O'Callahan rob...@ocallahan.orgwrote: wrote my thesis which also include a lot of semantics and type theory in FrameMaker, which was actually pretty good but is very dead. Correction: it's alive! Amazing. 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
Re: We should drop MathML
On Monday, 6 May 2013 07:27:41 UTC+2, p.kraut...@gmail.com wrote: Microsoft indeed remains a mystery. Not so much when it comes to Microsoft Office: http://blogs.msdn.com/b/murrays/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: We should drop MathML
On 05/06/2013 05:46 AM, Benoit Jacob wrote: Let me just reply to a few points to keep this conversation manageable: 2013/5/5 p.krautzber...@gmail.com Here are a couple of reasons why dropping MathML would be a bad idea. (While I wrote this others made some of the points as well.) * MathML is part of HTML5 and epub3. That MathML is part of epub3, is useful information. It doesn't mean that MathML is good but it means that it's more encroached than I knew. We don't care about this is part of HTML5 arguments (or else we would support all the crazy stuff that flies on public-fx@w3...) We do care about the stuff what is in the HTML spec. http://www.whatwg.org/specs/web-apps/current-work/#mathml (and if there is something we don't care about, it should be removed from the spec) * Gecko has the very best native implementation out there, only a few constructs short of complete. * Killing it off means Mozilla gives up a competitive edge against all other browser engines. * MathML is widely used. Almost all publishers use XML workflows and in those MathML for math. Similarly, XML+MathML dominates technical writing. * In particular, the entire digital textbook market and thus the entire educational sector comes out of XML/MathML workflows right now. * MathML is the only format supported by math-capable accessibility tools right now. * MathML is just as powerful for typesetting math as TeX is. Publishers have been converting TeX to XML for over a decade (e.g., Wiley, Springer, Elsevier). Fun fact: the Math WG and the LaTeX3 group overlap. * Limitations of browser support does not mean that the standard is limited. From a MathJax point of view * MathJax uses MathML as its internal format. * MathJax output is ~5 times slower than native support. This is after 9 years of development of jsmath and MathJax (and javascript engines). JavaScript performance hasn't stopped improving and is already far better than 5x slower than native on use cases (like the Unreal Engine 3 demo) that were a priori much harder for JavaScript. * The performance issues lie solely with rendering MathML using HTML constructs. * Performance is the only reason why Wikipedia continues to uses images. Then fix performance? With recent JavaScript improvements, if you really can't get faster than within 5x of native, then you must be running into a browser bug. The good thing with rendering with general HTML constructs is that improving performance for such use cases benefits the entire browser. If you pit browsers against each other on such a benchmark, you should be able to generate enough competitive pressure between browser vendors to force them to pay attention. * JavaScript cannot access font metrics, so MathJax can only use fonts we'r able to teach it to use. Has that issue been brought up in the right places before (like, on this very mailing list?) Accessing font metrics sounds like something reasonable that would benefit multiple applications (like PDF.js). * While TeX and the basic LaTeX packages are stable, most macro packages are unreliable. Speaking as a mathematician, it's often hard to compile my own TeX documents from a few years ago. You can also ask the arXiv folks how painful it is to do what they do. I'm also speaking as a (former) mathematician, and I've never had to rely on TeX packages that aren't found in every sane TeX distribution (when I stopped using TeX on a daily basis, TexLive was what everybody seemed to be using). But that's not relevant to my proposal (or considering a suitable subset of TeX-plus-some-packages) because we could write this specification in a way that mandates support for a fixed set of functionality, much like other Web specifications do. Personal remarks MathML still feels a lot like HTML 1 to me. It's only entered the web natively in 2012. We're lacking a lot of tools, in particular open source tools (authoring environments, cross-conversion, a11y tools etc). I'm concerned everytime I hear native as an inherent quality. As I tried to explain above, if something can be done in browsers without native support, that's much better. The job of browser vendors is to be picky gatekeepers to limit the number of different specialized things that require native support. Whence my specific interest in MathJax here. But that's a bit like complaining in 1994 that HTML sucks and that there's TeX which is so much more natural with \chapter and \section and has higher typesetting quality anyway. It would have been extremely easy to rebut such arguments as irrelevant and counter them by much stronger arguments why TeX couldn't do the job that HTML does. I am still waiting for the rebuttal of my arguments, in the original email in this thread, about how TeX is strictly better than MathML for the particular task of representing equations. As far as I can see, MathML's only inherent claim to existence is it's XML, and being XML stopped being a relevant
Re: We should drop MathML
Thanks Peter: that point-for-point format makes it easier for me to understand your perspective on the issues that I raised. 2013/5/6 p.krautzber...@gmail.com Benoit, you said you need proof that MathML is better than TeX. I think it's the reverse at this point (from a web perspective -- you'll never get me to use Word instead of TeX privately ;) ). Anyway, let me try to repeat how I had addressed your original points in my first post. 1.1. you make a point against adding unnecessary typography. Mathematics is text, but adding new requirements. It's comparable to the introduction of RTL or tables much more than musical notation. It's also something that all school children will encounter for 9-12 years. IMHO, this makes it necessary to implement mathematical typesetting functionality. 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. 1.2 you claimed MathML is inferior to TeX. I've tried to point out that that's not the case as most scientific and educational publishers use it extensively. 1.2.1 you claimed TeX is the universal standard. I've tried to point out only research mathematicians use it as a standard. Almost most mathematics happens outside that group. I suppose that I can only accept your data as better documented that mine; most of the TeX users I know are or have been math researchers. 1.2.2 You pointed out that MathML isn't friendly to manual input. That's true but HTML isn't very friendly either, nor is SVG. It's not comparable at all. If you're writing plain text, HTML's overhead is limited to some br or p tags, with maybe the usual b, i, heading... so the overhead is small compared to the size of your text. If you add many anchors and links, and some style, the overhead can grow significantly, but is hardly going to be more than 2 input lines per output line. With MathML, we're talking about easily over 10 input lines per output line --- in wikipedia's example, MathML has 30 where TeX has 1. So contrary to HTML, nobody's going to actually write MathML code by hand for anything more than a few isolated equations. Thanks also for your other points below, to which I'm not individually replying; we have a perspective mismatch here, so it's interesting for me to understand your perspective, but I'm not going to win a fight against the entire publishing industry which you say is already behind MathML. Benoit 1.2.3 You argued TeX is superior for accessibility. I've pointed out that that's not the case given the current technology landscape. 2 You wrote now is the time to drop MathML. I've tried to point out that now -- as web and ebook standard -- is the time to support it, especially when your implementation is almost complete and you're looking to carve a niche out of the mobile and mobile OS market, ebooks etc. 2.1 you claim MathML never saw traction outside of Firefox. I tried to point out that MathML has huge traction in publishing and the educational sector, even if it wasn't visible on the web until MathJax came along. Google wants MathML support (they just don't trust the current code) while Apple has happily advertised with the MathML they got for free. Microsoft indeed remains a mystery. 2.2 you claim MathJax does a great job -- ok, I'm not going to argue ;) -- while browsers don't. But we've used native output on Firefox before MathJax 2.0 and plan to do it again soon -- it is well implemented and can provide the same quality of typesetting. 3. Well, I'm not sure what to say to those. If math is a basic typographical need, then the syntax doesn't matter -- we need to see it implemented and its bottom up layout process clashes with CSS's top down process. No change in syntax will resolve that. Since MathML development involved a large number of TeX and computer algebra experts, I doubt a TeX-like syntax will end up being extremely different from MathML the second time around. Instead of fighting over syntax, I would prefer to focus on improving the situation of mathematics on the web -- so thank you for your offer to support us in fixing bugs and improving HTML layout. Peter. On Sunday, 5 May 2013 20:23:56 UTC-7, Joshua Cranmer wrote: On 5/5/2013 9:46 PM, Benoit Jacob wrote: I am still waiting for the rebuttal of my arguments, in the original email in this thread, about how TeX is strictly better than MathML for the particular task of representing equations. As far as I can see, MathML's only inherent claim to existence is it's XML, and being XML stopped being a relevant selling point for a Web spec many years ago (or else we'd be stuck with XHTML) Don't be quick to dismiss the utility of XML. The problem of XHTML, as I understand it, was that the XHTML2 spec ignored the needs of its would-be users and designed stuff that was
Re: We should drop MathML
2013/5/6 Robert O'Callahan rob...@ocallahan.org Let me go on a bit of a rampage about TeX for a bit. TeX is not a markup format. It is an executable code format. It is a programming language by design! Yes, but a small subset of TeX could be purely a markup format, not a programming language. Just support a finite list of common TeX math operations, and no custom macros (or very restricted ones). Benoit ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: We should drop MathML
On Mon, May 06, 2013 at 07:27:08AM -0400, Benoit Jacob wrote:
2013/5/6 Robert O'Callahan rob...@ocallahan.org
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 guess I don't see the usefulness of allowing to apply style to individual
parts of an equation --- applying a single style to an entire equation
would be plenty enough as far as I can see.
Stupid example that can be useful:
style
.sqrt { color: red }
.sqrt * { font-style: italic; color: black }
/style
pA square root is denoted by mathmsqrt
class=sqrtmrowa/mrow/msqrt/math, where the radical sign, or
radix, is the symbol in red./p
Regarding editing, if I understand correctly, you have WYSIWYG or other
kinds of fancy editing in mind, where understanding of the syntax tree
inside of the equation is needed; I haven't seen a need for WYSIWYG editing
of math
seriously? I was a very happy user of the MS Word Equation Editor when I
was in high school.
Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: We should drop MathML
On 5/6/13 7:27 AM, Benoit Jacob wrote: I guess I don't see the usefulness of allowing to apply style to individual parts of an equation Styling parts of an equation with different colors can be _extremely_ useful for readability. It's rarely done in print, of course, and I assume there are various reasons ranging from it's more expensive to no one does that for why. But on the web it seems like a no-brainer. Styling parts of an equation with different font styles is of course all over the place; there are lots of TeX packages that will let you do things like \mathfrak, for example. Of course fraktur in particular got stuck into Unicode... There are some interesting use cases I can think of for scripted visibility styling in educational materials. Regarding editing, if I understand correctly, you have WYSIWYG or other kinds of fancy editing in mind, where understanding of the syntax tree inside of the equation is needed; I haven't seen a need for WYSIWYG editing of math I think this goes back to roc's point about current TeX workflows being ok for specialists (maybe; I have in fact wished for a good wysiwyg editor for TeX on many an occasion, but was always stymied by the need for custom macros for my documents), but most people _do_ in fact want wysiwyg editing. It's not fancy for most people but a baseline requirement. So any system for math on the web needs to have support for that requirement... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: We should drop MathML
On 5/6/2013 6:27 AM, Benoit Jacob wrote: I guess I don't see the usefulness of allowing to apply style to individual parts of an equation --- applying a single style to an entire equation would be plenty enough as far as I can see. Suppose you were writing an introductory explanation course, where you were explaining the derivation of a complex formula step-by-step. You could illustrate the changes in each step with a different color. You could also use strike through text formatting to clearly indicate. Regarding editing, if I understand correctly, you have WYSIWYG or other kinds of fancy editing in mind, where understanding of the syntax tree inside of the equation is needed; I haven't seen a need for WYSIWYG editing of math, but I don't want to try to fight the war for or against WYSIWYG. I would wager that the majority of HTML content in the wild is not written by people who write HTML in a text editor but by people who use some sort of WYSIWYG tool or document format conversion--I'm including subsets like email and E-PUB here. Also, this strikes me as very biased towards the frame of mind that real mathematicians use TeX--I was introduced to the Equation Editor in Microsoft Office more or less as part of the regular course of study, long before I was introduced to TeX in any form. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: We should drop MathML
I don't have time to respond right now, but regarding the accessibility, mathematics is also more complex in that case too. Basically the two use cases are I'm aware of are - For blind people or other visual disabilities, speech synthesizer must follow the MathSpeak rules. Simply reading the text normally, e.g. of a LaTeX or ASCII source, is ambiguous. - For people with reading disabilities (dyslexia etc), you need to synchronize highlight of equation parts / reading of equation parts. In both cases, you must know a bit more about the mathematical structure e.g. to have a DOM. It's not clear how to do that with plain text. It's just absurd to believe that putting TeX source inside the alt text of an img makes the formula accessible. It might works for very simple equations like x+2 but in general you'll have to do some parsing into an abstract representation if you want to read/highlight it correctly. With MathML you already have a standard representation and there already exist tools to work with that language. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Stylesheet loaded from privileged channel does not trigger content policy for subresources
On Thursday, May 2, 2013 1:40:37 AM UTC+1, Boris Zbarsky wrote: Yes. Content policy checks are skipped when the loader has system principal. Thanks. Seems like I need to be more selective about when to give the channel the system principal. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: We should drop MathML
On Monday, 6 May 2013 14:12:48 UTC+1, Trevor Saunders wrote: On Mon, May 06, 2013 at 08:24:07AM -0400, Boris Zbarsky wrote: I am still waiting for the rebuttal of my arguments, in the original email in this thread, about how TeX is strictly better than MathML for the particular task of representing equations. How easy is it to build an accessibility application on top of TeX, or even a restricted subset of it? Note that these exist for MathML, but not so much for TeX. I actually think it would be easier to map tx math into the accessibility APIs we support than mathml. There are several problems/issues here: # Context How do you differentiate/identify math powers (e.g. a^2), footnotes (e.g. some text^1) and code (int c = a^b;)? With MathML markup, you have clearly identified what the content of the document/sub-tree is. # Parsing With a TeX-like format, a speech synthesiser/screen reader/web browser would need to write a parser for that format. With MathML, the parsing is already handled by the SGML/XML/HTML5 parser so the application can process it via DOM/SAX/a reader API. currently we don't expose mathml at all other than as a an object that we say is an equation, and its not really clear how to fix that with mathml. This is enough information for the screen reader/speech synthesiser to know that it has MathML content, and thus walk the MathML DOM to read the math out loud. It should also be enough to query associated CSS styles to handle any Aural CSS or CSS Speech styles associated with the MathML. Another important consideration is existing web content. If you are going to start rendering text that has e.g. a^2 as math, then all documents that use that, e.g. pYou can use a^b in TeX to denote 'a raised to the bsupth/sup power'./p - Reece ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Storage in Gecko
On Mon, May 06, 2013 at 09:41:08AM -0700, David Dahl wrote: KyotoCabinet might make a good backend for a new storage API: http://fallabs.com/kyotocabinet/ It's released under the GPL, so it's MPL-incompatible, if I understand correctly. As for the Kyoto Products Specific FOSS Library Linking Exception, at http://fallabs.com/license/linkexception.txt -- it currently lists exactly one library (not us) and seems to indicate that, even if Gecko were so listed, a Specific Library that re-exports Kyoto Cabinet's functionality to other applications would not be allowed. --Jed (not a lawyer) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: We should drop MathML
On Mon, May 06, 2013 at 11:30:51AM -0700, mscl...@googlemail.com wrote: On Monday, 6 May 2013 14:12:48 UTC+1, Trevor Saunders wrote: On Mon, May 06, 2013 at 08:24:07AM -0400, Boris Zbarsky wrote: I am still waiting for the rebuttal of my arguments, in the original email in this thread, about how TeX is strictly better than MathML for the particular task of representing equations. How easy is it to build an accessibility application on top of TeX, or even a restricted subset of it? Note that these exist for MathML, but not so much for TeX. I actually think it would be easier to map tx math into the accessibility APIs we support than mathml. There are several problems/issues here: # Context How do you differentiate/identify math powers (e.g. a^2), footnotes (e.g. some text^1) and code (int c = a^b;)? the same way the tx parser does, though that would be a problem for the API consumer to deal with not us. With MathML markup, you have clearly identified what the content of the document/sub-tree is. # Parsing With a TeX-like format, a speech synthesiser/screen reader/web browser would need to write a parser for that format. With MathML, the parsing is already handled by the SGML/XML/HTML5 parser so the application can process it via DOM/SAX/a reader API. which has just changed the problem from parsing text to parsing a tree of objects. currently we don't expose mathml at all other than as a an object that we say is an equation, and its not really clear how to fix that with mathml. This is enough information for the screen reader/speech synthesiser to know that it has MathML content, and thus walk the MathML DOM to read the math out loud. It should also be enough to query associated CSS styles to handle any Aural CSS or CSS Speech styles associated with the MathML. No it is not. Ignoring various evil things we'd really rather they didn't do they can't touch the DOM itself. Another important consideration is existing web content. If you are going to start rendering text that has e.g. a^2 as math, then all documents that use that, e.g. pYou can use a^b in TeX to denote 'a raised to the bsupth/sup power'./p I don't think anyone is suggesting that because it obviously would break existing pages, instead we'd have to do something like pthis is some text with an equation txx = 2y/tx/p Trev - Reece ___ 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
Re: We should drop MathML
On 5/6/2013 2:12 PM, Benoit Jacob wrote: How many specific domains will want to have their own domain-specific markup language next? Chemistry? Biology? Electronics? Music? Flow charts? Calligraphy? MathML specifies mathematical formulae, which is not domain-specific, and is itself a building block for other fields as well. Looking at the other fields: Chemical formulas of course can use MathML, and drawing chemical structures is best built on SVG. Note that even practitioners in the field are used to basically building these structures with tools like ChemDraw, which can be thought of as a specialized SVG tool. I don't know what biology can specify, but I don't think there's much that they couldn't solve without basic 2D and 3D graphics. Electronics' circuit diagrams are easily just a set of macros on top of SVG, as are music and flow charts. I haven't read the source code of MathJAX, but the fact that it isn't a straight TeX-to-HTML one-pass converter is to me a good sign that MathML expresses stuff that is not reliably expressible in HTML. I suspect that when people start asking for that, we'll quickly have to start saying no, and at that point, the exception made for math will seem unjustified. If no one's asking for the other things, then it's not an issue. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: We should drop MathML
2013/5/6 Joshua Cranmer pidgeo...@gmail.com On 5/6/2013 2:12 PM, Benoit Jacob wrote: How many specific domains will want to have their own domain-specific markup language next? Chemistry? Biology? Electronics? Music? Flow charts? Calligraphy? MathML specifies mathematical formulae, which is not domain-specific, and is itself a building block for other fields as well. Looking at the other fields: Chemical formulas of course can use MathML, and drawing chemical structures is best built on SVG. Note that even practitioners in the field are used to basically building these structures with tools like ChemDraw, which can be thought of as a specialized SVG tool. I don't know what biology can specify, but I don't think there's much that they couldn't solve without basic 2D and 3D graphics. Electronics' circuit diagrams are easily just a set of macros on top of SVG, as are music and flow charts. Of course not; just like math, music will want a higher level of abstraction that's not directly tied to graphical rendering, like a set of SVG macros would be. In fact, http://en.wikipedia.org/wiki/MusicXML And in fact... http://en.wikipedia.org/wiki/List_of_XML_markup_languages Benoit I haven't read the source code of MathJAX, but the fact that it isn't a straight TeX-to-HTML one-pass converter is to me a good sign that MathML expresses stuff that is not reliably expressible in HTML. I suspect that when people start asking for that, we'll quickly have to start saying no, and at that point, the exception made for math will seem unjustified. If no one's asking for the other things, then it's not an issue. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist __**_ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/**listinfo/dev-platformhttps://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rendering meeting, May 6, 2:30 PM US/Pacific
Friendly Reminder: Gecko Rendering (Layout, GFx, Media) meeting Today, May 6, 2:30 PM US/Pacific --Jet - Original Message - From: Benoit Jacob jacob.benoi...@gmail.com To: dev-platform dev-platform@lists.mozilla.org, dev-plann...@lists.mozilla.org planning dev-plann...@lists.mozilla.org Sent: Friday, May 3, 2013 8:14:32 PM Subject: Rendering meeting, May 6, 2:30 PM US/Pacific Hello, The next Rendering meeting will take this Monday May 6 at 2:30 PM US/Pacific time. That could be Tuesday in your timezone. The Rendering meeting is about all things Gfx, Image, Layout, and Media. It is expected to take place roughly every second Monday. Please first add your agenda items there: https://wiki.mozilla.org/Platform/GFX/2013-May-6 * Every second Monday at 2:30 PM Pacific Time * +1 650 903 0800 x92 Conf# 99366 * +1 416 848 3114 x92 Conf# 99366 * +1 800 707 2533 (pin 369) Conf# 99366 (toll free, Skype) * Video (Vidyo) link: https://v.mozilla.com/flex.html?roomdirect.htmlkey=vu1FKlkBlT29 * Vidyo room 9366 (if you have LDAP and can log in at https://v.mozilla.com) See you, Benoit ___ 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
Re: We should drop MathML
On Tue, May 7, 2013 at 7:12 AM, Benoit Jacob jacob.benoi...@gmail.comwrote: How many specific domains will want to have their own domain-specific markup language next? Chemistry? Biology? Electronics? Music? Flow charts? Calligraphy? This is a good question to ask, but I think it would help if there are specific vocabularies we can use as examples. I think we can safely say that mathematics is a more compelling domain for Web content than all those other domain. For years we've had a MathML WG in the W3C and as far as I know, none of those other domains have ever wanted a WG at the W3C --- at least, they haven't had one. Likewise we've had and still have a lot of people pushing for browser support for math, and I haven't ever noticed anyone pushing for browser support for those other domains. I think you can also look at Wikipedia and see a lot of use of math, but relatively little use of content in those other domains. Probably because math is a much more general tool than those other domains. Another thing to consider is how amenable to automatic layout/presentation a particular XML vocabulary is. I know good automatic music layout is very difficult. For flow-charts, and I suspect chemistry, it is too. For biology I don't even know what the browser would do. If there's no known good automatic layout algorithm then obviously browser rendering of content doesn't make much sense. One domain you didn't list where I *have* seen pressure for built-in browser support is maps. Some people want to extend SVG with features to support maps, so a browser can just render a map without specialized Web app support. I don't think that is a good idea because good map layout algorithms are really difficult (e.g. placing labels). Also, mapping applications invariably have a lot of functionality that wouldn't make sense to add to the browser --- direction finding, for example --- so it's hard to imagine users wanting to use maps outside of the context of some Web application. There's almost no benefit to anyone supporting maps outside the context of a mapping Web application. 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
Re: We should drop MathML
Hopefully Web Components will provide a good solution to let authors extend the browser with support for vocabularies that can be rendered via a straightforward decomposition to HTML or MathML or SVG. I think the layout requirements of MathML are too onerous for MathML to be reduced to HTML or SVG that way. While diagrams such as chemical formulae, flowcharts or electronics schematics can be compiled to SVG, the layout step is very much nontrivial and I don't think Web Components is enough for that. Web Components plus some JS to do the layout is probably satisfactory. 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
Follow-up: Using an inbound2 branch as a hot spare for mozilla-inbound
It seems from the previous thread on this topic that there is enough support for the idea to at least proceed with a trial to see how an inbound2 would function in practice. For this reason, RelEng will be configuring the cypress project branch for this purpose and we will begin using it per the previous proposal once it is ready. We will also create a wiki page documenting the process for transplanting a patch per the conversations in the previous thread. I will update this thread once the branch is ready and documented. Thank you for all your feedback in the previous thread! -Ryan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: We should drop MathML
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
Re: smartmake-like functionality has landed in mach
On 05/05/2013 09:07 PM, Felipe Gomes wrote: Is the idea of smartmake to make things also work for non-toplevel folders? For example, if I edit .cpp only in content/base/src, it should be enough to rebuild that and toolkit/library. However, `mach build content/base/src` won't add toolkit/library in that case. I think this would be a nice use case to cover for the workflow of: - enter folder - make changes to files - `mach build .` In any case, I filed bug 868880 to include some of the browser/app dependencies into smartmake. I thought at one point I had longest substring matching in smartmake, but the details are fuzzy. It feels like it should be fine to take the dependency that is the longest substring match of the target and start building from there, which would avoid the need to add browser/devtools/* to the dependency list. Cheers, Josh ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: smartmake-like functionality has landed in mach
On 13-05-06 9:03 PM, Josh Matthews wrote: On 05/05/2013 09:07 PM, Felipe Gomes wrote: Is the idea of smartmake to make things also work for non-toplevel folders? For example, if I edit .cpp only in content/base/src, it should be enough to rebuild that and toolkit/library. However, `mach build content/base/src` won't add toolkit/library in that case. I think this would be a nice use case to cover for the workflow of: - enter folder - make changes to files - `mach build .` In any case, I filed bug 868880 to include some of the browser/app dependencies into smartmake. I thought at one point I had longest substring matching in smartmake, but the details are fuzzy. It feels like it should be fine to take the dependency that is the longest substring match of the target and start building from there, which would avoid the need to add browser/devtools/* to the dependency list. I commented on Bug 868880 to this effect, but: what if the longest substring is /? Then we're forcing a top-level build. Or we're special casing directories at the root (which I suppose we already are, since |mach build| and |mach build DIR| do different things). Personally, adding browser/devtools/* to the dependency list prompts us developers to externalize our knowledge of the dependencies not captured by the current build system, which seems like an artifact we will appreciate in the future. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
