# Planet MathML

The Planet MathML aggregates posts from various blogs that concern MathML. Although it is hosted by W3C, the content of the individual entries represent only the opinion of their respective authors and does not reflect the position of W3C.

## Re: plain text math notation

Source: public-mathonwebpages@w3.org Mail Archives • Robin Berjon (robin@berjon.com) • September 26, 2016 • Permalink

On 23/09/2016 17:54 , Liam R. E. Quin wrote:
> On Fri, 2016-09-23 at 11:03 -0400, Robin Berjon wrote:
> [...]
>>
>>   function listPeople (people = [], listType) {
>>     return (
>>       <ul className={listType}>
>>         {
>>           people.map(p => <li>{p.name}</li>)
>>         }
>>       </ul>
>>     );
>>   }
>
> This isn't far removed from JSONiq (or even XQuery).

Yes, that's why I like it. I have long been thinking of doing some kind
of XQuery-like using JSX.

But _sshhhhh_, don't tell the millions of JS developers now using this!

--
• Robin Berjon - http://berjon.com/ - @robinberjon
• http://science.ai/ — intelligent science publishing
•


## Re: plain text math notation

Source: public-mathonwebpages@w3.org Mail Archives • Jean Kaplansky (jeankap@gmail.com) • September 23, 2016 • Permalink

But it is _very_ much "you got chocolate in my peanut butter" code. Good
thing I like chocolate AND peanut butter. :)

Jean Kaplansky

On Fri, Sep 23, 2016 at 5:54 PM, Liam R. E. Quin <liam@w3.org> wrote:

> On Fri, 2016-09-23 at 11:03 -0400, Robin Berjon wrote:
> [...]
> >
> >   function listPeople (people = [], listType) {
> >     return (
> >       <ul className={listType}>
> >         {
> >           people.map(p => <li>{p.name}</li>)
> >         }
> >       </ul>
> >     );
> >   }
>
> This isn't far removed from JSONiq (or even XQuery).
>
>
>
>


## Re: plain text math notation

Source: public-mathonwebpages@w3.org Mail Archives • Liam R. E. Quin (liam@w3.org) • September 23, 2016 • Permalink

On Fri, 2016-09-23 at 11:03 -0400, Robin Berjon wrote:
[...]
>
>   function listPeople (people = [], listType) {
>     return (
>       <ul className={listType}>
>         {
>           people.map(p => <li>{p.name}</li>)
>         }
>       </ul>
>     );
>   }

This isn't far removed from JSONiq (or even XQuery).


## Re: plain text math notation

Source: public-mathonwebpages@w3.org Mail Archives • Robin Berjon (robin@berjon.com) • September 23, 2016 • Permalink

On 22/09/2016 14:51 , Jos de Jong wrote:
> @Robin can you elaborate a bit on your idea? Do you mean that it would
> be trivial to translate a math formula into plain JavaScript which then
> can be evaluated, or to SVG for rendering? Or both?... Do you have
> concrete use cases in mind?

The way JSX works is that you can use markup in your code, like this:

let foo = <button>ohai!</button>;

That's pretty simple to type out, but obviously to make it useful what
you get out of it is not a string but a data structure. You can then
proceed to manipulating that data structure, injecting it into a DOM,
rendering it to string, etc. You can also embed code, variable, etc,
inside of it, say:

function listPeople (people = [], listType) {
return (
<ul className={listType}>
{
people.map(p => <li>{p.name}</li>)
}
</ul>
);
}

To be clear, I am not suggesting that this should be a major constraint
on the design. But I think it's worth keeping in mind the ability to
have the syntax as something that could be used as a plugin in a
JavaScript transpiler (this is not a very strong constraint, basically
it mostly needs to be disambiguatable from the surrounding context).

What gets returned could be manipulated (eg. you could feed it into a
library to execute it) or it could be rendered.

It's just a thought :)

--
• Robin Berjon - http://berjon.com/ - @robinberjon
• http://science.ai/ — intelligent science publishing
•


## TPAC 2016 F2F Minutes

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • September 23, 2016 • Permalink

Hi math-on-web CG,

Below are the minutes to the F2F at TPAC.

Given the late notice, the group was very small and we ended up focusing
entirely on accessibility related problems.

@Dani I noticed I didn't represent your example from the whiteboard. Can
you reconstruct it?

Best regards,
Peter.

# 2016-09-20 math-on-webpages CG, TPAC 2016

* Introductions / Present
* Manuel (Igalia): browser implementations, CSSWG
* Volker (ProgressiveAccess, U of Birmingham): accessibility interest,
math specifically, also working on MathJax
* Dani (WIRIS): known for web-based math editor, also handwriting
recognition, putting formulas (any which way), also a11y (but more
rendering).
* Peter (krautzource): works on MathJax, works on publishing workflow
chainend
* Peter: summarized the activity of the Group
* still getting to know each other, working on who can contribute on
which areas
* not about anything like MathML but interests so far are: practical
accessibility, procedural/computational, and incremental layout
improvemenets

## topic: accessibility

