Re: We should drop MathML

[Phillip Rhodes]

Yeah, somebody shared the link with me and I didn't notice the date.
My bad.   That said, I'm glad to hear that Firefox isn't seriously
considering dropping MathML!


Phil

This message optimized for indexing by NSA PRISM


On Wed, Feb 15, 2017 at 2:00 PM, Jonathan Kingston
 wrote:
> Hi Phil,
>
> I'm going to say this isn't a plan I am aware of (the email you responded to
> is pretty old and no know progression since then).
>
> Various bugs are still being raised about modern MathML support (stylo is a
> new integration of servo's CSS rendering as part of the quantum project -
> https://wiki.mozilla.org/Stylo)
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1339711
>
> Secondly when working on a pref for the tor patch uplift to Firefox there
> wasn't a notion that we should be removing MathML at all:
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1173199
>
> This change is just for Tor users who wish to increase their privacy by
> removing a library which has known fingerprinting and exploits in the past.
>
> Thanks
> Jonathan
>
>
> On Wed, Feb 15, 2017 at 4:51 PM,  wrote:
>>
>> On Sunday, May 5, 2013 at 11:38:39 AM UTC-4, Benoit Jacob wrote:
>> > Hi,
>> >
>> > Summary: MathML is a vestigial remnant of the XML-everything era, and we
>> > should drop it.
>> >
>>
>> This is one of the worst ideas I've ever heard floated around Mozilla,
>> dating back to the days when releases were numbered M1, M2 and so on.
>> MathML support is basically the ONLY regard in which Firefox has any real
>> differentiator between itself and the rest of the browsers out there.
>> Choosing to support MathML is one of the few examples of the Mozilla
>> leadership group displaying any real vision and choosing to lead, rather
>> than follow, in the browser market.  If you drop MathML support, I say you
>> might as well just cancel the Firefox project altogether.
>>
>>
>> Phil
>> ___
>> 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

[Jonathan Kingston]

Hi Phil,

I'm going to say this isn't a plan I am aware of (the email you responded
to is pretty old and no know progression since then).

Various bugs are still being raised about modern MathML support (stylo is a
new integration of servo's CSS rendering as part of the quantum project -
https://wiki.mozilla.org/Stylo)
  https://bugzilla.mozilla.org/show_bug.cgi?id=1339711

Secondly when working on a pref for the tor patch uplift to Firefox there
wasn't a notion that we should be removing MathML at all:
  https://bugzilla.mozilla.org/show_bug.cgi?id=1173199

This change is just for Tor users who wish to increase their privacy by
removing a library which has known fingerprinting and exploits in the past.

Thanks
Jonathan


On Wed, Feb 15, 2017 at 4:51 PM,  wrote:

> On Sunday, May 5, 2013 at 11:38:39 AM UTC-4, Benoit Jacob wrote:
> > Hi,
> >
> > Summary: MathML is a vestigial remnant of the XML-everything era, and we
> > should drop it.
> >
>
> This is one of the worst ideas I've ever heard floated around Mozilla,
> dating back to the days when releases were numbered M1, M2 and so on.
>  MathML support is basically the ONLY regard in which Firefox has any real
> differentiator between itself and the rest of the browsers out there.
> Choosing to support MathML is one of the few examples of the Mozilla
> leadership group displaying any real vision and choosing to lead, rather
> than follow, in the browser market.  If you drop MathML support, I say you
> might as well just cancel the Firefox project altogether.
>
>
> Phil
> ___
> 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

[motley . crue . fan]

On Sunday, May 5, 2013 at 11:38:39 AM UTC-4, Benoit Jacob wrote:
> Hi,
> 
> Summary: MathML is a vestigial remnant of the XML-everything era, and we
> should drop it.
> 

This is one of the worst ideas I've ever heard floated around Mozilla, dating 
back to the days when releases were numbered M1, M2 and so on.   MathML support 
is basically the ONLY regard in which Firefox has any real differentiator 
between itself and the rest of the browsers out there.  Choosing to support 
MathML is one of the few examples of the Mozilla leadership group displaying 
any real vision and choosing to lead, rather than follow, in the browser 
market.  If you drop MathML support, I say you might as well just cancel the 
Firefox project altogether.  


Phil
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[peter . krautzberger]

 Actually, MS is very clear on their position on MathML in Internet Explorer: 
 http://status.modern.ie/mathml?term=mathML

Well, status.modern.ie was published about a year after my message.

Curiously enough, according to 
http://blogs.msdn.com/b/murrays/archive/2014/04/27/opentype-math-tables.aspx IE 
uses LineServices which can render MathML just fine.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[storey . david]

On Sunday, May 5, 2013 10:27:41 PM UTC-7, p.kraut...@gmail.com wrote:
 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.

Actually, MS is very clear on their position on MathML in Internet Explorer: 
http://status.modern.ie/mathml?term=mathML
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[richardbrucebaxter]

You guys should not be considering dropping MathML, not unless you want to hold 
back the next generation of Wikipedia (mathematical formulae hyperlinks)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[Marcio Galli]

I am not following this thread as I should; however a contributor from
the Brazil community list was talking/planning a talk to the major
conference in Brazil - about MathML. Since he is a 'mozillian, I have
asked him to go through this whole thread and try to distill.

And he did digging work based in this thread:

http://blog.rgaiacs.com/2014/02/16/why_mathml.html

If you have any notes, I appreciate, sending directly for him can also
be motivating. Or sending to me I will be happy to distill some input
too, pass along etc.

m
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[Dāvis Mosāns]

What? Drop MathML? :| Is this some troll... it can't be serious. This is the 
most stupidest, retarded idea I've heard.

MathML works perfectly, it's been W3C standard for ages. Dropping it would be 
like dropping CSS. Think about the Web...

By the way I love XHTML :)
XHTML+CSS+JS+SVG+MathML = 
http://davispuh.github.io/Source-Code/Languages/XHTML.xhtml

Also another example http://davispuh.github.io/Source-Code/Languages/XML.xml 
there that km^2 is rendered using MathML which you can found in 
http://davispuh.github.io/Source-Code/Languages/XSL.xsl

It will work fine even without JavaScript.

I created these a while ago to test syntax highlight for IDEs, so take a look 
at source code.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[Mike Hoye]

On 2/11/2014, 10:19 AM, Dāvis Mosāns wrote:

What? Drop MathML?
While you're not doing much to endear anyone to your position here, my 
understanding is that we're not dropping MathML and we'll still take 
patches from people who'd like to improve it.



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[zweigmedia]

I am an educator struggling to incorporate mathematics in my online tutorials 
and mathematical games etc. I cannot use MathJax: It is asynchronous, and my 
code, which requires generating HTML and typeset mathematical formulas on the 
fly, would cease to function under MathJax unless I was to discard years of 
work and start all over again restructuring all my code to accommodate 
asynchronous math typesetting. Instead, I have been forced to write my own 
(very inferior) synchronous Tex to HTML converter for the MathML-illiterate 
browsers. For Firefox, I just use TeX to MathML and get perfectly good and 
pleasing typeset formulas synchronously. 

A lot of people are claiming that the existence of MathJax makes MathML 
unnecessary. However, no mention is made of the important fact that MathJax is 
asynchronous, so that it cannot be used in place of MathML in dynamic pages 
without fundamental restructuring of the code.

As things stand, Firefox is the only browser that admits native, synchronous 
mathematical typesetting. Worse, there is nothing even remotely comparable (and 
synchronous) for other browsers (Safari, for instance, claims to support MathML 
but the support is marginal and far from satisfactory).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[Boris Zbarsky]

On 5/28/13 8:22 AM, Benoit Jacob wrote:

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.


Note that I've seen at least one PhD dissertation that made good use of 
color to highlight which terms of a 2-page-long equation canceled each 
other to produce the final (much shorter; iirc it was 0) result.


Of course that was in the PDF version; the print version had to be 
black-and-white, and was a lot harder to follow.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[fred . wang]

I think the main points were:

1) Not everybody use TeX as an input method.
2) Not everybody write the source of Web pages by hand.
3) People using TeX want its full power (defining macros, loading packages etc).

