# 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: [mathonweb] CSS TF next meeting

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • February 19, 2018 • Permalink

Hi again,

Just to clarify, the task force meets on *Feb 26,* 3pm Eastern.

Again, if you want to join, send Dani or myself an email.

Best,
Peter.

2018-02-19 14:40 GMT+01:00 Peter Krautzberger <peter@krautzource.com>:

> Hi mathonweb,
>
> The CG's CSS task force will meet next Monday at 3pm Eastern.
>
> If you want to join the task force, please send a quick email off-list to
> Dani or myself.
>
> Best,
> Peter.
>


## [mathonweb] CSS TF next meeting

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • February 19, 2018 • Permalink

Hi mathonweb,

The CG's CSS task force will meet next Monday at 3pm Eastern.

If you want to join the task force, please send a quick email off-list to
Dani or myself.

Best,
Peter.


## Re: My htoughts

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • February 15, 2018 • Permalink

+1 on all points.

Best,
Peter.

2018-02-15 19:31 GMT+01:00 Daniel Marques <dani@wiris.com>:

> Hi everybody,
>
> I'm talking about ePub but the ideas are still valid for HTM:
>
>    1. It is up to the publisher to use MathML in their internal workflow.
>    A "source" ePub could have MathML (or LaTeX). Why not?
>    2. Publish ePub with HTML-css-webfonts and svg only (because MathML is
>    not ready and might never be).
>    3. Find a solution for accessibility and interoperability. There is
>    work here to be done. Here is where the compromises and common solutions
>    have to be taken, not at point 2.
>
> Other considerations
>
>    1. Publishers should be free to use JavaScript if they thing is a
>    solution or wants to use LaTeX or MathML inside the published ePub. As
>    comparison, is there anything that forbids the creation of <table>'s using
>    JavaScript inside an ePub?
>    2. Please, do not create a new standard because it will have the same
>    faults as MathML.
>    3. Again, a publisher should feel free to use Web Components for
>    representing mathematics.
>    4. Let MathML be as it is right now.
>
>
> Dani
>
> ------------------------------
> WIRIS and Design Science, makers of MathType, have joined forces!
> Thank you for your patience as we transition from dessci.com to wiris.com.
>


## My htoughts

Source: public-mathonwebpages@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • February 15, 2018 • Permalink

Hi everybody,

I'm talking about ePub but the ideas are still valid for HTM:

1. It is up to the publisher to use MathML in their internal workflow. A
"source" ePub could have MathML (or LaTeX). Why not?
2. Publish ePub with HTML-css-webfonts and svg only (because MathML is
not ready and might never be).
3. Find a solution for accessibility and interoperability. There is work
here to be done. Here is where the compromises and common solutions have to
be taken, not at point 2.

Other considerations

1. Publishers should be free to use JavaScript if they thing is a
solution or wants to use LaTeX or MathML inside the published ePub. As
comparison, is there anything that forbids the creation of <table>'s using
JavaScript inside an ePub?
2. Please, do not create a new standard because it will have the same
faults as MathML.
3. Again, a publisher should feel free to use Web Components for
representing mathematics.
4. Let MathML be as it is right now.

Dani

--

------------------------------
WIRIS and Design Science, makers of MathType, have joined forces!
Thank you for your patience as we transition from dessci.com to wiris.com.


## Re: Vertical alignment by a given child

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • February 15, 2018 • Permalink

Hi Dani,

The baseline seems to be slightly off (for me at least). I couldn't figure
out if this is a bug of some kind (browser, spec, font).

For comparison, [1] is an example for munderover that follows MathJax's
approach (using inline-table); this approach can't be used  for fractions
though.

Best,
Peter.

[1] https://codepen.io/pkra/pen/BYwBXB

2018-02-01 18:15 GMT+01:00 Daniel Marques <dani@wiris.com>:

> As promised, see examples at
> https://codepen.io/daniwiris/pen/JOqvpB
>
> where factions and munderover constructions are done using flexbox without
> any absolute positioning.
>
> Dani
>
> ------------------------------
> WIRIS and Design Science, makers of MathType, have joined forces!
> Thank you for your patience as we transition from dessci.com to wiris.com.
>


## reminder: meeting Feb 15, 2018, 12pm Eastern Time

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • February 14, 2018 • Permalink

Hi everyone,

Just a quick reminder that we're meeting this week.

As (by now) usual, we're meeting on Hangouts at [1]; I'll open the hangout
a few minutes before the meeting.

As for the agenda, we should catch up on open ACTION items (cf. below).

Best,
Peter.