* Dani: starting point: we want to go beyond image+alttext
* exploration, alternative renderings etc
* if you have MathML you have a tree you can attach to; if you have HTML
or SVG, you also have a tree.
* Volker: our solution applies an "orthogonal" tree to the visual rendering
tree
* abstracting away the visual layout
* Dani: can we assume a static version of the equation?
* Volker: we do that to some degree (embed the data structure that
enhances)
* have done initial exploration for ARIA structure to expose such
information
* Dani: do you respect the visual output tree hierarchy?
* Volker: try to but sometimes not possible
* Dani: do you think it's possible?
* Peter: not sure it can be. Human understanding is too complicated;
cf. how you visually explore an image/SVG structure. but limitation of the
platform is: tree.
* Volker: demonstrated some examples from MathJax's accessibility
extensions
* the data structure is added to the MathML and is preserved in HTML
and SVG rendering
* while the semantic tree structure is ad-hoc, it seems this wheel
has been invented several times  (conversations with Murray Sargent, Neil
Soiffer etc)
* Dani: I like the idea of a tree that is both semantic and visual
* can we find something simpler/less powerful but where semantic = visual?
* Dani: example: 2+xy
* <span role="math"> x+2y</span>?
* but AT might read "ecks too whee", so slap on some aria-labels to fix
that
* maybe you can add "role=variable" etc.?
* Peter: cf our DEIMS paper
* Volker: should we have a structure that is independent of the actual DOM
representation
* e.g., commutative diagrams, chemistry etc have circular semantics that
cannot be mapped to a tree structure
* Dani: the descendants should be the default descendants
* Peter: there probably is (should be) a connection to SVG a11y
* e.g., an SVG for a clockface should need some circular component
* Volker: have not followed SVG a11y TF well enough
* asked Chaals, who said you can't do ProgressiveAccess's style chemistry
exploration with current SVG a11y TF work
* Dani: can we use hmtl trees and references
* [Dani's example, needs to be reconstructed]
* Peter: like aria-describedby?
* Peter: what if the visual tree does not match the semantic tree.
* e.g., \overbrace{a+...+a}{n-times}
* need to indicate to start at "a"
* Dani: pointers handle this
* Volker: so like aria-labledby/describedby
* Peter: what is in the elements in the second tree?
* Dani if referenced, nothing, but more than that
* Volker: why do labels and describeby not suffice?
* Peter: I suspect ARIA people will not accept a secondary tree.
* aria attributes are on the unique tree and, via accessible name
calculation, modify the accessible trees (potentially changing /
overwriting the original content)
* Dani: how much can you modify this way? E.g., order of the tree
* Peter: I think you can (vague memory from building menus, specifying
children and, I think their order)
* Volker: and obviously hacks (Google knowledge cards, taborder, flexbox
direction)
* Volker: have done test implementations to do both two trees and one.
* with a second tree, you might open up using any other formar (chemml)
* Peter: this comes very close to custom elements and shadowDOM
* ACTIONS: try to schedule meeting with aria folks


## Re: plain text math notation

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • September 23, 2016 • Permalink

Hi Kevin,

> With CAS, since the goal is to compute, you have no choice but to type
what you mean. Is the goal to come up with a universal CAS language?

The goal of this group is to bring practitioners together. While the group
itself cannot develop any kind of standard on its own, if enough people
want to work on such a thing, the group can provide the breeding ground and
help propose a standards effort. Of course, the group can also make
practical collaborative agreements among practitioners, especially when
things do not fall into the web standards world (cf. common-mark),

Best wishes,
Peter.

On Fri, Sep 23, 2016 at 12:25 AM, Paul Topping <pault@dessci.com> wrote:

> All good issues and ones that should be solved before worrying about the
> language syntax.
>
>
>
> I believe that the math structure should be bound to an interpretation
> that may be declared in the structure or held separately. Two mathematical
> structures may both contain an alpha but one binds it to some concept,
> variable, constant, or value and the other binds it some different one.
> When it is desired to calculate with the notation structure, it must be
> transformed into some other, computational structure based on the
> interpretation to which it is bound.
>
>
>
> Of course, problems may occur when it is necessary to map the
> computational structure back to a notational structure. These mappings are
> not generally one-to-one. This can be a good thing as it is possible to
> change a given expression from one notational scheme to another, or one
> computational structure to another. But it is a bad thing because there are
> multiple representations that have non-trivial mappings between them.
>
>
>
> Paul
>
>
>
>
>
> *From:* Kevin Cheung [mailto:KEVINCHEUNG@CUNET.CARLETON.CA]
> *Sent:* Thursday, September 22, 2016 3:02 PM
> *To:* Paul Topping <pault@dessci.com>; Jos de Jong <wjosdejong@gmail.com>;
> Robin Berjon <robin@berjon.com>
>
> *Cc:* Peter Krautzberger <peter.krautzberger@mathjax.org>;
> public-mathonw. <public-mathonwebpages@w3.org>
> *Subject:* Re: plain text math notation
>
>
>
> It will be nice if there is a math notation language that forces math
> writers to mean exactly what they write.  (Contrasting to what
> mathematicians sometimes do; they use the same LaTex symbols to mean
> different things in different contexts.)  With CAS, since the goal is to
> compute, you have no choice but to type what you mean.  Is the goal to come
> up with a universal CAS language?  If so, how would one go about dealing
> with really abstract math?
> ------------------------------
>
> *From:* Paul Topping <pault@dessci.com>
> *Sent:* Thursday, September 22, 2016 3:17:56 PM
> *To:* Jos de Jong; Robin Berjon
> *Cc:* Peter Krautzberger; public-mathonw.
> *Subject:* RE: plain text math notation
>
>
>
> The goal of a single math language that describes standard math notation
> AND works well for computation and manipulation is a worthwhile and, IMHO,
> achievable goal. However, starting at the syntax is not going to work.
> Sure, it is fine to express preferences for one language or another but the
> place to start is the model that the language expresses. By model, I mean
> abstract data structure and its dynamic semantics.
>
>
>
> MathML suffered from the too-many-cooks problem as well as not having a
> clear set of goals, IMHO. It also suffered from its association with XML
> but that’s a whole other story.
>
>
>
> I believe starting with the model is the only road to success but it is
> perhaps hard to convince people of that. Another advantage that might be
> more compelling is that, with well-designed model in hand, it should be
> possible to develop multiple syntaxes for expressing it, each useful in a
> different scenario: an XML syntax for the XML document world and, perhaps,
> for embedding in HTML, a JSON syntax for programmatic generation,
> manipulation, and consumption, a “plain-text math notation” for authors to
> type directly, etc.
>
>
>
> BTW, I am not sure “plain text math notation” is well-defined. In a sense,
> all computer languages are plain text and, at the same time, all have a
> syntax. I’m guessing what is meant by this is a notation that humans feel
> comfortable typing. Computers like regular syntaxes and are not bothered by
> extra characters such as angle brackets. Humans like something that doesn’t
> require too many keystrokes, hard to reach keys on the keyboard, doesn’t
> get scrambled in email, and is easy for humans to read. If this is what is
> meant, perhaps “human math language” might work. Just a thought.
>
>
>
> Paul Topping
>
>
>
> Design Science, Inc.
>
> "How Science Communicates"
>
> Makers of MathType, MathFlow, MathPlayer, Equation Editor
>
> http://www.dessci.com
>
>
>
> *From:* Jos de Jong [mailto:wjosdejong@gmail.com <wjosdejong@gmail.com>]
> *Sent:* Thursday, September 22, 2016 11:52 AM
> *To:* Robin Berjon <robin@berjon.com>
> *Cc:* Peter Krautzberger <peter.krautzberger@mathjax.org>;
> public-mathonw. <public-mathonwebpages@w3.org>
> *Subject:* Re: plain text math notation
>
>
>
> @Robin can you elaborate a bit on your idea? Do you mean that it would be
> trivial to translate a math formula into plain JavaScript which then can be
> evaluated, or to SVG for rendering? Or both?... Do you have concrete use
> cases in mind?
>
>
>
> Jos
>
>
>
> On Thu, Sep 22, 2016 at 3:53 PM, Robin Berjon <robin@berjon.com> wrote:
>
> On 22/09/2016 02:54 , Peter Krautzberger wrote:
> > Jos has written up some notes on plain text math notations at [1].
>
> This is IMHO a very promising area. I wonder if it may be interesting to
> consider making it not too distant from the syntax of (modern) JS so
> that it could easily be implemented as a BabelJS[0] plugin (like JSX[1]).
>
> [0] http://babeljs.io/
>
> --
> • Robin Berjon - http://berjon.com/ - @robinberjon
> • http://science.ai/ — intelligent science publishing
> •
>
>
>


## RE: plain text math notation

Source: public-mathonwebpages@w3.org Mail Archives • Paul Topping (pault@dessci.com) • September 22, 2016 • Permalink

All good issues and ones that should be solved before worrying about the language syntax.

I believe that the math structure should be bound to an interpretation that may be declared in the structure or held separately. Two mathematical structures may both contain an alpha but one binds it to some concept, variable, constant, or value and the other binds it some different one. When it is desired to calculate with the notation structure, it must be transformed into some other, computational structure based on the interpretation to which it is bound.

Of course, problems may occur when it is necessary to map the computational structure back to a notational structure. These mappings are not generally one-to-one. This can be a good thing as it is possible to change a given expression from one notational scheme to another, or one computational structure to another. But it is a bad thing because there are multiple representations that have non-trivial mappings between them.

Paul

From: Kevin Cheung [mailto:KEVINCHEUNG@CUNET.CARLETON.CA]
Sent: Thursday, September 22, 2016 3:02 PM
To: Paul Topping <pault@dessci.com>; Jos de Jong <wjosdejong@gmail.com>; Robin Berjon <robin@berjon.com>
Cc: Peter Krautzberger <peter.krautzberger@mathjax.org>; public-mathonw. <public-mathonwebpages@w3.org>
Subject: Re: plain text math notation

It will be nice if there is a math notation language that forces math writers to mean exactly what they write.  (Contrasting to what mathematicians sometimes do; they use the same LaTex symbols to mean different things in different contexts.)  With CAS, since the goal is to compute, you have no choice but to type what you mean.  Is the goal to come up with a universal CAS language?  If so, how would one go about dealing with really abstract math?

________________________________
From: Paul Topping <pault@dessci.com<mailto:pault@dessci.com>>
Sent: Thursday, September 22, 2016 3:17:56 PM
To: Jos de Jong; Robin Berjon
Cc: Peter Krautzberger; public-mathonw.
Subject: RE: plain text math notation

The goal of a single math language that describes standard math notation AND works well for computation and manipulation is a worthwhile and, IMHO, achievable goal. However, starting at the syntax is not going to work. Sure, it is fine to express preferences for one language or another but the place to start is the model that the language expresses. By model, I mean abstract data structure and its dynamic semantics.

MathML suffered from the too-many-cooks problem as well as not having a clear set of goals, IMHO. It also suffered from its association with XML but that's a whole other story.

I believe starting with the model is the only road to success but it is perhaps hard to convince people of that. Another advantage that might be more compelling is that, with well-designed model in hand, it should be possible to develop multiple syntaxes for expressing it, each useful in a different scenario: an XML syntax for the XML document world and, perhaps, for embedding in HTML, a JSON syntax for programmatic generation, manipulation, and consumption, a "plain-text math notation" for authors to type directly, etc.

BTW, I am not sure "plain text math notation" is well-defined. In a sense, all computer languages are plain text and, at the same time, all have a syntax. I'm guessing what is meant by this is a notation that humans feel comfortable typing. Computers like regular syntaxes and are not bothered by extra characters such as angle brackets. Humans like something that doesn't require too many keystrokes, hard to reach keys on the keyboard, doesn't get scrambled in email, and is easy for humans to read. If this is what is meant, perhaps "human math language" might work. Just a thought.

Paul Topping

Design Science, Inc.
"How Science Communicates"
Makers of MathType, MathFlow, MathPlayer, Equation Editor
http://www.dessci.com

From: Jos de Jong [mailto:wjosdejong@gmail.com]
Sent: Thursday, September 22, 2016 11:52 AM
To: Robin Berjon <robin@berjon.com<mailto:robin@berjon.com>>
Cc: Peter Krautzberger <peter.krautzberger@mathjax.org<mailto:peter.krautzberger@mathjax.org>>; public-mathonw. <public-mathonwebpages@w3.org<mailto:public-mathonwebpages@w3.org>>
Subject: Re: plain text math notation

@Robin can you elaborate a bit on your idea? Do you mean that it would be trivial to translate a math formula into plain JavaScript which then can be evaluated, or to SVG for rendering? Or both?... Do you have concrete use cases in mind?

Jos

On Thu, Sep 22, 2016 at 3:53 PM, Robin Berjon <robin@berjon.com<mailto:robin@berjon.com>> wrote:
On 22/09/2016 02:54 , Peter Krautzberger wrote:
> Jos has written up some notes on plain text math notations at [1].

This is IMHO a very promising area. I wonder if it may be interesting to
consider making it not too distant from the syntax of (modern) JS so
that it could easily be implemented as a BabelJS[0] plugin (like JSX[1]).

[0] http://babeljs.io/

--
* Robin Berjon - http://berjon.com/ - @robinberjon
* http://science.ai/ - intelligent science publishing
*


## Re: plain text math notation

Source: public-mathonwebpages@w3.org Mail Archives • Kevin Cheung (KEVINCHEUNG@CUNET.CARLETON.CA) • September 22, 2016 • Permalink

It will be nice if there is a math notation language that forces math writers to mean exactly what they write.  (Contrasting to what mathematicians sometimes do; they use the same LaTex symbols to mean different things in different contexts.)  With CAS, since the goal is to compute, you have no choice but to type what you mean.  Is the goal to come up with a universal CAS language?  If so, how would one go about dealing with really abstract math?

________________________________
From: Paul Topping <pault@dessci.com>
Sent: Thursday, September 22, 2016 3:17:56 PM
To: Jos de Jong; Robin Berjon
Cc: Peter Krautzberger; public-mathonw.
Subject: RE: plain text math notation

The goal of a single math language that describes standard math notation AND works well for computation and manipulation is a worthwhile and, IMHO, achievable goal. However, starting at the syntax is not going to work. Sure, it is fine to express preferences for one language or another but the place to start is the model that the language expresses. By model, I mean abstract data structure and its dynamic semantics.

MathML suffered from the too-many-cooks problem as well as not having a clear set of goals, IMHO. It also suffered from its association with XML but that's a whole other story.

I believe starting with the model is the only road to success but it is perhaps hard to convince people of that. Another advantage that might be more compelling is that, with well-designed model in hand, it should be possible to develop multiple syntaxes for expressing it, each useful in a different scenario: an XML syntax for the XML document world and, perhaps, for embedding in HTML, a JSON syntax for programmatic generation, manipulation, and consumption, a "plain-text math notation" for authors to type directly, etc..

BTW, I am not sure "plain text math notation" is well-defined. In a sense, all computer languages are plain text and, at the same time, all have a syntax. I'm guessing what is meant by this is a notation that humans feel comfortable typing. Computers like regular syntaxes and are not bothered by extra characters such as angle brackets. Humans like something that doesn't require too many keystrokes, hard to reach keys on the keyboard, doesn't get scrambled in email, and is easy for humans to read. If this is what is meant, perhaps "human math language" might work. Just a thought.

Paul Topping

Design Science, Inc.
"How Science Communicates"
Makers of MathType, MathFlow, MathPlayer, Equation Editor
http://www.dessci.com

From: Jos de Jong [mailto:wjosdejong@gmail.com]
Sent: Thursday, September 22, 2016 11:52 AM
To: Robin Berjon <robin@berjon.com>
Cc: Peter Krautzberger <peter.krautzberger@mathjax.org>; public-mathonw. <public-mathonwebpages@w3.org>
Subject: Re: plain text math notation

@Robin can you elaborate a bit on your idea? Do you mean that it would be trivial to translate a math formula into plain JavaScript which then can be evaluated, or to SVG for rendering? Or both?... Do you have concrete use cases in mind?

Jos

On Thu, Sep 22, 2016 at 3:53 PM, Robin Berjon <robin@berjon.com<mailto:robin@berjon.com>> wrote:
On 22/09/2016 02:54 , Peter Krautzberger wrote:
> Jos has written up some notes on plain text math notations at [1].

This is IMHO a very promising area. I wonder if it may be interesting to
consider making it not too distant from the syntax of (modern) JS so
that it could easily be implemented as a BabelJS[0] plugin (like JSX[1]).

[0] http://babeljs.io/

--
* Robin Berjon - http://berjon.com/ - @robinberjon
* http://science.ai/ - intelligent science publishing
*


## RE: plain text math notation

Source: public-mathonwebpages@w3.org Mail Archives • Paul Topping (pault@dessci.com) • September 22, 2016 • Permalink

The goal of a single math language that describes standard math notation AND works well for computation and manipulation is a worthwhile and, IMHO, achievable goal. However, starting at the syntax is not going to work. Sure, it is fine to express preferences for one language or another but the place to start is the model that the language expresses. By model, I mean abstract data structure and its dynamic semantics.

MathML suffered from the too-many-cooks problem as well as not having a clear set of goals, IMHO. It also suffered from its association with XML but that’s a whole other story.

I believe starting with the model is the only road to success but it is perhaps hard to convince people of that. Another advantage that might be more compelling is that, with well-designed model in hand, it should be possible to develop multiple syntaxes for expressing it, each useful in a different scenario: an XML syntax for the XML document world and, perhaps, for embedding in HTML, a JSON syntax for programmatic generation, manipulation, and consumption, a “plain-text math notation” for authors to type directly, etc.

BTW, I am not sure “plain text math notation” is well-defined. In a sense, all computer languages are plain text and, at the same time, all have a syntax. I’m guessing what is meant by this is a notation that humans feel comfortable typing. Computers like regular syntaxes and are not bothered by extra characters such as angle brackets. Humans like something that doesn’t require too many keystrokes, hard to reach keys on the keyboard, doesn’t get scrambled in email, and is easy for humans to read. If this is what is meant, perhaps “human math language” might work. Just a thought.

Paul Topping

Design Science, Inc.
"How Science Communicates"
Makers of MathType, MathFlow, MathPlayer, Equation Editor
http://www.dessci.com

From: Jos de Jong [mailto:wjosdejong@gmail.com]
Sent: Thursday, September 22, 2016 11:52 AM
To: Robin Berjon <robin@berjon.com>
Cc: Peter Krautzberger <peter.krautzberger@mathjax.org>; public-mathonw. <public-mathonwebpages@w3.org>
Subject: Re: plain text math notation

@Robin can you elaborate a bit on your idea? Do you mean that it would be trivial to translate a math formula into plain JavaScript which then can be evaluated, or to SVG for rendering? Or both?... Do you have concrete use cases in mind?

Jos

On Thu, Sep 22, 2016 at 3:53 PM, Robin Berjon <robin@berjon.com<mailto:robin@berjon.com>> wrote:
On 22/09/2016 02:54 , Peter Krautzberger wrote:
> Jos has written up some notes on plain text math notations at [1].

This is IMHO a very promising area. I wonder if it may be interesting to
consider making it not too distant from the syntax of (modern) JS so
that it could easily be implemented as a BabelJS[0] plugin (like JSX[1]).

[0] http://babeljs.io/

--
• Robin Berjon - http://berjon.com/ - @robinberjon
• http://science.ai/ — intelligent science publishing
•



## Re: plain text math notation

Source: public-mathonwebpages@w3.org Mail Archives • Jos de Jong (wjosdejong@gmail.com) • September 22, 2016 • Permalink

@Robin can you elaborate a bit on your idea? Do you mean that it would be
trivial to translate a math formula into plain JavaScript which then can be
evaluated, or to SVG for rendering? Or both?... Do you have concrete use
cases in mind?

Jos

On Thu, Sep 22, 2016 at 3:53 PM, Robin Berjon <robin@berjon.com> wrote:

> On 22/09/2016 02:54 , Peter Krautzberger wrote:
> > Jos has written up some notes on plain text math notations at [1].
>
> This is IMHO a very promising area. I wonder if it may be interesting to
> consider making it not too distant from the syntax of (modern) JS so
> that it could easily be implemented as a BabelJS[0] plugin (like JSX[1]).
>
> [0] http://babeljs.io/
>
> --
> • Robin Berjon - http://berjon.com/ - @robinberjon
> • http://science.ai/ — intelligent science publishing
> •
>
>


## Re: plain text math notation

Source: public-mathonwebpages@w3.org Mail Archives • Robin Berjon (robin@berjon.com) • September 22, 2016 • Permalink

On 22/09/2016 02:54 , Peter Krautzberger wrote:
> Jos has written up some notes on plain text math notations at [1].

This is IMHO a very promising area. I wonder if it may be interesting to
consider making it not too distant from the syntax of (modern) JS so
that it could easily be implemented as a BabelJS[0] plugin (like JSX[1]).

[0] http://babeljs.io/

--
• Robin Berjon - http://berjon.com/ - @robinberjon
• http://science.ai/ — intelligent science publishing
•


## plain text math notation

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • September 22, 2016 • Permalink

Hi math-on-web CG,

Jos has written up some notes on plain text math notations at [1].

Best regards,
Peter.

[1] https://w3c.github.io/mathonwebpages/research/text_based_standards.html


## Re: TPAC hangout Inbox x

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • September 20, 2016 • Permalink

PS We continue to have connection issues. If you want to join and encounter
problems, please write a short message.

On Tue, Sep 20, 2016 at 3:27 PM, Peter Krautzberger <
peter.krautzberger@mathjax.org> wrote:

> Hi folks,
>
> In case anyone has time to join us at TPAC remotely, here is a hangout
> you are invited to:
>
>
> (Sorry for the delay due to network problems).
>
> There will also be minutes.
>
> Best regards,
> Peter.
>


## TPAC hangout Inbox x

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • September 20, 2016 • Permalink

Hi folks,

In case anyone has time to join us at TPAC remotely, here is a hangout
you are invited to:

(Sorry for the delay due to network problems).

There will also be minutes.

Best regards,
Peter.


## Release Notes for Safari Technology Preview Release 13

Source: WebKit • Jon Davis • September 15, 2016 • Permalink

Safari Technology Preview Release 13 is now available for download for both macOS Sierra betas and OS X El Capitan 10.11.6. If you already have Safari Technology Preview installed, you can update from the Mac App Store’s Updates tab. This release covers WebKit revisions 204876–205519.

### Fetch API

• Added support for BufferSource bodies (r205115)
• Fixed blob resource handling to raise a network error when the URL is not found (r205190)
• Set the blob type correctly for an empty body (r205250)
• Set the blob type from Response/Request contentType header (r205076)
• Made the body mix-in text() decode data as UTF–8 (r205188)
• Enabled the Fetch API to load the data URL in same-origin mode (r205265)
• Prevented any body for opaque responses (r205082)
• Changed opaqueredirect responses to have their URL set to the original URL (r205081)
• Prevented setting bodyUsed when request construction fails (r205253)
• Set Response bodyUsed to check for its body-disturbed state (r205251)
• Changed response cloning to use structureClone when teeing a Response stream (r205117)
• Aligned the internal structure of ReadableStream with the specifications (r205289)
• Aligned data:// URL behavior of XHR to match specifications (r205113)

### Custom Elements

• Added adopted callback for custom elements on appendChild() (r205085)
• Enabled reaction callbacks for adopted custom elements (r205060)
• Updated the semantics of :defined to re-align with specification changes (r205416)
• Added validations for a synchronously constructed custom element (r205386)
• Added support for the whenDefined() method on the CustomElementRegistry (r205315)
• Added a CustomElementRegistry check for reentrancy (r205261)

### JavaScript

• Enabled assignments in for…in head in non-strict mode (r204895)
• Changed newPromiseCapabilities to check that the given argument is a constructor (r205027)
• Fixed toString() to return the correct tag when called on proxy objects (r205023)

### Web APIs

• Added event support for <link preload> (r205269)
• Implemented x, y and ScrollToOptions arguments for Element.scroll(), Element.scrollTo(), and Element.scrollBy() (r205505)
• Updated location.toString to make it enumerable (r204953)
• Updated location.toString in Web Workers to make it enumerable (r204954)
• Changed Object.preventExtensions(window) to throw a TypeError exception (r205404)
• Aligned coords and srcset attribute parsing with the HTML specification (r205030, r205515)
• Added support for CanvasRenderingContext2D.prototype.resetTransform (r204878)
• Aligned cross-origin Object.getOwnPropertyNames() with the HTML specification (r205409)

### Web Inspector

• Added IndexedDB Database, ObjectStore, and Index data to the details sidebar (r205043)
• Added support for Shift-Command-D (⇧⌘D) to switch to the last used dock configuration (r205413)
• Added support for Shift-Tab (⇧⇥) to un-indent the selected line (r204924)
• Changed Command-D (⌘D) to select the next occurrence instead of deleting the line (r205414)
• Added a visual indicator for shadow content in the DOM tree (r205322)
• Allowed hiding of CSS variables in the Computed styles panel (r205518)
• Fixed an issue that prevented using an Undo action in the breakpoint editor (r205499)
• Prevented the resource content view from showing “CR” characters (r205517)
• Fixed an issue preventing re-inspecting the page after a Web Inspector process crash (r205370)
• Improved the minification detection heuristic for small resources (r205314)
• Fixed an issue causing network record bars to be positioned on unexpected rows (r205349)
• Provided a way to clear an IndexedDB object store (r205041)
• Improved the debugger popover to pretty print functions (r205223)
• Corrected unexpected cursor changes while dragging ruler handle in the rendering frames timeline (r204940)
• Corrected the display of a plain text XHR response with responseType="blob" (r205268)

### CSS

• Implemented CSS.escape according to the CSSOM specification (r204952)
• Improved CSS stylesheet checks to ensure clean stylesheets are accessible from JavaScript (r205455)
• Improved :enabled and :disabled selectors to only match elements that can be disabled (r205050)

### Rendering

• Fixed scrollbars for a <table> with overflow content inside <div align="right"> (r205489)
• Added support for non-BMP MathML operators U+1EEF0 and U+1EEF1 (r205111)
• Fixed getting font bounding rect for MathML (r205031)

### Security

• Changed the Image Loader to set the fetch mode according its crossOrigin attribute (r205134)
• Added a SecurityError when trying to access cross-origin Location properties (r205026)
• Updated Object.defineProperty() and Object.preventExtensions() to throw an error for a cross-origin Window or Location object (r205358, r205359)
• Updated Object.setPrototypeOf() to throw an error and return null when used on a cross-origin Window or Location object (r205205, r205258)

### Plugins

• Replaced YouTube.com Flash embeds with HTML5 equivalents on macOS (r205274)

## UnicodeMath

Source: Murray Sargent: Math in Office • MurrayS3 • September 07, 2016 • Permalink

In writing the post Nemeth Braille—the first math linear format, I became increasingly aware that the Unicode Nearly Plain Text Encoding of Mathematics needed a better name than “linear format”. In addition to the Nemeth braille linear format, there are other math linear formats some of which are described in the post Linear Format Notations for Mathematics. One of these, AsciiMath, inspired the name UnicodeMath, which is much more specific than “linear format”. UnicodeMath uses the Unicode math symbol set (see Math property in DerivedCoreProperties.txt), resembles real mathematical notation the most closely of all math linear formats, and handles almost every mathematical notation. Since Unicode characters are global by nature, UnicodeMath doesn’t need localization. [La]TeX and AsciiMath define characters using ASCII control words that are Western-centric, and perhaps need to be localized in nonLatin-based locales.

In addition to being the most readable linear format, UnicodeMath is the most concise. It represents the simple fraction, one half, by the 3 characters “1/2”, whereas typical MathML takes 62 characters (consisting of the <mml:mfrac> entity). This conciseness makes UnicodeMath an attractive format for storing mathematical expressions and equations, as well as for ease of keyboard entry. Another comparison is in the math structures for the Equation Tools tab in the Office ribbon. In Word, the structures are defined in OMML (Office MathML) and built up by Word, while for the other apps, the structures are defined in UnicodeMath and built up by RichEdit. The latter are much faster and the equation data much smaller. A dramatic example is the stacked fraction template (empty numerator over empty denominator). In UnicodeMath, this is given by the single character ‘/’. In OMML, it’s 109 characters! LaTeX is considerably shorter at 9 characters “\frac{}{}”, but is still 9 times longer than UnicodeMath. AsciiMath represents fractions the same way as UnicodeMath, so simple cases are identical. If Greek letters or other characters that require names in AsciiMath are used, UnicodeMath is shorter and more readable.

Another advantage of UnicodeMath over MathML and OMML is that UnicodeMath can be stored anywhere Unicode text is stored. When adding math capabilities to a program, XML formats require redefining the program’s file format and potentially destabilizing backward compatibility, while UnicodeMath does not. If a program is aware of UnicodeMath math zones (see Section 3.20 of UnicodeMath), it can recover the built-up mathematics by passing those zones through the RichEdit UnicodeMath MathBuildUp function. In fact, you can roundtrip RichEdit documents containing math zones through the plain-text editor Notepad: the math zones are preserved!

## AsciiMath

As its name implies, AsciiMath uses only ASCII characters, although it converts to MathML with access to a much larger character set. AsciiMath is relatively simple to parse and can handle many mathematical constructs. AsciiMath shares some methodology with UnicodeMath, such as eliminating the outer parentheses in fractions like (a+b)/c when converting to built-up format. AsciiMath is designed to work with a MathML renderer, such as MathJax. In Microsoft Office apps, UnicodeMath builds up to the LineServices math internal format, which represented by OMML.

## Math autocorrect

By default, the Office math autocorrect facility contains most [La]TeX math symbol control word definitions such as \beta for β. AsciiMath has a subset of such control words but omits the leading backslash. The user can modify such control words in the Office math autocorrect list or add them explicitly, but it’d probably be worth adding an option to make the leading backslash optional. That would speed up keyboard entry of UnicodeMath via math autocorrect. The RichEdit dll includes the UnicodeMath build up/down facility as well as converters for other math formats, such as MathML and OMML. It would be straightforward to add an option to the RichEdit UnicodeMath facility to accept AsciiMath input in general. Such an option would be handy for people that know AsciiMath.

One C++ oriented autocorrect choice in AsciiMath is that typing != enters ≠. Although I program in C++ almost every day, I think /= is a better choice for entering ≠. For one thing, using != for ≠ complicates typing in an equation like n! = n(n-1)(n-2)…1, which is the main reason we didn’t implement it. But in Office apps this equation can also be entered by typing ! = instead of !=, since math spacing rules insert space between ! and = and the RichEdit UnicodeMath facility automatically deletes a user’s space if typed there (see User Spaces in Math Zones). So, that’s an easy work around for entering an n! equation if one wants to support != for ≠. The RichEdit UnicodeMath facility supports most Unicode negated operators by sequences of / followed by the corresponding unnegated operator as described in the post Negated Operators.

<gripe> Meanwhile the C++ language should recognize ≠, ≤, ≥, and ≡ as aliases for !=, <=, >=, and ==. It seems primitive that C++ doesn’t do so in this Unicode age of computing. At least the C++ editing/debugging environments should have an option to display !=, <=, >=, and == as ≠, ≤, ≥, and ≡. </gripe>

## Comparison

Here’s a table with various formats for the integral

 Format Representation UnicodeMath 1/2𝜋 ∫_0^2𝜋▒ⅆ𝜃/(𝑎+𝑏 sin⁡𝜃 )=1/√(𝑎^2−𝑏^2 ) AsciiMath 1/(2pi) int_0^(2pi) dx/(a+bsin theta)=1/sqrt(a^2-b^2) LaTeX \frac{1}{2\pi}\int_{0}^{2\pi}\frac{d\theta}{a+b\sin {\theta}}=\frac{1}{\sqrt{a^2-b^2}}

Note that UnicodeMath binds the integrand to the integral, whereas AsciiMath and LaTeX don’t define the limits of the integrand. The Presentation MathML and OMML for this integral are too long to put into this post.

## Observations

There is a unicode-math conversion package for Unicode enabled XeTeX and LuaLaTeX. The name UnicodeMath seems sufficiently different from unicode-math that there shouldn’t be any confusion between the two. The unicode-math package supports a variety of math fonts including Cambria Math, Minion Math, Latin Modern Math, TeX Gyre Pagella Math, Asana-Math, Neo-Euler, STIX, and XTIS Math. Did you know there are so many math fonts?

Enjoy the new name UnicodeMath. I am and it already appears near the end of my previous blog post, Nemeth Braille Alphanumerics and Unicode Math Alphanumerics. If you’re interested in the origin of UnicodeMath, read the post How I got into technical WP. The forerunner of UnicodeMath originated back in the early microcomputer days and had only 512 characters consisting of upright ASCII, italics, script, Greek and various mathematical symbols used in theoretical physics. Unicode 1.0 didn’t arrive until 10 years later.

## The HTML5 Spec: What's In and What's Out?

Source: Ask.com News Search for "mathml" • September 01, 2016 • Permalink

 HTML Goodies - Found Sep. 1, 2016 ... and announced to start developing tools using HTML5. Options to support scalable vector graphics (SVL) and MathML were added to support...

## MathJax v2.7 beta now available

Source: MathJax • September 01, 2016 • Permalink

Today we are entering the public beta phase of MathJax v2.7. MathJax v2.7 is primarily a bug-fix release with over 60 important bug fixes. In addition, this release adds several new features as an opt-in. The following are some of the highlights:

1. CommonHTML output improvements Several important bugs in the layout model have been fixed, in particular tabular layout is now much more robust.
2. Accessibility extensions. After the completion of the MathJax Accessibility Extensions, we are integrating the lightweight opt-in into the MathJax core. This allows readers to opt into the following features via the MathJax Menu:
• Responsive Equations. An innovative responsive rendering of mathematical content through collapsing and exploration of subexpressions.
• Universal aural Rendering. An aural rendering tool providing on-the-fly speech-text for mathematical content and its subexpressions using various rule sets.
• Full Exploration. A fully accessible exploration tool, allowing for meaningful exploration of mathematical content including multiple highlighting features and synchronized aural rendering.
• For detailed information check the accessibility extensions’ release announcement.
3. Opt-in for mhchem v3 The mhchem extension in the core now provides a configuration option to switch to mchhem v3. This new version was (re-)written by Martin Hensel, author of the original $\rm \LaTeX$ package, and greatly revises and extends it. This new extension is also available directly through the MathJax Third Party Extension repository
4. Simplified opt-in for third party extensions MathJax v2.7 configures the [Contrib] path variable to the URL of the third party extension repository on the MathJax CDN. This simplifies loading contributed extensions.
5. Third Party Extension Updates Our Third Party Extension repository as seen some great additions recently. The MathJax team is grateful for these contributions from the community!

For details on all bug fixes, please see below.

The beta is available via our CDN at beta.mathjax.org/mathjax/latest/MathJax.js which you can load it in place of the version you are currently using. Alternatively, you can get a ZIP archive or access the branch on GitHub.

### Changes to the combined configuration files

If you are using a combined configuration, please note that we added the the accessibility menu extension to all combined configuration files. This extension will always load from cdn.mathjax.org/mathjax/contrib. If you are hosting your own copy of MathJax and if your users will not be able to access cdn.mathjax.org, then you should disable the [Contrib] path by adding noContrib to the query string, e.g., MathJax.js?config=...&noContrib to avoid unnecessary failed requests.

Remember that this is still beta software, so if you are not an experienced user, you may want to wait for the official 2.7 release. We do not recommend that you use the 2.7-beta version for production environments, but do encourage you to test your content with it.

If you are linking to http://cdn.mathjax.org/mathjax/latest/MathJax.js, note that at the point of the official release of v2.7, the address will begin to serve MathJax v2.7. You can also continue to use v2.6 by linking to http://cdn.mathjax.org/mathjax/2.6-latest/MathJax.js instead — and you can change to that version at any point (it is available now).

The official release of v2.7 should occur within the next few weeks, but we want you to be able to start to test out the v2.7 features now. Please report any bugs you find to the issue tracker at https://github.com/mathjax/MathJax/issues.

Thanks for your continuing interest in MathJax. We hope that this release makes your MathJax experience even better.

The MathJax Team.

## New in MathJax v2.7

MathJax v2.7 is primarily a bug-fix release with over 60 important bug fixes, in particular to the CommonHTML output. In addition, this release adds several new features as an opt-in. The following are some of the highlights.

## Features

• Common HTML output improvements Several important bugs in the layout model have been fixed, in particular tabular layout is now much more robust.
• Accessibility improvements. After the completion of the MathJax Accessibility Extensions, we are integrating the opt-in for the MathJax menu into the core distribution. We are grateful to the web accessibility community for their guidance, support, and feedback in our efforts towards making MathJax completely accessible to all users. This allows end-users to opt into the following features via the MathJax Menu:
• Responsive Equations. An innovative responsive rendering of mathematical content through collapsing and exploration of subexpressions.
• Universal aural Rendering. An aural rendering tool providing on-the-fly speech-text for mathematical content and its subexpressions using various rule sets.
• Full Exploration. A fully accessible exploration tool, allowing for meaningful exploration of mathematical content including multiple highlighting features and synchronized aural rendering.
• For more information check the release announcement and the dedicated repository at mathjax/mathjax-a11y.

For a detailed listing please check the release milestone.

## Accessibility

• mathajx-dev/#20 Add the Menu extension from the MathJax Accessibility tools to all combined configuration files.
• #1465 CHTML and HTML-CSS output: do not add role=math by default.
• #1483 Catch IE8 errors with inserting MathML from AssistiveMML extension.
• #1513 Disable the AssistiveMML extension when the output renderer is PlainSource.

## Interface

• #1463 Reset message strings for messageStyle=simple for each typeset.

## HTML/SVG/nativeMML display

• #1454 SVG output: Use full location URL for xlink references in SVG <use> elements.
• #1457 Common-HTML output: Fix problem with characters from Unicode Plane 1 not being mapped to the MathJax fonts properly
• #1458 SVG output: Fix problem with container width when math is scaled.
• #1459 CommonHTML output: Improve getNode() to fix processing errors when line-breaking.
• #1460 HTML-CSS output: Adjust position of rule for square root when it is made via createRule().
• #1461 HTML-CSS output: Make sure 0 remains 0 when rounding to pixels (plus a bit).
• #1462 CommonHTML output: Bubble percentage widths up while line breaking.
• #1475 PreviewHTML: Avoid error when \overset or \underset is empty.
• #1479 All outputs: Properly determine (shrink-wrapping) container widths.
• #1503 CommonHTML output: Handle adjusting table cell heights properly.
• #1507 SVG output: Remove invalid src attribute from <mglyph> output.
• #1510 CommonHTML output: Prevent CSS bleed-through for box-sizing.
• #1512 CommonHTML output: make <mglyph> scale image size by hand.
• #1530 All outputs: Fix problem with Safari inserting line breaks before in-line math.
• #1533 CommonHTML output: improve aligning labels with their table rows.
• #1534 CommonHTML output: ensure output stays a table-cell when focused.
• #1538 All outputs: Don’t let preview width interfere with the determination of the container width.
• #1542 CommonHTML output: improve stretching <mover> in <mtd> elements.
• #1547 HTML-CSS output: improve line breaks within fractions.
• #1549 All outputs: Improve determination of line-breaking parent element.
• #1550 CommonHTML output: Improve vector arrow positioning.
• #1552 All outputs: Handle href correctly when line breaking.
• #1574 HTML-CSS and SVG output: Use currentColor for <menclose> with no mathcolor.
• #1595 CommonHTML output: Properly scale elements with font-family specified.

## TeX emulation

• #1455 Fix TeX.Environment() to use the correct end environment.
• #1464 Make sure resetEquationNumbers is always defined.
• #1484 Mark accented operators as not having movable limits.
• #1485 Allow line breaks within TeXAtom elements
• #1508 Surround \middle with OPEN and CLOSE TeXAtoms to match TeX spacing
• #1509 Make delimiters (in particular arrows) symmetric for \left and \right.
• #1514 Don’t unwrap rows when creating fenced elements.
• #1523 Don’t copy environment into array environments.
• #1537 mhchem: add config parameter to select mhchem v3.0.
• #1596 Prevent \require{mhchem} to override one already loaded.
• #1551 Allow <wbr> in TeX code.
• #1565 Handle \+SPACE in macro definitions.
• #1569 Treat control sequences as a unit when matching a macro template.
• #1587 Make sure trimSpaces() doesn’t remove tailing space in \+SPACE.
• #1602 Handle \ref properly when there is a <base> tag.

## MathML

• #1505 Handle rowlines="" and rowlines=" " like rowlines="none".
• #1511 Don’t convert attribute to boolean unless the default is a boolean.
• #1526 Make minus in <mn> produce U+2212 rather than U+002D.
• #1567 Fix spacing for initial fraction in exponent position.

## Fonts

• #1521 STIX fonts: Make left arrow use combining left arrow for accents.
• #1092 STIX fonts: Make U+222B (integral) stretchy.
• #1154 STIX fonts: Remap | to variant form (with descender) and map variant to original form.
• #1175 Use U+007C and U+2016 for delimiters rather than U+2223 and U+2225.
• #1421 MathJax TeX fonts: Fix SVG font data for stretchy characters.
• #1418 Alias U+2206 to U+0394 and remove incorrect U+2206 from SVG font files.
• #1187 Make height and depth of minus match that of plus (needed for TeX-layout super/subscript algorithm to work properly), and adjust for that when it is used as an extender in stretchy characters.
• #1546 MathJax TeX fonts: Add stretchy data for U+20D7.

## Localization

• #1604 Updated locales thanks to the contributors at Translatewiki.net; activate locale for Zazaki.

## APIs

• #1504 Make getJaxForMath() work even during chunking.
• #1522 Add Third Party Extensions Repository to the Ajax paths as [Contrib].
• #1525 Allow MathJax root to be configured.

## Misc.

• #1456 Prevent removal of DOM elements while MathJax is running from stopping processing, or to leaving duplicate math in place.
• #1524 Prevent pre-processors from adding duplicate preview elements.
• #1554 Safe extension: Add filtering of CSS styles like padding, margin.
• #1590 Set previews to have display:none.
• #1591 Change rev= to V= in cache breaking code.

## Re: TPAC meeting DPUB IG & math-on-webpages

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • August 31, 2016 • Permalink

Dear math-on-webpages CG,

The last-minute nature of this thread makes it difficult to plan beyond our
own slot.

>From the call, I remember that a few people besides myself are planning or
considering to attend TPAC so there's no reason to let our slot go to waste
:-)