So except in simple and limited cases, a small subset of TeX is not what people 
want. MathML already contains the core features for mathematical rendering and 
has been widely used for a long time. Concrete tools have been developed and 
shown that MathML can be used with other Web languages (HTML, SVG and CSS), 
with DOM/Javascript, to write mathematical search engines, can be generated 
from AsciiMath, can be used for accessibility (*), in WYSIWYG editor, in 
ebooks, for copy and paste (e.g. Microsoft Word, Mathematica/Mapple), in 
publishers's internal workflow etc For the LaTeX community, tools like LaTeXML 
(currently able to convert 94% of the arXiV papers) have shown that MathML can 
be generated from LaTeX and that the annotation element can even be used to 
expose and share the original LaTeX markup (e.g. for copy and paste).

So your proposal of a small subset of TeX is mostly (depending on what you put 
exactly in the subset and how you map it to the DOM tree) a syntactical change, 
just like the RelaxNG XML form vs the RelaxNG compact form. As I said, I 
understand this can be helpful when one wants to quickly write a HTML page with 
math content and Javascript libraries like MathJax or AsciiMath have already 
addressed that need. With non-XML/SGML syntax, you're just making more 
difficult for authors/implementers to understand what will be the DOM tree you 
get at the end. So you're making life easier for people writing their Web pages 
by hand with no CSS or Javascript involved, but much more complicated in all 
the other cases. You claimed that MathML was not used and that replacing it by 
the more universal TeX syntax would make developing tools easier (like 
accessibility or copy and paste) while things that do not work well with TeX 
(like CSS) were not absolutely necessary. That just seemed misinfor
 mation about the current status of MathML and current use cases. You asked 
advice about the usefulness of MathML on the MathJax list and we tried to 
explain that it is indeed very important. Of course TeX is important too, but 
is not always adapted to a Web context (remember it was initially designed by 
Knuth to write books). As I said, I would prefer improving MathML, especially 
compatibility with CSS, than starting again from zero with a new math language 
for the Web and reinventing the wheel.

(*) BTW, ChromeVox has recently been released with MathML support. So Google 
can now read the math but not display it: 
http://www.youtube.com/watch?v=YyWu9HB9QtU
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[Gervase Markham]

On 04/06/13 23:30, Jonas Sicking wrote:
 It would be cool to find a solution that makes the simple things
 simpler than MathML, while keeping the complicated things possible.

Isn't the answer to that sort of question normally something like: a
mini-language for simple math, plus a JS library you can include which
will automatically turn it into MathML?

And lo, there was ASCIIMath:
http://www1.chapman.edu/~jipsen/mathml/asciimath.html

Gerv


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[fred . wang]

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

Re: We should drop MathML

[Benoit Jacob]

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

Re: We should drop MathML

[Benoit Jacob]

Hi Isaac,

What I meant by matter of taste is that while some people find advanced
presentation styles, such as the one you mention, useful, other people find
them to be just toys. I belong to the latter category, but have no hope of
convincing everyone else of my views, so I'd rather just call it a matter
of taste.

If you asked me about my views on these matters (I have taught mathematics
for a few years), I would tell you that math symbolic formalism is
overrated in the first place and is given an excessive role in math
teaching; I would say that math teaching should focus on conveying
underlying concepts, which in most areas of math are geometric in nature,
and that once the student has a grasp of how things work on a geometric
level, the formalism isn't anymore a major impediment to understanding; and
that therefore, focusing on cool presentation features to ease algebra
teaching is like treating only the symptoms of a poor approach to math
teaching. You mention Fourier transforms: that is a prime example of
something that has formulas that may seem intimidating to students until
they understand the basic idea, at which point the formulas become almost
trivial. However, by expanding on all these things, I would be completely
off-topic on this list ;-)

Benoit


2013/5/28 Isaac Aggrey isaac.agg...@gmail.com

 Hi Benoit,

  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.

 I think there is tremendous value in styling individual pieces of an
 equation, especially in educational settings, but its application is
 largely unexplored.

 For example, this image [1] breaks down a Fourier Transform in such a
 way that makes the equation more approachable rather than a sea of
 symbols (see [2] for entire blog post). I can't help but get excited
 thinking about applications in future online courses (MOOCs [3]) that
 use interactive equations along with frameworks like Popcorn.js [4] to
 create a more dynamic learning experience.

 [1]: http://altdevblogaday.com/wp-content/uploads/2011/05/DerivedDFT.png
 [2]:
 http://www.altdevblogaday.com/2011/05/17/understanding-the-fourier-transform/
 [3]: https://en.wikipedia.org/wiki/Massive_open_online_course
 [4]: http://popcornjs.org/


 - Isaac

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[Henri Sivonen]

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.

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

