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
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://wi
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,
> 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.
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. Googl
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-p
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 base
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
___
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 =>
h
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 di
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,
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
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
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
Thanks Henri, that's a lot more clear to me than what I've read before in
this thread.
The point I've been trying to make is that rather than a separate language
for math, what would be better would be suitable extensions of HTML and CSS
to cover this, but I don't want to make this thread longer.
On Tue, May 28, 2013 at 3:22 PM, Benoit Jacob wrote:
> 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.
> 2. It's needed to support epub3 natively
On Tue, May 28, 2013 at 5:22 AM, Benoit Jacob wrote:
> 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 WYS
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 i
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
2013/5/28 Henri Sivonen
> On Fri, May 24, 2013 at 4:33 PM, Benoit Jacob
> 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 e
On Fri, May 24, 2013 at 4:33 PM, Benoit Jacob 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
2013/5/24 Henri Sivonen
> On Mon, May 6, 2013 at 1:52 AM, Benoit Jacob >wrote:
>
> > 2013/5/5 Robert O'Callahan > 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
On Mon, May 6, 2013 at 1:52 AM, Benoit Jacob wrote:
> 2013/5/5 Robert O'Callahan > 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 yo
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
On Monday, 6 May 2013 01:38:39 UTC+10, Benoit Jacob 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 uniform
On Monday, 6 May 2013 22:19:31 UTC+10, Boris Zbarsky wrote:
> 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_
>
>
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 Educat
> 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
I think Fred's point here was that the literal text in the MathML or LaTeX is
not what a blind person wants to hear. The whole point of math as a 2-D
notation is that the relative position of the parts of the equation carry
meaning. This is unlike normal text which almost always carries its whol
On Mon, May 06, 2013 at 07:13:04AM -0700, fred.w...@mathjax.org wrote:
> - 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.
I'd argue that any machine parsable
A bit more on the TeX part of this argument. Over a decade ago my company
polled publishers that accept submissions from authors of content containing
math. Although not a scientific poll, the results were overwhelming.
Approximately 85% of all submissions were in MS Word format with equations
> 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 inten
On 5/7/2013 1:42 PM, Robert O'Callahan wrote:
Keep in mind that without script, the kind of transformations you can apply
with Web Components are similar to XBL, and that's pretty limited.
Yes, I'm definitely not talking about a non-script implementation of any
of these. I'm presuming a fully sc
On Sunday, 5 May 2013 16:38:39 UTC+1, Benoit Jacob wrote:
> Hi,
>
>
>
> Summary: MathML is a vestigial remnant of the XML-everything era, and we
>
> should drop it.
>
As can be seen in the integration into HTML(5) nothing in MathML requires an
XML surface syntax.
>
>
> ***
>
>
>
> 1.
On Tue, May 7, 2013 at 6:46 AM, Benjamin Smedberg wrote:
> 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 H
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.mozil
> Does MathML need to participate in inline reflow in a way that requires
> direct support from the layout engine?
I don't know if that answers your question but one important thing that is
currently lacking in Gecko's MathML implementation is line breaking. This is
true for Web pages but I sus
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
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
* 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
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 o
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
On Tue, May 7, 2013 at 7:12 AM, 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?
>
This is a good question to ask, but I think it would help if there are
specific
2013/5/6 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
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
We're getting distracted by the comparison with TeX and the discussion of
MathML's relative merits. My bad: I obscured my message by starting two
conversations at once (1.1 and 1.2 in my initial email).
I happily concede this round, given that most people disagree with me about
TeX in this thread.
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
>
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
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
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 te
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 accessib
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, wh
On 5/5/13 10:46 PM, Benoit Jacob wrote:
* 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
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 v
On Mon, May 06, 2013 at 07:27:08AM -0400, Benoit Jacob wrote:
> 2013/5/6 Robert O'Callahan
>
> > 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 seriali
2013/5/6 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!
>
Yes, but a small subset of TeX could be purely a markup format, not a
programming language. Just support
2013/5/6 Robert O'Callahan
> 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.
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
> 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
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
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.
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
ht
On Mon, May 6, 2013 at 6:14 PM, Robert O'Callahan wrote:
> 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 qy
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 s
On Mon, May 6, 2013 at 10:52 AM, Benoit Jacob wrote:
> 2013/5/5 Robert O'Callahan
>
>> I would also say that one big difference between MathML and a
>> hypothetical TeX-based format is that MathML has a DOM and it's not clear
>> how to fit TeX into a DOM. That may not matter much for rendering, b
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
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 "
Let me just reply to a few points to keep this conversation manageable:
2013/5/5
> 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 use
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 w
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 Mozil
2013/5/5 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
> >
>
> 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#Exa
2013/5/5 Robert O'Callahan
> On Mon, May 6, 2013 at 3:38 AM, Benoit Jacob wrote:
>
>>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 fac
On Mon, May 6, 2013 at 3:38 AM, Benoit Jacob wrote:
>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 B
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
> I'm not sure if that's a joke or complete misinformation abou
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-pla
2013/5/5 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 wa
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 subse
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: w
77 matches
Mail list logo