If you are thinking about attending TPAC and would like to attend the CG
meeting (Tuesday, 13:30--15:30), could you please send an email to Dani or
myself?

Best regards,
Peter.

On Mon, Aug 29, 2016 at 5:55 PM, Peter Krautzberger <
peter.krautzberger@mathjax.org> wrote:

> Dea DPUB IG and Math-on-Webpages CG,
>
> The math-on-webpages CG got a meeting slot for TPAC (Tue, 13:30–15:30).
>
> So in the last CG F2F, people present decided to it would be best to
> concentrate on a meeting with the DPUB IG.
>
> The DPUB IG schedule [1] already lists something for the time but I'm
> wondering if we could fit something in anyway?
>
> Best wishes,
> Peter.
>
> [1] https://www.w3.org/dpub/IG/wiki/Sep_2016_F2F_Logistics_
> and_Details#Tuesday.2C_20_September
>


## Release Notes for Safari Technology Preview Release 12

Source: WebKit • Jon Davis • August 30, 2016 • Permalink

Safari Technology Preview Release 12 is now available for download for both macOS Sierra betas and OS X El Capitan. If you already have Safari Technology Preview installed, you can update from the Mac App Store’s Updates tab. This release covers WebKit revisions 204289–204876.

This release of Safari Technology Preview will be the last that will install and run on OS X El Capitan 10.11.4 and 10.11.5. To continue testing or living on the latest enhancements to WebKit, please upgrade to OS X El Capitan 10.11.6 or the macOS Sierra betas.