Re: We should drop MathML

[Henri Sivonen]

On Mon, May 6, 2013 at 1:52 AM, Benoit Jacob jacob.benoi...@gmail.comwrote:

 2013/5/5 Robert O'Callahan rob...@ocallahan.org One other thing: EPUB
 publishers are screaming for good math support for
  textbooks (and currently that means they want MathML). They're mostly
  Webkit-based, and maybe we don't care about them, but there you are.
 

 Given that TeX is already the standard in scientific publishing, I would
 find it very surprising if they complained about a TeX-based or TeX-like
 format !


TeX is a programming language and, in practice, running the program results
in a rigid PDF. For the Web, we need something that can dynamically reflow
to different viewports and integrate with CSS layout. MathJax or Web
Components involve the publisher sending a program along with a supposedly
declarative representation, so as a whole, it's again like sending a
program, because you have to run the program to be sure about what the
declarative input really results.

EPUB publishers want something that is declarative and reflows to viewport
width. Presentation MathML is that and it doesn't make sense to start over.

These days, it's fashionable to rely on JavaScript and to treat
downloadable EPUB files as an anachronism in an always-online world, but
there's still value in being able to represent content in a way that can be
reflown, edited, copied and pasted instead of only being rendered by a
program supplied by the publisher. After all, we have all this CSS stuff
for non-mathematical text instead of each site sending over an
emscripten-compiled typesetter that paints the image of text onto canvas.

Although math doesn't have the same mass-market appeal as text in general,
math is pretty important for humanity, so I think it makes sense to keep
the way to handle mathematical text in a way that's analogous with other
text in browsers (declarative, reflowable, has a DOM) and endeavor to get
Wikipedia to actually use it by default so that Chrome and IE would have
compatibility pressure from a ridiculously mainstream site even if not from
its most mainstream articles.

(Compared to music and flowcharts, math has a greater need to integrate
with line layout instead of working as an image-like region, so it makes
less sense to use SVG. As for chemistry, presentation MathML probably
serves chemistry pretty well, too.)

-- 
Henri Sivonen
hsivo...@hsivonen.fi
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[Neil]

Even Raymond Chen wants better MathML support?

http://blogs.msdn.com/b/oldnewthing/archive/2013/05/08/10416823.aspx#comments
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[fred . wang]

* About the XML is evil, MathML is XML so MathML is evil syllogism.

I don't think it makes sense in general to say that something is good or bad 
without mentioning for what purpose. I actually agree with Joshua that XML is a 
good format to work with for a computer engineer. There are very good libraries 
and tools to handle it and things like XML namespaces that are painful on the 
Web become very important for these tools. roc is right that the catastrophic 
fail is certainly not good for a Web model. Note however that most of the Web 
sites are automatically generated by server side programs and I often see 
MYSQL, PHP, CGI etc failures without hearing anyone saying they should come 
back to static pages. The HTML5 parsing rules allow to get concision and 
error-tolerance when you want to quickly write pages but this tag-soup 
approach also brings confusion in general and is just useless for programming. 
The inclusion of MathML inside HTML5 removed the XML burden that prevented 
people to use it on the Web or in emails where the default content 
 is text/html. Actually the syntactic difference has never been a problem for 
MathJax or WYSIWYG tools (working on a DOM-like tree) or for authoring tools 
like LaTeXML (that generates XML from LaTeX and then only uses XSLT stylesheets 
at the final step to convert to EPUB, XHTML or HTML5). Perhaps one of the best 
argument against the XML-haters is that Henri Sivonen's HTML5 validator is 
itself heavily based on XML tools like RELAX NG schemas or Java XML-related 
libraries.

* About the MathML is too specialized.

Obviously I agree with what has been said before about math being in particular 
position. I personally see mathematical writing as language by itself and so 
not having it in the browsers is just like not supporting Arabic or Asian 
scripts (BTW MathML was implemented in Gecko a long time before HTML ruby). 
Just to add one point: mathematical expressions are also very often mixed with 
other content like text or diagrams and it makes sense to have 
HTML+SVG+MathML+CSS well integrated together.

* About the TeX is already the universally adopted standard and  TeX is very 
friendly to manual writing.