* ACTIONs
* CSS
* Dani examples, Peter has started to look at WICG starter (but now
Dani's examples change things!)
* Arno's first review (stretchy) => let's continue, draft doc for CG
site
* Regular TF meeting
* @Arno write email about ideas for common abstract format needs
* @Arno more current practices for layout?
* @Peter follow with CSS WG on alignment at child
* @Neil still wants to post a CfC response


## MathJax v2.7.3 now available

Source: MathJax • February 08, 2018 • Permalink

We are happy to officially release MathJax v2.7.3 today.

This is mostly a bug-fix release, with a few enhancements as well.

The primary enhancement is the addition of version 2.3 of the Speech-Rule Engine that underlies the MathJax accessibility tools. This includes performance enhancements as well as a Spanish localization that is tied to the MathJax localization menu. In addition, the Explorer menu in the Assistive submenu has been slimmed down to remove unneeded options.

For details on all bug fixes and enhancements, please see below.

This release should be available on all CDN providers, e.g., https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.3/MathJax.js which you can load it in place of the version you are currently using (or load latest.js instead of Mathjax.js to get the latest version 2.x, whatever it is, but note that this loads asynchronously, so the MathJax global variable may not be available immediately).

Alternatively, you can get a ZIP archive or access the branch on GitHub.

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

### Input

• AsciiMath has been updated to include new features that have been added in the official AsciiMathML.js file since v2.7.2 was released.

• TeX: Remove balanceBraces option from tex2jax, which was never implemented (#1871)

• TeX: Make HTML id’s used in \tag handling more robust (#1899)

• TeX: Make \DeclareMathOperator and \Newextarrow localizable by begingroup (#1876)

• TeX: Have \bigg and friends to trim spaces from their arguments (#1819)

• TeX: Don’t produce unwanted mrows with \left…\right (#1829)

### Output

• HTML-CSS: Improve detection of web fonts (#517)

• Improve line breaking past the container width when no break is found within it (#1883)

• SVG: Don’t lose pre-spacing in elements containing line breaks (#1915)

• CommonHTML: Fix width of roots containing line breaks (#1882)

• SVG: Measure sizes of annotation-xml elements properly (#1870)

• Handle default border width properly in SVG and HTML-CSS (#1855)

• CommonHTML: Reset character width if a reset occurs while an equation is being processed (#1837)

• CommonHTML: Properly scale widths in line breaking algorithm (#1881)

• HTML-CSS: Fix position of rightmost glyph in multi-glyph horizontal stretchy characters (#1896)

• MathML: Don’t add duplicate xmlns attribute when original is empty (#1862)

### Interface

• Decode hash URI component so it works with special characters (#1843)

## Re: [mathonweb] CG meeting 2018/02/01

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • February 01, 2018 • Permalink

Hi everyone,

Today's minutes.

Next meeting is Feb 15, noon EST.

Best,
Peter.

# Math On Web, Feb 1, 2018

* on call: Dani, Peter, Neil, Charles, Volker
* Dani: since we see each other in May for a11y workshop at AIM, perhaps
focus on a11y then
* focus on display (CSS etc) now
* => SOUNDS GOOD
* Dani: my opinion on CSS / display
* last year it may not seem like much output but learned a lot about
* a lot more is doable "properly"
* e.g., no more absolute positioning
* maybe still some hacks like stretchy but at least it works
* alignment for given child is also possible
* fraction, munderover
* Neil: Davide Cervone mentioned a few ideas for improvements on the last
MathJax TC call
* e.g., it would be good to have stretchies as decorations / borders
* e.g., dealing with italic skew in munderover
* Peter: talked to Arno about variable fonts off-list, looks like they
could be very useful
* maybe solves having multiple sizes of fence  + stretchy
* maybe solves horizontal stretch
* but we both think it won't help with vertical stretch
* yet?
* example:
https://www.typenetwork.com/brochure/decovar-a-decorative-variable-font-by-david-berlow/#?skelID=SA&skel=0.18&termID=TA&term=1
* Dani: example vertical alignment
* https://codepen.io/daniwiris/pen/JOqvpB
* munderover with flex:reverse-column, evne markup si
* mfrac is a bit less natural but still ok
* msubsup is ok, needs a filler
* colors are ok. stretchy brace by borders
* a11y conferences
* CSUN: Volker, Neil
* w4a: Volker, possibly Neil
* AIM workshop: all on call

* OLD ACTIONs
* CSS
* Dani examples, Peter has started to look at WICG starter (but now
Dani's examples change things!)
* Arno's first review (stretchy) => let's continue, draft doc for CG
site
* @Arno write email about ideas for common abstract format needs
* new:
* @Arno more current practices for layout?
* @Peter follow with CSS WG on alignment at child
* @Neil to respond to call for comments

2018-02-01 18:00 GMT+01:00 Peter Krautzberger <peter@krautzource.com>:

> Hi everyone,
>
> Below is the link to the hangout for the meeting. It's now open.
>
> Best,
> Peter.
>
>


## Vertical alignment by a given child

Source: public-mathonwebpages@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • February 01, 2018 • Permalink

As promised, see examples at
https://codepen.io/daniwiris/pen/JOqvpB

where factions and munderover constructions are done using flexbox without
any absolute positioning.

Dani

--

------------------------------
WIRIS and Design Science, makers of MathType, have joined forces!
Thank you for your patience as we transition from dessci.com to wiris.com.


## [mathonweb] CG meeting 2018/02/01

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • February 01, 2018 • Permalink

Hi everyone,

Below is the link to the hangout for the meeting. It's now open.

Best,
Peter.



## Re: [MathOnWeb] Peter K's comments on directions for 2018

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • January 29, 2018 • Permalink

Thank you, Ivan.

Best,
Peter.

On Jan 29, 2018 15:52, "Ivan Herman" <ivan@w3.org> wrote:

> No problems.
>
> Ivan
>
> On 29 Jan 2018, at 15:49, Peter Krautzberger <peter@krautzource.com>
> wrote:
>
> Hi Ivan,
>
> I'm sorry about my previous message. I've grown very frustrated trying to
> respond on this thread as I seem unable to make myself understood and I
> seem unable to understand your position.
>
> However, my last email was simply rude for which I apologize. It does not
> represent the way I wish to communicate on this list or elsewhere; I will
> do better in the future.
>
> With best regards,
> Peter.
>
> 2018-01-27 17:39 GMT+01:00 Peter Krautzberger <peter@krautzource.com>:
>
>> Hi Ivan,
>>
>> It's difficult to reply as there are many details in your message that
>> are off, uninformed or incorrect.
>>
>> I think we fundamentally do not understand each other; we do not
>> understand how each of us views the current state of affairs, the available
>> tools and standards, what each of us considers to be problems see or how to
>> try to resolve them.
>>
>> So I cannot even agree to disagree as it would presume an understanding
>> of each other's position.
>>
>> Peter.
>>
>>
>>
>>
>> 2018-01-26 13:41 GMT+01:00 Ivan Herman <ivan@w3.org>:
>>
>>> Hi Peter,
>>>
>>> indeed, we do not seem to find a common ground:-( so let us try again.
>>> Reset (symbolically, I removed all the previous threads from this mail:-).
>>>
>>> The discussion started with your statement whereby you think MathML
>>> should be removed from HTML. What I was trying to understand is what you
>>> would replace it with. Put it another way, if there is no MathML in HTML,
>>> what is the vision of displaying math in a Web page?
>>>
>>> What I could *gather* from your replies and also some of our earlier
>>> discussions is that, in your view:
>>>
>>> 1. Authors should use *some* tools (authoring tools, AI, simple screen
>>> editors, whatever) to author/describe their math content. Let thousands of
>>> tools bloom.
>>> 2. Some process, possibly bound to these tools, would turn, on the
>>> server side, these formulae into HTML+CSS+SVG content and incorporate those
>>> directly into the overall HTML of the enclosing Web page. (Let us put
>>> issues of accessibility and interactivity aside for now.)
>>> 3. That web page then displays in the browser as usual and everybody is
>>> happy:-)
>>>
>>> MathML, in this view, is "reduced" (although that sounds pejorative,
>>> which is not my intention) to, e.g., publishing workflow usage, part of
>>> step (1) above, it can be used for interchange among mathematical systems,
>>> etc. And, in a way, that is also what happens often in practice, except
>>> that, instead of HTML+CSS+SVG, MathML content is turned into images.
>>>
>>> If this is indeed your vision, then it is obviously a radical departure
>>> from the current HTML+MathML approach. The fundamental difference, in my
>>> view, is that the math rendering happens on the client vs. the server side.
>>> And, I believe, that is also at the core of our disagreement: I am not
>>> convinced that this is the right architecture.
>>>
>>> I think we can agree that the CSS+HTML+SVG "encoding" (let me call it
>>> this way) for a mathematical formula is extremely verbose. You guys have
>>> much more data on this than I would ever have, but I believe my gut feeling
>>> is correct. That means the load will be on the amount of data transferred
>>> to the client over the wire; that may very well become a major bottleneck.
>>> The processing power of clients is, after all, getting huge and I do not
>>> see that evolution slowing down; the speed of the network is far from
>>> following that pace. There are other problems with this architecture (eg, I
>>> am a bit worried about the extreme proliferation of different tools and
>>> conversion engines) but that is the essential one.
>>>
>>> What it means is that I still believe the fundamental architecture of
>>> the current HTML+MathML is right: use a succinct representation of
>>> mathematics on the wire and let the client do the job. Hence the necessity,
>>> again in my view, of having such succinct representation as a standard.
>>>
>>> Now... we know there are problems, to say the least, with the
>>> practicalities today. And it may well be that MathML does not hit the right
>>> target in making that architecture viable. For example, one of the comments
>>> I often get is that MathML is aiming way too high: the goal is to be able
>>> to represent PhD level mathematics, whereas, on the Web, the mass
>>> publication would what our American friends call K12 or even elementary
>>> mathematics. Ie, maybe the current approach should be changed by replacing
>>> MathML with something simpler. Also, the implementation strategies used so
>>> far may not have been not the good ones, because they did not use CSS & co
>>> properly. Etc. And, probably, the two architectures will have to coexist
>>> side-by-side and we have to understand the details. So yes, the current
>>> situation does need improvement.
>>>
>>> Do we at least agree where we disagree?
>>>
>>> Ivan
>>>
>>> P.S. You realized that I did not use the L-word, right? :-)
>>>
>>> ----
>>> Ivan Herman, W3C
>>> Home: http://www.w3.org/People/Ivan/
>>> mobile: +31-641044153 <+31%206%2041044153>
>>> ORCID ID: http://orcid.org/0000-0003-0782-2704
>>>
>>>
>>
>
>
> ----
> Ivan Herman, W3C
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153 <+31%206%2041044153>
> ORCID ID: http://orcid.org/0000-0003-0782-2704
>
>


## Re: [MathOnWeb] Peter K's comments on directions for 2018

Source: public-mathonwebpages@w3.org Mail Archives • Ivan Herman (ivan@w3.org) • January 29, 2018 • Permalink

No problems.

Ivan

> On 29 Jan 2018, at 15:49, Peter Krautzberger <peter@krautzource.com <mailto:peter@krautzource.com>> wrote:
>
> Hi Ivan,
>
> I'm sorry about my previous message. I've grown very frustrated trying to respond on this thread as I seem unable to make myself understood and I seem unable to understand your position.
>
> However, my last email was simply rude for which I apologize. It does not represent the way I wish to communicate on this list or elsewhere; I will do better in the future.
>
> With best regards,
> Peter.
>
> 2018-01-27 17:39 GMT+01:00 Peter Krautzberger <peter@krautzource.com <mailto:peter@krautzource.com>>:
> Hi Ivan,
>
> It's difficult to reply as there are many details in your message that are off, uninformed or incorrect.
>
> I think we fundamentally do not understand each other; we do not understand how each of us views the current state of affairs, the available tools and standards, what each of us considers to be problems see or how to try to resolve them.
>
> So I cannot even agree to disagree as it would presume an understanding of each other's position.
>
> Peter.
>
>
>
>
> 2018-01-26 13:41 GMT+01:00 Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>>:
> Hi Peter,
>
> indeed, we do not seem to find a common ground:-( so let us try again. Reset (symbolically, I removed all the previous threads from this mail:-).
>
> The discussion started with your statement whereby you think MathML should be removed from HTML. What I was trying to understand is what you would replace it with. Put it another way, if there is no MathML in HTML, what is the vision of displaying math in a Web page?
>
> What I could gather from your replies and also some of our earlier discussions is that, in your view:
>
> 1. Authors should use some tools (authoring tools, AI, simple screen editors, whatever) to author/describe their math content. Let thousands of tools bloom.
> 2. Some process, possibly bound to these tools, would turn, on the server side, these formulae into HTML+CSS+SVG content and incorporate those directly into the overall HTML of the enclosing Web page. (Let us put issues of accessibility and interactivity aside for now.)
> 3. That web page then displays in the browser as usual and everybody is happy:-)
>
> MathML, in this view, is "reduced" (although that sounds pejorative, which is not my intention) to, e.g., publishing workflow usage, part of step (1) above, it can be used for interchange among mathematical systems, etc. And, in a way, that is also what happens often in practice, except that, instead of HTML+CSS+SVG, MathML content is turned into images.
>
> If this is indeed your vision, then it is obviously a radical departure from the current HTML+MathML approach. The fundamental difference, in my view, is that the math rendering happens on the client vs. the server side. And, I believe, that is also at the core of our disagreement: I am not convinced that this is the right architecture.
>
> I think we can agree that the CSS+HTML+SVG "encoding" (let me call it this way) for a mathematical formula is extremely verbose. You guys have much more data on this than I would ever have, but I believe my gut feeling is correct. That means the load will be on the amount of data transferred to the client over the wire; that may very well become a major bottleneck. The processing power of clients is, after all, getting huge and I do not see that evolution slowing down; the speed of the network is far from following that pace. There are other problems with this architecture (eg, I am a bit worried about the extreme proliferation of different tools and conversion engines) but that is the essential one.
>
> What it means is that I still believe the fundamental architecture of the current HTML+MathML is right: use a succinct representation of mathematics on the wire and let the client do the job. Hence the necessity, again in my view, of having such succinct representation as a standard.
>
> Now... we know there are problems, to say the least, with the practicalities today. And it may well be that MathML does not hit the right target in making that architecture viable. For example, one of the comments I often get is that MathML is aiming way too high: the goal is to be able to represent PhD level mathematics, whereas, on the Web, the mass publication would what our American friends call K12 or even elementary mathematics. Ie, maybe the current approach should be changed by replacing MathML with something simpler. Also, the implementation strategies used so far may not have been not the good ones, because they did not use CSS & co properly. Etc. And, probably, the two architectures will have to coexist side-by-side and we have to understand the details. So yes, the current situation does need improvement.
>
> Do we at least agree where we disagree?
>
> Ivan
>
> P.S. You realized that I did not use the L-word, right? :-)
>
> ----
> Ivan Herman, W3C
> Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
> mobile: +31-641044153 <tel:+31%206%2041044153>
> ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>
>
>
>

----
Ivan Herman, W3C
Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>



## Re: [MathOnWeb] Peter K's comments on directions for 2018

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • January 29, 2018 • Permalink

Hi Ivan,

I'm sorry about my previous message. I've grown very frustrated trying to
respond on this thread as I seem unable to make myself understood and I
seem unable to understand your position.

However, my last email was simply rude for which I apologize. It does not
represent the way I wish to communicate on this list or elsewhere; I will
do better in the future.

With best regards,
Peter.

2018-01-27 17:39 GMT+01:00 Peter Krautzberger <peter@krautzource.com>:

> Hi Ivan,
>
> It's difficult to reply as there are many details in your message that are
> off, uninformed or incorrect.
>
> I think we fundamentally do not understand each other; we do not
> understand how each of us views the current state of affairs, the available
> tools and standards, what each of us considers to be problems see or how to
> try to resolve them.
>
> So I cannot even agree to disagree as it would presume an understanding of
> each other's position.
>
> Peter.
>
>
>
>
> 2018-01-26 13:41 GMT+01:00 Ivan Herman <ivan@w3.org>:
>
>> Hi Peter,
>>
>> indeed, we do not seem to find a common ground:-( so let us try again.
>> Reset (symbolically, I removed all the previous threads from this mail:-).
>>
>> The discussion started with your statement whereby you think MathML
>> should be removed from HTML. What I was trying to understand is what you
>> would replace it with. Put it another way, if there is no MathML in HTML,
>> what is the vision of displaying math in a Web page?
>>
>> What I could *gather* from your replies and also some of our earlier
>> discussions is that, in your view:
>>
>> 1. Authors should use *some* tools (authoring tools, AI, simple screen
>> editors, whatever) to author/describe their math content. Let thousands of
>> tools bloom.
>> 2. Some process, possibly bound to these tools, would turn, on the server
>> side, these formulae into HTML+CSS+SVG content and incorporate those
>> directly into the overall HTML of the enclosing Web page. (Let us put
>> issues of accessibility and interactivity aside for now.)
>> 3. That web page then displays in the browser as usual and everybody is
>> happy:-)
>>
>> MathML, in this view, is "reduced" (although that sounds pejorative,
>> which is not my intention) to, e.g., publishing workflow usage, part of
>> step (1) above, it can be used for interchange among mathematical systems,
>> etc. And, in a way, that is also what happens often in practice, except
>> that, instead of HTML+CSS+SVG, MathML content is turned into images.
>>
>> If this is indeed your vision, then it is obviously a radical departure
>> from the current HTML+MathML approach. The fundamental difference, in my
>> view, is that the math rendering happens on the client vs. the server side.
>> And, I believe, that is also at the core of our disagreement: I am not
>> convinced that this is the right architecture.
>>
>> I think we can agree that the CSS+HTML+SVG "encoding" (let me call it
>> this way) for a mathematical formula is extremely verbose. You guys have
>> much more data on this than I would ever have, but I believe my gut feeling
>> is correct. That means the load will be on the amount of data transferred
>> to the client over the wire; that may very well become a major bottleneck.
>> The processing power of clients is, after all, getting huge and I do not
>> see that evolution slowing down; the speed of the network is far from
>> following that pace. There are other problems with this architecture (eg, I
>> am a bit worried about the extreme proliferation of different tools and
>> conversion engines) but that is the essential one.
>>
>> What it means is that I still believe the fundamental architecture of the
>> current HTML+MathML is right: use a succinct representation of mathematics
>> on the wire and let the client do the job. Hence the necessity, again in my
>> view, of having such succinct representation as a standard.
>>
>> Now... we know there are problems, to say the least, with the
>> practicalities today. And it may well be that MathML does not hit the right
>> target in making that architecture viable. For example, one of the comments
>> I often get is that MathML is aiming way too high: the goal is to be able
>> to represent PhD level mathematics, whereas, on the Web, the mass
>> publication would what our American friends call K12 or even elementary
>> mathematics. Ie, maybe the current approach should be changed by replacing
>> MathML with something simpler. Also, the implementation strategies used so
>> far may not have been not the good ones, because they did not use CSS & co
>> properly. Etc. And, probably, the two architectures will have to coexist
>> side-by-side and we have to understand the details. So yes, the current
>> situation does need improvement.
>>
>> Do we at least agree where we disagree?
>>
>> Ivan
>>
>> P.S. You realized that I did not use the L-word, right? :-)
>>
>> ----
>> Ivan Herman, W3C
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153 <+31%206%2041044153>
>> ORCID ID: http://orcid.org/0000-0003-0782-2704
>>
>>
>


## Re: [math-on-web] CG meeting minutes, 2018/01/18

Source: public-mathonwebpages@w3.org Mail Archives • Arno Gourdol (arno.gourdol@gmail.com) • January 28, 2018 • Permalink

>
>> - is the height of the container that needs to be surround by the fence, within certain margins?
>> - if so, use a single glyph representing the fence: U+007d "{"
>> - if the height is above those bounds, create a "stacked" fenced, by putting a glyph at the top U+23a7 "⎧", a glyph at the bottom U+23a9 "⎩", a glyph in the middle U+23a8 "⎨" and for the rest of it, a "repeating" glyph, U+23aa "⎪" (and so on for all the different types of fences)
> Before choosing a way to proceed, I tried to understand how TeX works. There is several prebuilt sizes of each fence (3 ou 4). TeX first tries to use these sizes and if it needs hiegher, TeX builts the "stacked" fenced as you discribed. But what about italic and other orientations ! ?

“Stacking” is also performed for horizontal fences in the same way. Fences in traditional mathematical typography are not displayed differently in italic. See [1] for example.

> So,I wonder why nobody tried to sent a simple font file with the right sized glyph draw to the glyph engine (Harfbuzz or other) as TeX but for each sizes and not only for the first four.

Because the notion of “font size” for a glyph engine usually is centered around the “em box”, which glyph of a font are drawn (somewhat) into. It doesn’t say anything about drawing a glyph so that the distance between the first and the last pixel of a glyph is a specific value, which is what you would want for stretched ascenders.

> I think that drawing a bracket as a curve is simpliest and economics than the algorithm that puts glyphs over other glyphs.

Indeed, it is simpler, however it does not follow the traditions of mathematical typography. In particular, consider that fences for a latin sans-serif font look distinct from a serif font. So, for the best possibly mathematical typography, it is better to use the glyph information provided by the font file. Note that OpenType math fonts include a MathVariants table that specify how to correctly draw stretched glyphs. [2] It would be advantageous if the HTML/CSS layout engines made use of this information when available.

[1] http://www.shearsoneditorial.com/2012/07/typographical-conventions-for-mathematics/ <http://www.shearsoneditorial.com/2012/07/typographical-conventions-for-mathematics/>
[2] https://www.microsoft.com/typography/otspec/math.htm <https://www.microsoft.com/typography/otspec/math.htm>


## Re: [MathOnWeb] Peter K's comments on directions for 2018

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • January 27, 2018 • Permalink

Hi Ivan,

It's difficult to reply as there are many details in your message that are
off, uninformed or incorrect.

I think we fundamentally do not understand each other; we do not understand
how each of us views the current state of affairs, the available tools and
standards, what each of us considers to be problems see or how to try to
resolve them.

So I cannot even agree to disagree as it would presume an understanding of
each other's position.

Peter.

2018-01-26 13:41 GMT+01:00 Ivan Herman <ivan@w3.org>:

> Hi Peter,
>
> indeed, we do not seem to find a common ground:-( so let us try again.
> Reset (symbolically, I removed all the previous threads from this mail:-).
>
> The discussion started with your statement whereby you think MathML should
> be removed from HTML. What I was trying to understand is what you would
> replace it with. Put it another way, if there is no MathML in HTML, what is
> the vision of displaying math in a Web page?
>
> What I could *gather* from your replies and also some of our earlier
> discussions is that, in your view:
>
> 1. Authors should use *some* tools (authoring tools, AI, simple screen
> editors, whatever) to author/describe their math content. Let thousands of
> tools bloom.
> 2. Some process, possibly bound to these tools, would turn, on the server
> side, these formulae into HTML+CSS+SVG content and incorporate those
> directly into the overall HTML of the enclosing Web page. (Let us put
> issues of accessibility and interactivity aside for now.)
> 3. That web page then displays in the browser as usual and everybody is
> happy:-)
>
> MathML, in this view, is "reduced" (although that sounds pejorative, which
> is not my intention) to, e.g., publishing workflow usage, part of step (1)
> above, it can be used for interchange among mathematical systems, etc. And,
> in a way, that is also what happens often in practice, except that, instead
> of HTML+CSS+SVG, MathML content is turned into images.
>
> If this is indeed your vision, then it is obviously a radical departure
> from the current HTML+MathML approach. The fundamental difference, in my
> view, is that the math rendering happens on the client vs. the server side.
> And, I believe, that is also at the core of our disagreement: I am not
> convinced that this is the right architecture.
>
> I think we can agree that the CSS+HTML+SVG "encoding" (let me call it this
> way) for a mathematical formula is extremely verbose. You guys have much
> more data on this than I would ever have, but I believe my gut feeling is
> correct. That means the load will be on the amount of data transferred to
> the client over the wire; that may very well become a major bottleneck. The
> processing power of clients is, after all, getting huge and I do not see
> that evolution slowing down; the speed of the network is far from following
> that pace. There are other problems with this architecture (eg, I am a bit
> worried about the extreme proliferation of different tools and conversion
> engines) but that is the essential one.
>
> What it means is that I still believe the fundamental architecture of the
> current HTML+MathML is right: use a succinct representation of mathematics
> on the wire and let the client do the job. Hence the necessity, again in my
> view, of having such succinct representation as a standard.
>
> Now... we know there are problems, to say the least, with the
> practicalities today. And it may well be that MathML does not hit the right
> target in making that architecture viable. For example, one of the comments
> I often get is that MathML is aiming way too high: the goal is to be able
> to represent PhD level mathematics, whereas, on the Web, the mass
> publication would what our American friends call K12 or even elementary
> mathematics. Ie, maybe the current approach should be changed by replacing
> MathML with something simpler. Also, the implementation strategies used so
> far may not have been not the good ones, because they did not use CSS & co
> properly. Etc. And, probably, the two architectures will have to coexist
> side-by-side and we have to understand the details. So yes, the current
> situation does need improvement.
>
> Do we at least agree where we disagree?
>
> Ivan
>
> P.S. You realized that I did not use the L-word, right? :-)
>
> ----
> Ivan Herman, W3C
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153 <+31%206%2041044153>
> ORCID ID: http://orcid.org/0000-0003-0782-2704
>
>


## Re: [math-on-web] CG meeting minutes, 2018/01/18

Source: public-mathonwebpages@w3.org Mail Archives • info@scientificware.com (info@scientificware.com) • January 27, 2018 • Permalink



Hi Arno,

> ​That's an interesting use case. It might take a while to get there, given that SMS doesn't even support bold text, but a good use case to keep in mind. It might be easier to get support in other messaging platforms before SMS (SMS is tied to telecom standards that are slow to evolve).

By SMS, I mean, to use only its sequence of characters and to display it
in a specific SMS Messenger. I agree with you that telecom standarts are
slow to evolve that's why we need a specific messenger.

> The status of JavaFX is a bit murky, but OpenJDK might be a way to contribute. I also note that the issue above has 0 votes. Furthermore, the issue seems to be with the MathML support in the host browsers, so really, until the host browsers (Chrome, Safari, IE) support MathML natively, the chances of seeing a fix for this bug are low.

I wrote "JavaFX", but in fact, I mean "OpenJFX" its open source version.
OpenJFX includes a web browser "WebView" built over webkit that's why it
supports MathML.
(https://docs.oracle.com/javase/9/docs/api/index.html?overview-summary.html)

But I don't understand why with the same webkit version, it works well
on Safari and not on OpenJFX. As suggested by team OpenJFX leader,
(http://mail.openjdk.java.net/pipermail/openjfx-dev/2017-December/021113.html)
I tried to see where is the problem, but it's not pure Java and build
OpenJFX is a bit difficult than build OpenJDK.

> - is the height of the container that needs to be surround by the fence, within certain margins?
> - if so, use a single glyph representing the fence: U+007d "{"
> - if the height is above those bounds, create a "stacked" fenced, by putting a glyph at the top U+23a7 "⎧", a glyph at the bottom U+23a9 "⎩", a glyph in the middle U+23a8 "⎨" and for the rest of it, a "repeating" glyph, U+23aa "⎪" (and so on for all the different types of fences)
Before choosing a way to proceed, I tried to understand how TeX works.
There is several prebuilt sizes of each fence (3 ou 4). TeX first tries
to use these sizes and if it needs hiegher, TeX builts the "stacked"
fenced as you discribed. But what about italic and other orientations !
?
So,I wonder why nobody tried to sent a simple font file with the right
sized glyph draw to the glyph engine (Harfbuzz or other) as TeX but for
each sizes and not only for the first four.
I think that drawing a bracket as a curve is simpliest and economics
than the algorithm that puts glyphs over other glyphs.
That's the way I choose to proceed, I directly draw "{", "(" and "[".
The inconvenience, is that I have to create them by hand and then to
draw them but without use the glyph engine (a bit complicate for me
because I don't know how to built a font file). Fortunately Java can
draw it easily. The advantage, I have got symetric, italic and
horizontal glyphs too, with the same curve.

Best regards.

Guy.



## Re: [MathOnWeb] Peter K's comments on directions for 2018

Source: public-mathonwebpages@w3.org Mail Archives • Ivan Herman (ivan@w3.org) • January 26, 2018 • Permalink

Hi Peter,

indeed, we do not seem to find a common ground:-( so let us try again. Reset (symbolically, I removed all the previous threads from this mail:-).

The discussion started with your statement whereby you think MathML should be removed from HTML. What I was trying to understand is what you would replace it with. Put it another way, if there is no MathML in HTML, what is the vision of displaying math in a Web page?

What I could gather from your replies and also some of our earlier discussions is that, in your view:

1. Authors should use some tools (authoring tools, AI, simple screen editors, whatever) to author/describe their math content. Let thousands of tools bloom.
2. Some process, possibly bound to these tools, would turn, on the server side, these formulae into HTML+CSS+SVG content and incorporate those directly into the overall HTML of the enclosing Web page. (Let us put issues of accessibility and interactivity aside for now.)
3. That web page then displays in the browser as usual and everybody is happy:-)

MathML, in this view, is "reduced" (although that sounds pejorative, which is not my intention) to, e.g., publishing workflow usage, part of step (1) above, it can be used for interchange among mathematical systems, etc. And, in a way, that is also what happens often in practice, except that, instead of HTML+CSS+SVG, MathML content is turned into images.

If this is indeed your vision, then it is obviously a radical departure from the current HTML+MathML approach. The fundamental difference, in my view, is that the math rendering happens on the client vs. the server side. And, I believe, that is also at the core of our disagreement: I am not convinced that this is the right architecture.

I think we can agree that the CSS+HTML+SVG "encoding" (let me call it this way) for a mathematical formula is extremely verbose. You guys have much more data on this than I would ever have, but I believe my gut feeling is correct. That means the load will be on the amount of data transferred to the client over the wire; that may very well become a major bottleneck. The processing power of clients is, after all, getting huge and I do not see that evolution slowing down; the speed of the network is far from following that pace. There are other problems with this architecture (eg, I am a bit worried about the extreme proliferation of different tools and conversion engines) but that is the essential one.

What it means is that I still believe the fundamental architecture of the current HTML+MathML is right: use a succinct representation of mathematics on the wire and let the client do the job. Hence the necessity, again in my view, of having such succinct representation as a standard.

Now... we know there are problems, to say the least, with the practicalities today. And it may well be that MathML does not hit the right target in making that architecture viable. For example, one of the comments I often get is that MathML is aiming way too high: the goal is to be able to represent PhD level mathematics, whereas, on the Web, the mass publication would what our American friends call K12 or even elementary mathematics. Ie, maybe the current approach should be changed by replacing MathML with something simpler. Also, the implementation strategies used so far may not have been not the good ones, because they did not use CSS & co properly. Etc. And, probably, the two architectures will have to coexist side-by-side and we have to understand the details. So yes, the current situation does need improvement.

Do we at least agree where we disagree?

Ivan

P.S. You realized that I did not use the L-word, right? :-)

----
Ivan Herman, W3C
Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>



## Re: [math-on-web] CG meeting minutes, 2018/01/18

Source: public-mathonwebpages@w3.org Mail Archives • Arno Gourdol (arno@arno.org) • January 26, 2018 • Permalink

I try to follow your discussions. I wanted to post a small commentary to
> try to progress. I hope not to disturb this exchange thread.
>

​Thank you for participating!​

> The mathematic notation on web and others support like mails ou sms are
> the user adoption. I'm a teacher and my dream is to exchange mathematic SMS
> with collegues or students.
>

​That's an interesting use case. It might take a while to get there, given
that SMS doesn't even support bold text, but a good use case to keep in
mind. It might be easier to get support in other messaging platforms before
SMS (SMS is tied to telecom standards that are slow to evolve).

> On my authoring tool that I try to developp, I realised that I need three
> interfaces :
> - An user interface : "Write As You Speak or Heard", "3 times 12" in
> english, "3 fois 12" in french, ... . I think this is the only way to be
> - An internal interface to display or save formula : MathML presentation
> markup or Latex.
> - And finaly an other internal interface to exchange formula with other
> applications : MathML content markup.
>
​Yes, I think that makes sense and potentially goes to show that different
representations are useful for different purposes.​

Common Users don't have to deal with complex Markup and we need them to
> generalise mathematic on web : JavaFX support MathML but the display has
> been broken since 7 ans. The developpment team answer me that it not a
> priority bug !
>
> https://bugs.openjdk.java.net/browse/JDK-8147476
>
​In open source projects, "not a priority" often means "nobody volunteered
to do the work that would be required".​ The status of JavaFX is a bit
murky, but OpenJDK might be a way to contribute. I also note that the issue
above has 0 votes. Furthermore, the issue seems to be with the MathML
support in the host browsers, so really, until the host browsers (Chrome,
Safari, IE) support MathML natively, the chances of seeing a fix for this
bug are low.

I have a dream, I hope that one day, many angry user mails will change this
> :-)
>
​In my experience, angry emails directed at open source project
contributors rarely result in forward motion. I would suggest some
alternatives: propose a new spec, or a modification to an existing spec,
contribute by giving input and feedback on existing proposals that have
been put forward, contribute code implementing the proposed spec, or
contribute test cases.

One thing to consider: the more complicated a spec is to implement, the
less likely it is to be implemented. Every contributor to a project has to
make am evaluation of the benefit vs. the cost of investing time and
resources in implementing something. Math is unfortunately something with a
relatively small audience (compare to say, text or images). Therefore, any
proposal that is high in cost, but only serve the relatively narrow use
case of math, will have difficulty in getting traction. I'm afraid that
this is where we are with MathML adoption in browsers. I would suggest, and
I think there might be consensus in this group, that we would be better
served by proposing enhancements/improvements to existing standards that
would both be easier to implement, and that would also serve broader use
cases. Stretched fences being a good example of this.

Displaying streching characters is also a problem. I found that Java/Swing
> solution was interresting. In some configurations it's allow to mixed
> glyphs from fonts and user glyph drawing. In fact all glyphs are curves, we
> can use a specific application (like Harfbuzz) to draw it or draw "by hand"
> for complexe glyph. I don't understand why nobody achieved to extend Donald
> Knuth approch with TextFont.
>
​I think you mean MetaFont? In fact, existing standards do have the same
support than MetaFont does. In fact, they were "inspired" by what MetaFont

As you discribe it, most of rendering mathematic application use different
> font sizes first and many glyphs for higher characters (exactly as Knuth
> several years ago). But computers speed is faster than in the past and we
> should be able to draw directly stretching glyphs.
>
​I don't believe that the support for stretchable fences require support in
fonts or font standards. Fonts, and the standards related to drawing the
glyphs they contain, only concern themselves with relatively simple
(compared to what's require for math typography) composition of glyphs. In
particular, for a stretched fence, for a multi-row matrix for example, you
need to be able to specify a precise height that the fence should have,
that is, the height of the container of the matrix "data". You can't really
do that with a font, or with a font API. Instead, you need to do some
higher level composition, which is more akin to layout. Note that this is
what TeX does. MetaFont does not have facilities to "draw" a stretched
fence. Instead, there is logic in TeX that goes something like this:
- is the height of the container that needs to be surround by the fence,
within certain margins?
- if so, use a single glyph representing the fence: U+007d "{"
- if the height is above those bounds, create a "stacked" fenced, by
putting a glyph at the top U+23a7 "⎧", a glyph at the bottom U+23a9 "⎩", a
glyph in the middle U+23a8 "⎨" and for the rest of it, a "repeating" glyph,
U+23aa "⎪" (and so on for all the different types of fences)

​I believe that all those operations should be performed by the HTML text
engine of the web browsers, via a CSS extension that would probably be
similar to the quote attribute. I should probably follow my own advice and

Best,
Arno.
​

> ------------------------------------------------------------
> ---------------------------------
>
> Le 2018-01-25 18:54, Peter Krautzberger a écrit :
>
> Hi everyone,
>
> The minutes are blow.
>
> The next meeting will be on Feb 1 and we will focus on kick-starting the
>
> Best,
> Peter.
>
> # MathOnWeb CG 2018-01-18
>
> * Volker: didn't write a comment; it would have been "let's not re-hash
> the same old discussions every week"
> * Dani: I think F2F will be best to sort some things out
> * Peter:
>   * review call for comments
>   * plan potential task forces for 2018
> * Neil: font improvements are interesting. Anyone interested?
>   * Volker:
>   * Arno: only have one font b/c I can't get access to metrics of fonts
>     * interesting beyond equations
>     * reference for other work?
>     * Peter: https://discourse.wicg.io/t/font-metrics-api/2417
>   * Neil: is Houdini alive?
>     * Peter: yes. Look up Tab Atkins
> * Dani: for equation display, I see two approaches
>   * 1) no JS. I.e., HTML+CSS
>   * 2) with JS. Then have to compute metrics
>   * Neil: right. metrics means client-Side JS
>     * Peter: though Houdini sits in between as it uses JS for new CSS,
> claims its path towards new CSS features
>   * Arno: editing obviously needs JS
>     * Think we need both and they might differ
>   *  Dani: agreed. It's just that it requires different task forces
>     * Peter: agreed, while I wished it wasn't the case
>       * ideally, client and server-side rendering would be identical
>   * Peter: @Dani so propose two task forces for client / server rendering?
>     * Dani: yes but I personally more on server-side
> * Peter: is there interest in purely client-side rendering (web
> components, Houdini)?
>   * Neil: I'd be interested but have no plans
>   * Peter: you might want to talk to the developer of fmath
> * Neil: promise to write a comment
> * Volker: interested in ARIA spec for navigation
>   * Dani: I'd be interested in that
> * Dani: if we can come up with a unified vision for mathematics, then we
> can try to bring that to TPAC for feedback
>   * Dani: we come across as divided
> * Neil: it would be good to take one piece of CSS and try to get wider
> support from web devs
>   * Peter: makes sense; it's what I've been trying to do and continue
> * Neil: stretchy characters might be another
>   * Peter: anyone interested?
> * Neil: strike-through might be another
>   * Arno: interested
> * Arno: my email had two CSS definitions
>   * stretchy
>   * menclose-like notations (crossing out etc)
> * Dani: I think we need to document how people are doing things right now
> * Peter: should we set up two meetings, both bi-weekly?
>   * ACTION send out test doodles
> * ACTION:
>   * @task forces: start gathering existing techniques
>   * @Arno write email about ideas for common abstract format needs
>
>
>
>


## Re: [mathonweb] interest in additional meetings with different time-slot

Source: public-mathonwebpages@w3.org Mail Archives • Physikerwelt (wiki@physikerwelt.de) • January 26, 2018 • Permalink

I think we should not open the can of worms to find another time slot.
According to my experience a fixed time slot works best for community
groups. I would not see a low number of participants as indicator for no
interest, but rather as trust in those who do participate.

Sorry for the signal;-)

Moritz

Am 25.01.2018 18:57 schrieb "Peter Krautzberger" <peter@krautzource.com>:

Hi everyone,

As discussed in the last meeting, we want to do a quick check on whether
the current meeting time is still the best compromise.

We currently meet: bi-weekly, Thursday, 12pm Eastern Time.

Please ping me (personally so as to avoid noise on the list) if you are
interested in

a) meeting at an earlier time of day
b) meeting at a later time of day

For example, we could have weekly meetings at alternating time slots to
accomodate more time zones.

Best,
Peter.


## Re: [math-on-web] CG meeting minutes, 2018/01/18

Source: public-mathonwebpages@w3.org Mail Archives • info@scientificware.com (info@scientificware.com) • January 25, 2018 • Permalink



Hi !

I try to follow your discussions. I wanted to post a small commentary to
try to progress. I hope not to disturb this exchange thread.

The mathematic notation on web and others support like mails ou sms are
the user adoption. I'm a teacher and my dream is to exchange mathematic
SMS with collegues or students.

On my authoring tool that I try to developp, I realised that I need
three interfaces :
- An user interface : "Write As You Speak or Heard", "3 times 12" in
english, "3 fois 12" in french, ... . I think this is the only way to be
- An internal interface to display or save formula : MathML presentation
markup or Latex.
- And finaly an other internal interface to exchange formula with other
applications : MathML content markup.

Common Users don't have to deal with complex Markup and we need them to
generalise mathematic on web : JavaFX support MathML but the display has
been broken since 7 ans. The developpment team answer me that it not a
priority bug !

https://bugs.openjdk.java.net/browse/JDK-8147476

I have a dream, I hope that one day, many angry user mails will change
this :-)

Displaying streching characters is also a problem. I found that
Java/Swing solution was interresting. In some configurations it's allow
to mixed glyphs from fonts and user glyph drawing. In fact all glyphs
are curves, we can use a specific application (like Harfbuzz) to draw it
or draw "by hand" for complexe glyph. I don't understand why nobody
achieved to extend Donald Knuth approch with TextFont. As you discribe
it, most of rendering mathematic application use different font sizes
first and many glyphs for higher characters (exactly as Knuth several
years ago). But computers speed is faster than in the past and we should
be able to draw directly stretching glyphs.

Guy.

---------------------------------------------------------------------------------------------

Le 2018-01-25 18:54, Peter Krautzberger a écrit :

> Hi everyone,
>
> The minutes are blow.
>
> The next meeting will be on Feb 1 and we will focus on kick-starting the task forces for 2018.
>
> Best,
> Peter.
>
> # MathOnWeb CG 2018-01-18
>
> * Volker: didn't write a comment; it would have been "let's not re-hash the same old discussions every week"
> * Dani: I think F2F will be best to sort some things out
> * Peter:
> * review call for comments
> * plan potential task forces for 2018
> * Neil: font improvements are interesting. Anyone interested?
> * Volker:
> * Arno: only have one font b/c I can't get access to metrics of fonts
> * interesting beyond equations
> * reference for other work?
> * Peter: https://discourse.wicg.io/t/font-metrics-api/2417 [1]
> * Neil: is Houdini alive?
> * Peter: yes. Look up Tab Atkins
> * Dani: for equation display, I see two approaches
> * 1) no JS. I.e., HTML+CSS
> * 2) with JS. Then have to compute metrics
> * Neil: right. metrics means client-Side JS
> * Peter: though Houdini sits in between as it uses JS for new CSS, claims its path towards new CSS features
> * Arno: editing obviously needs JS
> * Think we need both and they might differ
> * Dani: agreed. It's just that it requires different task forces
> * Peter: agreed, while I wished it wasn't the case
> * ideally, client and server-side rendering would be identical
> * Peter: @Dani so propose two task forces for client / server rendering?
> * Dani: yes but I personally more on server-side
> * Peter: is there interest in purely client-side rendering (web components, Houdini)?
> * Neil: I'd be interested but have no plans
> * Peter: you might want to talk to the developer of fmath
> * Neil: promise to write a comment
> * Volker: interested in ARIA spec for navigation
> * Dani: I'd be interested in that
> * Dani: if we can come up with a unified vision for mathematics, then we can try to bring that to TPAC for feedback
> * Dani: we come across as divided
> * Neil: it would be good to take one piece of CSS and try to get wider support from web devs
> * Peter: makes sense; it's what I've been trying to do and continue
> * Neil: stretchy characters might be another
> * Peter: anyone interested?
> * Neil: strike-through might be another
> * Arno: interested
> * Arno: my email had two CSS definitions
> * stretchy
> * menclose-like notations (crossing out etc)
> * Dani: I think we need to document how people are doing things right now
> * Peter: should we set up two meetings, both bi-weekly?
> * ACTION send out test doodles
> * ACTION:
> * @task forces: start gathering existing techniques
> * @Arno write email about ideas for common abstract format needs

------
[1] https://discourse.wicg.io/t/font-metrics-api/2417


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