### JavaScript

• Added checks for TypedArray.prototype.slice to ensure the source and destination have not been detached (r204868)
• Added exception handling for const variables used in a for-in or for-of loop (r204586)
• Improved the performance of Array.prototype.map when used with Arrays (r204488)
• Implemented Object.entries and Object.values from the ES2017 specifications (r204419, r204358)
• Changed the line, column and sourceURL properties of Error to be configurable and writable (r204663)

### Web APIs

• Fetch API is enabled by default (r204705)
• Updated Resource Timing implementation (r204736, r204641, r204429)
• Aligned Range.surroundContents() with the latest DOM specification (r204390)
• Added support for HTMLAreaElement.toString() (r204871)
• Changed the prefix properties of Attr and Element to be read-only (r204648)
• Changed <command> to an HTMLUnknownElement and <basefont> to an HTMLElement (r204647)
• Moved the prefix, namespaceURI, and localName attributes from Node to Attr and Element (r204624)
• Aligned text encoding labels with the Encoding specification (r204605)
• Added Animatable, AnimationEffect, KeyframeEffect and Animation interfaces for Web Animations (r204594)
• Aligned isDefaultNamespace(), lookupPrefix(), and lookupNamespaceURI() with the specification (r204536)
• Changed querySelector() and querySelectorAll() to always throw a SyntaxError when failing to parse a selector string (r204522)
• Moved embeds, plugins, and scripts attributes from HTMLDocument to Document (r204450)
• Moved the compatMode and designMode properties from HTMLDocument to Document (r204451, r204449)
• Updated getElementsByTagName() to take a qualified name parameter (r204441)
• Exposed crypto.getRandomValues to Web Workers (r204481)
• Added application/vnd.api+json as a valid JSON MIME-type (r204437)