Again, people have already said that this is not true, at least not outside 
academia (I personally use TeX too as an input method but don't want to impose 
that to other people and I'm open to use other methods like handwritting 
recognition in the future). One of the most popular question on the MathJax 
list is of course is there a WYSIWYG math editor? Many people also like the 
ASCII-like syntax: (x^2 + y_1)/2. For example MathJax supports that syntax, 
Daniel Glazman has a plugins for BlueGriffon  Thunderbird and this is commonly 
used in Computer algebra systems. Some people say (cf jqMath or MathEL) that 
with tools to replace the traditional keyboard, entering Unicode characters 
becomes easy and so they generalize to a Unicode-based simple syntax where you 
write the actual symbol rather than commands like \Leftrightarrow. Even modern 
LaTeX environments support Unicode. Finally, people are also interested in 
handwritting recognition (see e.g. https://www.youtube.com/watch?v
 =26opB8DRf3c or http://webdemo.visionobjects.com/portal.html). 

* About the TeX can be nearly trivially read aloud.

This is an assumption but the reallity is that math accessibility tools would 
need a parsing into an abstract representation at some point anyway. Just 
reading the plain text source naively is not enough for the two use cases I 
mentioned. There are already MathML-based tools showing that it is possible to 
use MathML.

* About MathML never saw much traction outside of Mozilla

If you are only talking about browser vendors then that's true. But Web users 
have requested MathML support for a long time (remember that the Web was 
created at the CERN for research purpose) and has been implemented in Gecko and 
Webkit by volunteers. MathJax is yet another community effort to bring math on 
the Web and was initially presented to me by Robert Miner as a transition 
technology towards MathML in browsers. At the last W3C workshop on ebook, 
everybody complained about the lack of MathML support in layout engines (Gecko 
being excluded de facto for now) and this leads to serious discussions inside 
the MathJax consortium about how we could help implementing MathML in browsers 
(hopefully the MathJax team will be able to say more about that later). Other 
people also indicate other domain where MathML is now used. BTW, you probably 
don't care either about that argument, but MathML is part of the OpenDocument 
OASIS/ISO/IEC standard used in OpenOffice and other office s
 oftware suite.

[digression: Mozilla people keep saying that competition is good. That was 
certainly true when Mozilla was fighting against Internet Explorer predominance 
and stagnation in Web innovation. But to be honest, it seems that what's 
happening now is that Google is leading the 

Re: We should drop MathML

[Mihai Sucan]

Hello everyone!

This thread has raised my attention and I would like to share my 
opinions, maybe as a school child who used mathematical software for 
WYSIWYG editing (not only reading!), as the primary way of editing any 
math, as a primary/fundamental tool for computer-aided learning. I was 
(un)lucky enough to be forced by my situation to learn using *only* 
computers in the late 1990s and early 2000s. That experience has taught 
me the importance of WYSIWYG editing for HTML and maths.


I feel it's not easy to me to reply to this thread - seeing other people 
who are technical experts that I admire have already replied, providing 
proper arguments for their reasoning. Please excuse my, perhaps, less 
formal, less backed-by-arguments reply.


This thread shows that there's some misunderstanding on the performance, 
styling and editing requirements for math. I can say that I spent months 
trying software to find the best one fitting my requirements. It wasn't 
easy.


I haven't seen good (La)TeX WYSIWYG editors, but lately I haven't tried 
any such software - now I write LaTeX manually. Still, in the early 
2000s I did see and use one WYSIWYG editor that was really good: 
Wolfram's Mathematica. It had fast rendering, good set of keyboard 
editing shortcuts allowing fast input in WYSIWYG mode. Really good math 
WYSIWYG editing is very much possible.


Performance matters not only for the initial document rendering. When 
you do WYSIWYG editing performance characteristics matter in a lot more 
subtle ways. When you are editing big equations, or some really big 
document updates need to happen as close as possible to instant. I have 
tested software like MathCAD and Maple that did not seem slow at all 
when loading documents. Editing math, however, proved to be quite slow. 
Very good editing is *not* about click and point - this was one of the 
biggest failures of MathCAD's UI: it encouraged the click-and-point 
editing which meant you had to switch between the keyboard and the mouse 
all the time. Word 97 (before Word 2007) forced you to manually switch 
between the equation editor and the normal editor, which was a huge 
problem, and so on.


Styling is really important when you collaborate with others and you 
need to highlight relevant parts of the math output. I am surprised this 
is even put up as discussion.


Similarly I am surprised that the need for WISYWG editing for math is 
being discussed. I am being subjective here: I believe that mathematics 
should be first-class citizen on the web. Mathematics is a fundamental 
domain of study in all schools, in all forms of education throughout the 
world. Mathematics is the basis for many other fields, see physics, 
computer science and others.


Back in those days when I was writing math homeworks with Mathematica I 
was very glad and I appreciated a lot that people write software that 
can benefit my niche needs, it was invaluable for me. It made possible 
things that were not possible. Microsoft's Word was not even close to 
being as usable as Wolfram's software. Word 2007 has, indeed, improved 
math editing a *lot*, today it's certainly usable.


Microsoft's work on improving math editing in Word shows there's a real 
demand for math in documents. I don't see why we would believe otherwise 
about the web. We should not need to include half-baked* JS libs to 
render math in a document.


* I'm not claiming that MathJax is half-baked - I am simply pointing out 
that once people have the choice of which JS lib to use for math 
rendering they may (and will) fail to pick the best one.


I do not care about the technology here - MathML or TeX. What I care 
about is for the web browsers to meet the technical demands for 
producing really good math rendering and editors. I want this not for 
the academics, not for professors who can write TeX documents. I want 
this for school children who cannot write math on paper, who are blind, 
or who have other physical disabilities. Manually writing LaTeX does not 
cut it at early stages, when children learn maths. Such tools are 
invaluable for them.


At the moment, removing MathML support from Gecko would make it harder 
for web app developers to create (really) good software for math 
editing. It may certainly have its problems, but its benefits are 
greater. Before MathML is removed people should look into defining the 
requirements, the APIs needed to be implemented in the browser such that 
JS-based math rendering can be equally fast and versatile (eg. styling). 
Font metrics stuff is, I believe, only a part of the problem that makes 
JS-based math rendering slower than native. After requirements are 
defined, those things should be implemented. After that, yes, remove MathML.


Back in the days when I was testing math software, I was also testing 
MathML rendering in Gecko - it was slower than in specialized software. 
I don't know how it is today, but keep in mind that native software like 
Maple and 

Re: We should drop MathML

[Benjamin Smedberg]

On 5/6/2013 7:20 PM, Robert O'Callahan wrote:

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.
I'd like understand more about this. I have been hoping that one of the 
best use cases for web components is to implement these kinds of 
domain-specific languages. I greatly fear that we're accidentally 
pushing the web from declarative markup to a model where everything is 
controlled with script: in the process, we are going to lose some of the 
core benefits of the web: pervasive hyperlinking, save-as and 
view-source, and . I tend to think that web components are a great way 
to abstract away the presentation of new declarative languages.


Without knowing a lot about it, it seems that SVG and HTML contain all 
of the primitives necessary for a web components script to implement the 
visual MathML presentation. Perhaps I'm not completely aware of the 
problems, though. Does MathML need to participate in inline reflow in a 
way that requires direct support from the layout engine?




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.

Unless I misunderstand web components, they are primarily blobs of 
script, and I'm really hoping they will be able to implement arbitrary 
new markup languages. I think there's a lot more that we can add to 
components, especially for nonvisual presentations (better 
implementation of accessibility and audio presentations seem like 
near-term goals).


That still leaves us with future decisions about whether we should build 
any of these markup languages into the browser. It seems clear from epub 
that there is a demand for declarative math markup, and whether we build 
that using web components or directly into our layout engine, it should 
be a core markup language of the web.


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[fred . wang]

On Tuesday, May 7, 2013 4:11:22 PM UTC+2, fred...@mathjax.org wrote:
 I use many long inline formulas in my blog and this is handled as I would 
 like by Gecko. 

sorry I meant this is *not* handled
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[Marcio Galli]

 I'm coming late to this thread but I have to say that the misunderstanding 
 present in the original post is huge. The author can take refuge in that he's 
 made a common category mistake. MathML is a computer representation for math, 
 TeX is a human input language.

 MathML was never intended to be typed by humans so it is no wonder that you 
 find it a bad experience. TeX is a poor computer representation which is one 
 reason why MathML was invented.

 It is reasonable to have a discussion of the relative merits of entering math 
 by typing TeX vs point-and-click editing of math (ie, direct manipulation 
 editing). I am biased toward the latter but I can understand the feelings of 
 those whose hands know TeX really well.
 In short, both MathML and TeX have good reasons to exist and don't compete 
 with each other in their primary categories.

I am also late in this thread, and I incline to this point and I see
the original author frustration as a valid discussion — not sure under
this one.

But I wanted to present another problem which is in a way of the same
nature (has also a degree of separation). It's the development of
tableless grids against HTML.

Consider the case, table A, which a developer can think of:

4 columns:
abcd
ebfd

To to this in HTML, the developer has to make a container DIV with 4
main column cells in it, think c1,c2,c3,c4. And which c1=rows a,e;
c2=row b; c3=rows cf; c4=row d;

It's easier to type something like the following:

4,abcdebfd

But this won't change the reality, the end product of this is:

divdiv class='inline'a /e //divdiv class='inline'b
//divdiv class='inline'c /f //divdiv class='inline'd
//div/div

Which, can be , as many pointed: styled, channeled to accessibility
observers, manipulated, annotated — all of of that with a greater
level of compatibility as developers understand.

But then, right now, what we have are:

a) Toolkits using JS to do things like 4,abcdebfd [1]

  a.1) For example, http://labs.telasocial.com/grid-layout/

b) Specs do to similar things:

   b.1) http://dev.w3.org/csswg/css-template/#grid-shorthand

The above example, which refers to grid rearrangement, is a different
things I know. But I think it has similar points to this discussion:
shorthands that applies to HTML elements (or other elements) are good
things to developers.

m
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[fred . wang]

 I'd argue that any machine parsable format can't be ambiguous by virtue
 of the fact machines parse it.  However in any case AtkText /
 IAccessibleText / the mac accessible protocol thing all expect the text
 for an object to be a string so whatever format the web uses screen
 readers will be handling a serialized format.
 

Sorry I was not clear here. Concretely, if {x+1}/2 is read x plus one over 
2, it's ambiguous since that could also mean x + 1/2.  Blind people have 
standard rules to clarify reading of mathematical expressions and screen 
readers must follow these rules. That's not necessarily the order people 
usually read a formula. And reading opening brace x plus closing brace slash 
two is not what they want either. So at some point, someone will have to parse 
and understand the mathematical structure. That's essentially what MathPlayer 
and a MathJax extension prototype do from the MathML tree. I guess at the end 
they will send text strings to the reader anyway.

  - For people with reading disabilities (dyslexia etc), you need to 
  synchronize highlight of equation parts / reading of equation parts.
 this should actually work quiet naturally in my proposal since we can
 tell API consumers that the bounds of characters in the serialized text
 are those for the formatted text shown on screen.  That doesn't quiet
 work for  { / } / ^ etc, but we can just give them a size of zero or
 something, and that should probably be fine.

It seems that you are oversimplifying the issue here. First people proposing an 
alternative syntax will still need to define a mapping from the text source to 
the visual 2D representation if you want to know which part to highlight. For 
MathML it's the normal mapping from DOM to the rendering tree in Gecko but it's 
not clear what Benoit wants to use instead since without further info it seems 
that the DOM will just have a text node. Next, what you suggest seem to only 
work for variable names and it's not clear how you'll read e.g. operators or 
square roots. IIRC, to read a fraction the tools I mention highlight the 
numerator when they read it, then the whole fraction's bounding box when they 
read the over, then the denominator when they read it. Or perhaps they 
highlight the whole fraction before, I don't remember exactly but the point is 
that it's not limited to text. I admit that I don't know the details but there 
are other similar sync rules between highlight and reading
 . Also, I hope you realize that mathematical layout is much more complex than 
just fractions and scripts so I don't think one can just say I guess that will 
work for such a nontrivial problem.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[pault]

Math accessibility is a surprisingly complex subject. How math should be read 
is dependent on the mathematical or scientific context in which the math is 
embedded, the educational level of the user, and their familiarity with the 
accessibility technology itself. In our grant work with the Educational Testing 
Service (ETS) we found out that a literal reading of a mathematical expression 
in a test question can give away the answer even when the graphical rendering 
doesn't. 

BTW, all this work is done with math expressed in MathML. It could use MathML 
structures obtained from MathJax but this means that the screen reader can't 
use MSAA (or equivalent) to get an IAccessible interface from a DOM node. As 
far as I know, there is no mechanism that allows JavaScript code to implement 
IAccessible.

Even with MathML implemented natively in browsers, it seems like accessibility 
mechanisms still need some work. While the HTML5 effort is busy adding access 
to device features (phone, camera, GPS, touch) for us in web apps, there has 
been no effort to do something similar for screen readers and for accessibility 
support in general. Screen reader vendors are currently being cut out of the 
mobile market as device makers are playing the old proprietary that 
functionality is part of the OS game.