### Web Inspector

• Added a visual editor for the spring() timing-function (r204775)
• Fixed an issue where “NaN x NaN” was shown for invisible elements in the Styles → Computed → Box Model section (r204759)
• Set Open Resource Dialog to jump to the last line when the specified line number (“:n”) is more than the total line count of the resource (r204755)
• Added an icon for selectors that only affect pseudo-elements (r204754)
• Fixed DOM nodes shifting when hovering over them in the Console (r204520)
• Fixed the alignment of the Close button of the selected item in the Network tab (r204491)
• Changed the Visual Styles Sidebar behavior for SVGs to show SVG specific sections (r204758)
• Changed the Visual Styles Sidebar TextContent section to only be visible for a pseudo-element (r204757)
• Escaped Text → Content in the Visual Styles Sidebar (r204510)
• Addressed status icons flickering from rapid updates in the Visual Styles Sidebar (r204562)
• Fixed the placement of Error and Warning icons in the Visual Styles Sidebar (r204490)
• Fixed a hang when using Command-Shift-O (⌘⇧O) when the loaded web page has frames (r204428)
• Enabled editing node attributes, content, and styles for shadow DOM nodes (r204370)
• Improved the display of large numbers in the console log counter on the dashboard (r204642)
• Improved the display of large class lists and made the quick-toggle easier to discover (r204496)