I guess I am going a bit far afield here. My hope was to show that there is a 
lot happening with MathML technology. It is not time to pull the plug but 
properly support it.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[Robert O'Callahan]

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

[Robert O'Callahan]

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

[papalowa]

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

[smaug]

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

[Benoit Jacob]

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

[Benoit Jacob]

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

[Mike Hommey]

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

[Boris Zbarsky]

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

[Joshua Cranmer ]

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

[fred . wang]

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: We should drop MathML

[msclrhd]

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: We should drop MathML

[Trevor Saunders]

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

[Joshua Cranmer ]

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

[Benoit Jacob]

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: We should drop MathML

[Robert O'Callahan]

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

[Robert O'Callahan]

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

Re: We should drop MathML

[Brian Smith]

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: We should drop MathML

[Justin Lebar]

Four points here.

1. We're assuming that MathJax is as good with MathML as it is without
it, but perhaps we could ask the MathJax folks to comment on whether
this is true.  I'd certainly be a lot more comfortable dropping MathML
if the MathJax folks said there was no point.

2.

 A suitable subset of TeX (not
 the entirety of TeX, as that is a huge, single-implementation technology
 that reputedly only Knuth ever fully understood) was the right choice all
 along

Jonathan Kew is a much better person to comment on this, but in my
relatively limited experience typesetting documents in TeX, I've had
to use various LaTeX packages (particularly amsmath and amssymb) in
order to get all of the symbols and so on that I needed.  I suspect
that heavy users of TeX frequently need more than these two
packages.

The point being, a subset of TeX isn't necessarily sufficient.

3. It's not clear to me why we should go through all the work of
rewriting MathML into this TeX thing unless we thought that the new
thing would see more enthusiastic adoption.  It sounds like you would
probably agree on this point.

4.

 2.2. High-quality mathematical typography in browsers is now possible,
 without using MathML. Examples include MathJax ( http://www.mathjax.org/ ),
 which happily takes either TeX or MathML input and renders it without
 specific browser support, and of course PDF.js which is theoretically able
 to render all PDFs including those generated by pdftex. Both approaches
 give far higher quality output than what any current MathML browser
 implementation offers.

Could you elaborate on how MathML is inferior to MathJax's HTML+CSS
rendering?  MathJax has a page where you can switch between different
rendering modes, and to my eyes, the two modes are almost identical.
The only difference I see is that the HTML+CSS mode is better at
correctly sizing large parentheses and radicals, but I wouldn't call
this far higher quality.

http://www.mathjax.org/demos/mathml-samples/

On Sun, May 5, 2013 at 11:38 AM, Benoit Jacob jacob.benoi...@gmail.com wrote:
 Hi,

 Summary: MathML is a vestigial remnant of the XML-everything era, and we
 should drop it.

 ***

 1. Reasons why I believe that MathML never was a good idea. Summary:
 over-specialized and uniformly inferior to the pre-existing,
 well-established standard, TeX.

1.1. MathML is too specialized: we should be reluctant to have a
 separate spec for every kind of specialized typography. What if musicians
 wanted their own MusicML too?

1.2. MathML reinvents the wheel, poorly. A suitable subset of TeX (not
 the entirety of TeX, as that is a huge, single-implementation technology
 that reputedly only Knuth ever fully understood) was the right choice all
 along, because:

   1.2.1. TeX is already the universally adopted standard --- and
 already was long before MathML was invented. Check for yourself on
 http://arxiv.org/ , where most new math papers are uploaded --- pick any
 article, then other formats, then Source: you can then download TeX
 sources for almost every article.

   1.2.2. TeX is very friendly to manual writing, being concise and
 close to natural notation, with limited overhead (some backslashes and
 curly braces), while MathML is as tedious to handwrite as any other
 XML-based format. An example is worked out at
 http://en.wikipedia.org/wiki/MathML#Example_and_comparison_to_other_formats,
 where the solution to the quadratic equation is one line of TeX versus
 30
 lines of MathML!

   1.2.3. An important corollary of being very close to natural notation
 is that TeX can be nearly trivially read aloud. That means that it offers
 a particularly easy accessibility story. No matter what mechanism is used
 to graphically display equations, providing the TeX source (similarly to
 images alt text) would allow anyone to quickly read it themselves without
 any kind of software support; and screen reading software could properly
 read equations with minimal TeX-specific support code. For example, TeX
 code such as \int_0^1 x^2 dx can be readily understood by any human with
 basic TeX exposure (which is nearly 100% of mathematicians) and can be
 easily handled by any screen reader that knows that \int should be read as
 integral and that immediately after it, _ and ^ should be read as from
 and to respectively.

 ***

 2. Reasons why even if MathML had ever been a decent idea, now would be the
 right time to drop it. Summary: never really got traction, and the same
 rendering can now be achieved without MathML support.

2.1. MathML never saw much traction outside of Mozilla, despite having
 been around for a decade. WebKit only got a very limited partial
 implementation recently, and Google removed it from Blink. The fact that it
 was just dropped from Blink says much about how little it's used: Google
 wouldn't have disabled a feature that's needed to render web pages in the
 real world. Opera got an implementation too, but Opera's engine has been

Re: We should drop MathML

[Benoit Jacob]

2013/5/5 Justin Lebar justin.le...@gmail.com

 Four points here.

 1. We're assuming that MathJax is as good with MathML as it is without
 it, but perhaps we could ask the MathJax folks to comment on whether
 this is true.  I'd certainly be a lot more comfortable dropping MathML
 if the MathJax folks said there was no point.


Absolutely, feedback from the MathJax team would be very valuable here.



 2.

  A suitable subset of TeX (not
  the entirety of TeX, as that is a huge, single-implementation technology
  that reputedly only Knuth ever fully understood) was the right choice all
  along

 Jonathan Kew is a much better person to comment on this, but in my
 relatively limited experience typesetting documents in TeX, I've had
 to use various LaTeX packages (particularly amsmath and amssymb) in
 order to get all of the symbols and so on that I needed.  I suspect
 that heavy users of TeX frequently need more than these two
 packages.

 The point being, a subset of TeX isn't necessarily sufficient.


It is absolutely true that nearly all TeX documents include various
packages. So by TeX I implicitly meant TeX with a selection of stuff
from various usual packages.



 3. It's not clear to me why we should go through all the work of
 rewriting MathML into this TeX thing unless we thought that the new
 thing would see more enthusiastic adoption.  It sounds like you would
 probably agree on this point.


I absolutely agree. That is basically what I meant when I wrote that the
argument that MathML was over-specialized may well apply to a TeX-based
solution too (see the discussion at the end, comparing proposals 3.1 and
3.2).



 4.

  2.2. High-quality mathematical typography in browsers is now possible,
  without using MathML. Examples include MathJax ( http://www.mathjax.org/),
  which happily takes either TeX or MathML input and renders it without
  specific browser support, and of course PDF.js which is theoretically
 able
  to render all PDFs including those generated by pdftex. Both approaches
  give far higher quality output than what any current MathML browser
  implementation offers.

 Could you elaborate on how MathML is inferior to MathJax's HTML+CSS
 rendering?  MathJax has a page where you can switch between different
 rendering modes, and to my eyes, the two modes are almost identical.
 The only difference I see is that the HTML+CSS mode is better at
 correctly sizing large parentheses and radicals, but I wouldn't call
 this far higher quality.

 http://www.mathjax.org/demos/mathml-samples/


Sure, I loaded this page in two tabs and switched one to MathML to compare.
I used Firefox 23.0a1 linux 64bit (ubuntu 12.04 if that matters).

From a quick look, here is what stands out:
 1. the spacing looks weird in MathML mode in a few places, especially in
Definition of Christoffel Symbols: the dx^i at the denominator is
strangely far down, and the exponent (k) and subscript (im) in Gamma^k_{im}
also are placed surprisingly far away from the Gamma. (The subscript in
fact looks like there was no kerning there, as it is not placed any further
left than the exponent in the MathML version, while it is placed left of
the exponent in the HTML+CSS version, which looks better).
 2. in Gauss' Divergence Theorem, in the dS, the S is placed strangely
far away from the d, in the MathML version. That could again be explained
by absence of kerning.
 3. the square root in The Quadratic Formula does not extend any further
down than the text under it, in the MathML version. square root signs
usually extend a bit further down, as in the HTML+CSS version.
 4. the greek letters in MathML mode look weird, for example the pi in
Cauchy's Integral Formula looks like an uppercase pi (in smallcaps), the
mu in Standard Deviation looks strange too.

That may all sound very picky, but if you're going to try to convince the
scientific community to switch away from TeX, which gets all of this just
right, better make sure than the replacement looks as good!

Benoit



 On Sun, May 5, 2013 at 11:38 AM, Benoit Jacob jacob.benoi...@gmail.com
 wrote:
  Hi,
 
  Summary: MathML is a vestigial remnant of the XML-everything era, and we
  should drop it.
 
  ***
 
  1. Reasons why I believe that MathML never was a good idea. Summary:
  over-specialized and uniformly inferior to the pre-existing,
  well-established standard, TeX.
 
 1.1. MathML is too specialized: we should be reluctant to have a
  separate spec for every kind of specialized typography. What if musicians
  wanted their own MusicML too?
 
 1.2. MathML reinvents the wheel, poorly. A suitable subset of TeX (not
  the entirety of TeX, as that is a huge, single-implementation technology
  that reputedly only Knuth ever fully understood) was the right choice all
  along, because:
 
1.2.1. TeX is already the universally adopted standard --- and
  already was long before MathML was invented. Check for yourself on
  http://arxiv.org/ , where most new math papers are 

Re: We should drop MathML

[fred . wang]

I'm not sure if that's a joke or complete misinformation about the topic. But 
obviously the answer is that the MathML support must be preserved. The MathJax 
team is strongly in favor of native MathML implementation.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[Benoit Jacob]

It's not a joke.

Could you elaborate on this? In particular, as I wrote to the MathJax list,
I would be very interested in knowing what regressions the removal of
MathML would incur as far as MathJax is concerned.

Benoit


2013/5/5 fred.w...@mathjax.org

 I'm not sure if that's a joke or complete misinformation about the topic.
 But obviously the answer is that the MathML support must be preserved. The
 MathJax team is strongly in favor of native MathML implementation.
 ___
 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

[Wesley Johnston]

 1.2.2. TeX is very friendly to manual writing, being concise and
 close to natural notation, with limited overhead (some backslashes and
 curly braces), while MathML is as tedious to handwrite as any other
 XML-based format. An example is worked out at
 http://en.wikipedia.org/wiki/MathML#Example_and_comparison_to_other_formats,
 where the solution to the quadratic equation is one line of TeX versus
 30 lines of MathML!

This isn't exactly a fair comparison. I mean, its fair, but for equations of 
any complexity (i.e. things you wouldn't find in a high school text book) TeX 
can quickly become incredibly difficult (maybe more difficult than MATHML) to 
manage. Most people I know who use TeX regularly have developed fairly thick 
sets of macros to try and manage things.

 Given that TeX is already the standard in scientific publishing, I would
 find it very surprising if they complained about a TeX-based or TeX-like
 format !

I'm not sure this is true either. At least in the fields I was involved in 
(solid state phsyics), MS Word had established itself as a broader standard. 
That was primarily based on general ease of use and (more importantly?) ease of 
collaboration (i.e. we could easily share a real document back and forth that 
tracked changes/comments inside it). Using a version tracking system would have 
been interesting... but I wasn't aware of anyone doing it.

I always wanted to see MathML succeeded. There are plenty of things to complain 
about in the format, but I think most of its problems stemmed from a lack of 
implementations. It feels to me like another one of those technologies (like 
flexbox or web components) that people need to reinvent (with a few of the 
sharp edges rounded off) and try to sell as new. Until we have buy in from 
some other browser vendors on a new format though, I don't think I understand 
why we'd kill off something that 1.) works and 2.) AFAIK requires almost zero 
upkeep. Are teams spending a lot of time upkeeping MathML code?

- Wes
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[Benoit Jacob]

2013/5/5 Wesley Johnston wjohns...@mozilla.com

  1.2.2. TeX is very friendly to manual writing, being concise and
  close to natural notation, with limited overhead (some backslashes and
  curly braces), while MathML is as tedious to handwrite as any other
  XML-based format. An example is worked out at
 
 http://en.wikipedia.org/wiki/MathML#Example_and_comparison_to_other_formats
 ,
  where the solution to the quadratic equation is one line of TeX versus
  30 lines of MathML!

 This isn't exactly a fair comparison. I mean, its fair, but for equations
 of any complexity (i.e. things you wouldn't find in a high school text
 book) TeX can quickly become incredibly difficult (maybe more difficult
 than MATHML) to manage. Most people I know who use TeX regularly have
 developed fairly thick sets of macros to try and manage things.


Well, I have written hundreds of pages of TeX; for sure, some large
equations would expand over more than one line of TeX, but I can't remember
going over more than 5 lines of TeX source (without custom helper macros)
per actual line of output, that that would be a really unusual case ---
while the MathML example above has a ratio of 30 source lines to 1 output
line.

The fact that TeX furthermore allows macros shouldn't be considered proof
that it's particularly hairy --- it's just something that people do for
convenience/abstraction.

There _are_ very hairy things with TeX, but they are not so much with math
typography per se; instead, I'd say that TeX becomes hairy when one tries
to use it beyond its primary domain of application. For example, one can
draw diagrams, e.g. with the xypic package, and that can get really
cumbersome and inexpressive. But that's not part of what I was suggesting
could become part of the subset-of-TeX used to replace MathML.



  Given that TeX is already the standard in scientific publishing, I would
  find it very surprising if they complained about a TeX-based or TeX-like
  format !

 I'm not sure this is true either. At least in the fields I was involved in
 (solid state phsyics), MS Word had established itself as a broader
 standard. That was primarily based on general ease of use and (more
 importantly?) ease of collaboration (i.e. we could easily share a real
 document back and forth that tracked changes/comments inside it). Using a
 version tracking system would have been interesting... but I wasn't aware
 of anyone doing it.


Ouch. I am glad I didn't work in a field where MS Word was in use for
writing long and/or scientific documents.

At least for the more mathematical sciences (math, mathematical physics,
large parts of CS) I can say with confidence that TeX is ubiquitous.




 I always wanted to see MathML succeeded. There are plenty of things to
 complain about in the format, but I think most of its problems stemmed from
 a lack of implementations. It feels to me like another one of those
 technologies (like flexbox or web components) that people need to reinvent
 (with a few of the sharp edges rounded off) and try to sell as new. Until
 we have buy in from some other browser vendors on a new format though, I
 don't think I understand why we'd kill off something that 1.) works and 2.)
 AFAIK requires almost zero upkeep. Are teams spending a lot of time
 upkeeping MathML code?


We agree: it does sound fair to wait for either a replacement, or agreement
that no such technology is needed in browsers, or evidence that the
maintenance cost is significant, before taking any decision to drop MathML.

Benoit



 - Wes

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[p . krautzberger]

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.
* 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).
* The performance issues lie solely with rendering MathML using HTML 
constructs. 
* Performance is the only reason why Wikipedia continues to uses images.
* JavaScript cannot access font metrics, so MathJax can only use fonts we'r 
able to teach it to use.
* 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.

Other points

* MathML has never seen paid browser development. All work (save code review) 
has been done solely by unpaid volunteers. If Mozilla was paying even a part 
time developer, Firefox would have had complete support years ago.

* The same holds for Apple, Google and Microsoft. Yes, when you don't put any 
developers on the job, MathML implementations do not get better.

* Google is even silly enough to kick out a hugely improved (albeit partial) 
implementation instead of landing the patches that fix that one remaining 
security issue -- while Apple doesn't have any problems with the same code. 

* Firefox has shown how productive the feedback loop from a partial 
implementation can be, attracting a number of volunteers over the years, 
pushing it forward a little bit each time.

* MathML syntax is not as bad as people think but it takes getting used to 
(just like HTML). It's a bit like saying HTML is bad since markdown is much 
more human readable. Check out Dave Barton's jqmath, a serialization of MathML; 
with very little effort I find it as human readable as TeX.

* TeX is *not* the de-facto standard for math. It is the standard for 
researchers in mathematics and very few related fields. Most mathematical 
content is not created by researchers but by technical writers and in the 
educational sector. And again: most TeX gets converted to MathML in publishing 
workflows.

* MS Word and Libre Office produce MathML out of the box. 


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). 

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.

I'm totally for MusicML! More generally, there are things like CellML, CML and 
other scientific standards. I'd encourage them to work towards becoming web 
standards, to prove that the web is truly the native place for all human 
communication.

A statistical plot has no more reason to be an image than an equation -- it 
should be markup/data in the page and the browser should render it. Browsers 
may be the new printing press, but we are looking at Gutenberg's model here, 
not 20th century digital offset printing.


Anyway, the MathWG has fought extremely hard for 15 years to make mathematics a 
first class citizen on the web. Certainly, MathML is only the beginning for 
math on the web. But abandoning it now will throw scientific content back 20 
years. 

Personally, I don't want to wait for another Knuth to show up and fix the 
problem.


Peter.


On Sunday, 5 May 2013 16:40:30 UTC-7, Benoit Jacob  wrote:
 2013/5/5 Wesley Johnston wjohns...@mozilla.com
 
 
 
   1.2.2. TeX is very friendly to manual writing, being concise and
 
   close to natural notation, with limited overhead (some backslashes and
 
   curly braces), while MathML is as tedious to handwrite as any other
 
   XML-based format. An example is worked out at
 
  
 
  http://en.wikipedia.org/wiki/MathML#Example_and_comparison_to_other_formats
 
  ,
 
   where 

Re: We should drop MathML

[Joshua Cranmer ]

On 5/5/2013 6:40 PM, Benoit Jacob wrote:

Well, I have written hundreds of pages of TeX; for sure, some large
equations would expand over more than one line of TeX, but I can't remember
going over more than 5 lines of TeX source (without custom helper macros)
per actual line of output, that that would be a really unusual case ---
while the MathML example above has a ratio of 30 source lines to 1 output
line.


For what it's worth, to compare the TeX to that MathML properly, you'd 
have to count, e.g., \frac{a}{b} as three lines:

\frac
  {a}
  {b}

An example I have of several lines of TeX-per-output-line is the 
following (some Big-Step semantics rules):

\frac{\langle b,\sigma\rangle \Downarrow \mathtt{true}\quad
  \langle \text{$s$ while ($b$) $s$},\sigma\rangle\Downarrow
  \langle t, \sigma_1\rangle}
 {\langle \text{while ($b$) $s$},\sigma\rangle \Downarrow
  \langle t, \sigma_1\rangle}

The rendered output of this would be (hopefully the MathML makes it 
through):
〈 b , σ 〉 ⇓ true 〈 s while (b) s , σ 〉 ⇓ 〈 t , σ 1 〉 〈 while (b) s , σ 〉 
⇓ 〈 t , σ 1 〉
Entering one of the lines in MathML in a more compact representation 
comes out to:
mo〈/momtextwhile (mib/mi) 
mis/mi/mtextmo,/momiσ/mimo〉/momo⇓/mo


So it's not a factor of 30-to-1 in verbosity, more like a factor of 
2-to-1 or 3-to-1. Certainly the same order of magnitude. You might argue 
that I'm cheating by using Unicode characters instead of entities, but 
the LaTeX-to-MathML conversion tools I've seen all output UTF-8, and 
UTF-8 is generally much more well supported by browsers than in TeX 
processors, so it's not an unrealistic assumption for how the text looks.


--
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