### MathML

• Improved the extraction of operator and token elements’ characters (r204830)
• Introduced a MathMLRowElement class for mrow-like elements (r204779)
• Introduced a MathMLAnnotationElement class for the <annotation> and <annotation-xml> elements (r204692)

### CSS

• Enabled the :host pseudo-class to style elements in the shadow tree (r204724)
• Corrected the namespace prefix handling in front of element name CSS selectors (r204591)

### Rendering

• Fixed SVG clip-path to work on a root SVG element (r204872)
• Fixed ctx.drawImage to clip the source rectangle if it is outside the source image (r204517)

### Accessibility

• Labelled audio description tracks correctly to prevent user confusion (r204601)
• Added a percentage value description for the media control’s timeline slider (r204361)

### Security

• Improved URLParser parsing IPv4 addresses and URLs without credentials (r204701, r204544)
• Added support to handle cross-origin redirect requests while in CORS mode (r204693, r204795)
• Corrected the Upgrade-Insecure-Request state handling between navigations (r204521)
• Added a sandbox for the Adobe Flash Player ESR plug-in used in enterprise environments (r204461)
• Changed instantiation of WebKit plug-ins to happen at layout time, instead of at style resolution time (r204320)

## Feeds

Planet MathML features:

If you own a blog with a focus on MathML, and want to be added or removed from this aggregator, please get in touch with Bert Bos at bert@w3.org.