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

## [MathOnWeb] CANCEL meeting Nov 23, 2017

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • November 23, 2017 • Permalink

Hi everyone,

Due to Thanksgiving in the US, we'll skip the meeting this week.

Best,
Peter.


## Re: [MathOnWeb] CANCEL meeting Nov 9, 2017

Source: public-mathonwebpages@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • November 23, 2017 • Permalink

Hi,

Tomorrow is Thanksgivings in the USA. I won't be able to attend the meeting
since I'm out camping.

Dani

On Wed, Nov 8, 2017 at 10:01 AM, Peter Krautzberger <peter@krautzource.com>
wrote:

> Hi everybody,
>
> With TPAC ongoing and various people traveling, we've decided to cancel
> this week's meeting.
>
> Best regards,
> Peter and 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.


## Igalia launches a project to fund MathML in Chromium

Source: W3C Math Home • November 20, 2017 • Permalink

Igalia launches a project to fund MathML in Chromium

## [MathOnWeb] CANCEL meeting Nov 9, 2017

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • November 08, 2017 • Permalink

Hi everybody,

With TPAC ongoing and various people traveling, we've decided to cancel
this week's meeting.

Best regards,
Peter and Dani.


## Re: Polyfill and meeting

Source: public-mathonwebpages@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • November 02, 2017 • Permalink

Hi Neil,

I created some *academic *tests at https://codepen.io/daniwiris/pen/ooXmov
to study how to use flex-boxes.

Then, I created more practical example with a formula:
https://codepen.io/daniwiris/pen/bYERoL

Both tested in Firefox, Chrome, IE and Edge.

The only thing I miss is to be able to select which row to use for baseline
alignment when a column based flex-box is inside a row based flex-box. I'm
still planning to talk to Alan Steams. Any other suggestion?

Dani

On Mon, Oct 30, 2017 at 8:07 PM, Neil Soiffer <soiffer@alum.mit.edu> wrote:

> FYI:  CSS Flexible Box Layout Module Level 1
> <https://www.w3.org/TR/2017/CR-css-flexbox-1-20171019/#align-content-property>
> just announced call for implementations. Anything in there of use for
> alignment or otherwise? If something is missing, it's getting late in the
> game to suggest a missing feature for flex boxes, but with a good
> justification, you never know.
>
>     Neil
>
>
>
> www.avg.com
>
> On Mon, Oct 30, 2017 at 3:09 PM, Daniel Marques <dani@wiris.com> wrote:
>
>> Hi,
>>
>>
>> Just uploaded the examples at https://codepen.io/daniwiris/p
>> roject/editor/ZWbYxB .
>>
>>
>> My first thought was to extend the CSS style vertical-align. But then, I
>> changed my mind in favor of the CSS style baseline-shift (
>> https://www.w3.org/TR/css-inline-3/#baseline-shift-property). That’s
>> more powerful since, for example, it would be possible to combine
>> vertical-align="mathematical" with baseline-shift.
>>
>>
>> In any case, I would like to sate the following objectives:
>>
>>
>>    1. To use only html5/css/web-fonts (no JavaScript) to display
>>    statically independent-target-device math (but also some physics and
>>    chemistry) simple-enough formulas. This means:
>>       1. To target a common subset of simple math formulas.
>>       2. To be robust to browser and OS change. Firefox, Chrome, Safari,
>>       Edge, ... Windows, Mac, Linux, iOs, Android, ...
>>       3. To be robust to scale. For example, device pixel ratio in
>>       retina display and browser zoom.
>>       4. To be robust to font family change within the same type of font
>>       (Arial, Helvetica or Lucida Sans). Changing from Arial to Courier New might
>>       not work so well.
>>       5. To be robust to font size change.
>>       6. It is fine to embed fonts for math symbols. Especially stretchy
>>       parts, including parts of roots.
>>    2. To be enough semanticaly rich for copying, pasting and providing
>>    accessibility.
>>    3. To be able to recompose a formula if any subpart of such formula
>>    is dynamically changed with the help of JavaScript. Because, if you are
>>    able to change subparts of a formula, it means that the device is using
>>    JavaScript anyway.
>>
>> Of course, the html5/css/web-fonts representation of a given formula can
>> be generated once programmatically. Since it must not depend on the target
>> device, it can be generated either in the server or in the browser. Once
>> such formula is created, the exactly same html is send to all devices.
>> eBooks will be published with static html formulas.
>>
>>
>> After giving many thoughts to the topic I realized that current HTML
>> technology has already solved problem 1. Maybe one possible task of the
>> MathOnWebPages CG could be to explain how to do it. In a form of paper in a
>> conference? In a blog? A new project in Github?
>>
>>
>> For formulas that cannot be achieved with html5/css/web-fonts, let’s use
>> SVG. I don’t think it is possible to do all imaginable formulas with either
>> LaTeX or MathML. Remember that math are more than just formulas: plots,
>> graphs, movies…
>>
>>
>> The second objective is more ambitious. What I suggest is that we need to
>> markup the html in order to be able to recover the underlying math
>> structure. We are entering in the swampy zone of the semantics. I suggest a
>> lightweight semantics style like presentation-MathML on first place and,
>> optionally, add an extra layer of heavyweight semantics the way
>> content-MathML, Open Math or whatever format is decided.
>>
>>
>> It should be possible to add this layer of semantics also to a SVG image.
>>
>>
>> Dani
>>
>> On Wed, Oct 25, 2017 at 4:03 PM, Daniel Marques <dani@wiris.com> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> First of all, my apologies since I’m not available tomorrow/today for
>>> the meeting since I’m travelling to a conference.
>>>
>>>
>>>
>>> The good news is that I’ve not been idle and I’ve added two further
>>> examples to the polyfill:
>>>
>>> 1.     Matrix alignment with fences
>>> 2.     Grammar analysis (language subject)
>>>
>>> Unfortunately, I’m travelling and I’m not able to update the examples
>>> online. The old version is still available at:
>>> https://codepen.io/daniwiris/pen/rGKENd
>>>
>>>
>>>
>>> From the current examples, I learnt that the minimum requirements are to
>>> be able to align respect to a given child in the following two scenarios:
>>>
>>> 1.     A vertical flexbox
>>> 2.     A table or grid
>>>
>>> For the table, the alignment is only well defined when the affected row
>>> (the children of tables are rows) has all its cells aligned by the
>>> baseline, which is already possible to do with the current CSS
>>> specification. Things are a little more disgusting because tables contain
>>> an extra tbody element…
>>>
>>>
>>>
>>> Despite these minimal requirements, I implemented a version of the
>>> polyfill that is able to align a flexbox or table according to any of its
>>> descendants using a CSS like selector. It is fine to have such
>>> functionality but maybe we are overkilling the solution.
>>>
>>>
>>>
>>> I used the handy selectionQuery method in JavaScript which seemed an
>>> ideal solution until I discovered that selectionQuery never returned the
>>> node I expected when multiple nodes satisfied the criteria. For example,
>>> “:nth-child(2)” actually means any second child of any successor.
>>>
>>>
>>>
>>> Another idea is that probably makes more sense defining the “baseline”
>>> than change the “vertical-align”. Thus,
>>>
>>> Preferred solution:
>>>
>>>             baseline: “:nth-child(2)”;
>>>
>>>             vertical-align: “baseline”;
>>>
>>> Less preferred solution:
>>>
>>>              vertical-align: “:nth-child(2)”
>>>
>>>
>>>
>>> I’ve also experimented with the stretchy solution. I think that it is
>>> great but at the same time discovered that the browser does not render in
>>> the same form normal text than scaled one (we already saw that in Peter’s
>>> demo). This yields, again, that the different parts do not match perfectly.
>>> For example, the minus sign had different weight when zoomed horizontally.
>>> So the theory that this is a solution for perfect fraction lines is not
>>> true. I’m not worried about that. Eventually we could blame the browsers
>>> and they might fix it from their side.
>>>
>>>
>>> I'm still with the idea of going to TPAC. But I'm not satisfied with the
>>> current polyfill status.
>>>
>>>
>>> Regards,
>>>
>>>
>>> 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
>> .
>>
>
>

--

------------------------------
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: Polyfill and meeting

Source: public-mathonwebpages@w3.org Mail Archives • Neil Soiffer (soiffer@alum.mit.edu) • October 31, 2017 • Permalink

FYI:  CSS Flexible Box Layout Module Level 1
<https://www.w3.org/TR/2017/CR-css-flexbox-1-20171019/#align-content-property>
just announced call for implementations. Anything in there of use for
alignment or otherwise? If something is missing, it's getting late in the
game to suggest a missing feature for flex boxes, but with a good
justification, you never know.

Neil

Virus-free.
www.avg.com

On Mon, Oct 30, 2017 at 3:09 PM, Daniel Marques <dani@wiris.com> wrote:

> Hi,
>
>
> Just uploaded the examples at https://codepen.io/daniwiris/
> project/editor/ZWbYxB .
>
>
> My first thought was to extend the CSS style vertical-align. But then, I
> changed my mind in favor of the CSS style baseline-shift (
> https://www.w3.org/TR/css-inline-3/#baseline-shift-property). That’s more
> powerful since, for example, it would be possible to combine
> vertical-align="mathematical" with baseline-shift.
>
>
> In any case, I would like to sate the following objectives:
>
>
>    1. To use only html5/css/web-fonts (no JavaScript) to display
>    statically independent-target-device math (but also some physics and
>    chemistry) simple-enough formulas. This means:
>       1. To target a common subset of simple math formulas.
>       2. To be robust to browser and OS change. Firefox, Chrome, Safari,
>       Edge, ... Windows, Mac, Linux, iOs, Android, ...
>       3. To be robust to scale. For example, device pixel ratio in retina
>       display and browser zoom.
>       4. To be robust to font family change within the same type of font
>       (Arial, Helvetica or Lucida Sans). Changing from Arial to Courier New might
>       not work so well.
>       5. To be robust to font size change.
>       6. It is fine to embed fonts for math symbols. Especially stretchy
>       parts, including parts of roots.
>    2. To be enough semanticaly rich for copying, pasting and providing
>    accessibility.
>    3. To be able to recompose a formula if any subpart of such formula is
>    dynamically changed with the help of JavaScript. Because, if you are able
>    to change subparts of a formula, it means that the device is using
>    JavaScript anyway.
>
> Of course, the html5/css/web-fonts representation of a given formula can
> be generated once programmatically. Since it must not depend on the target
> device, it can be generated either in the server or in the browser. Once
> such formula is created, the exactly same html is send to all devices.
> eBooks will be published with static html formulas.
>
>
> After giving many thoughts to the topic I realized that current HTML
> technology has already solved problem 1. Maybe one possible task of the
> MathOnWebPages CG could be to explain how to do it. In a form of paper in a
> conference? In a blog? A new project in Github?
>
>
> For formulas that cannot be achieved with html5/css/web-fonts, let’s use
> SVG. I don’t think it is possible to do all imaginable formulas with either
> LaTeX or MathML. Remember that math are more than just formulas: plots,
> graphs, movies…
>
>
> The second objective is more ambitious. What I suggest is that we need to
> markup the html in order to be able to recover the underlying math
> structure. We are entering in the swampy zone of the semantics. I suggest a
> lightweight semantics style like presentation-MathML on first place and,
> optionally, add an extra layer of heavyweight semantics the way
> content-MathML, Open Math or whatever format is decided.
>
>
> It should be possible to add this layer of semantics also to a SVG image.
>
>
> Dani
>
> On Wed, Oct 25, 2017 at 4:03 PM, Daniel Marques <dani@wiris.com> wrote:
>
>> Hi,
>>
>>
>>
>> First of all, my apologies since I’m not available tomorrow/today for the
>> meeting since I’m travelling to a conference.
>>
>>
>>
>> The good news is that I’ve not been idle and I’ve added two further
>> examples to the polyfill:
>>
>> 1.     Matrix alignment with fences
>> 2.     Grammar analysis (language subject)
>>
>> Unfortunately, I’m travelling and I’m not able to update the examples
>> online. The old version is still available at: https://codepen.io/daniwir
>> is/pen/rGKENd
>>
>>
>>
>> From the current examples, I learnt that the minimum requirements are to
>> be able to align respect to a given child in the following two scenarios:
>>
>> 1.     A vertical flexbox
>> 2.     A table or grid
>>
>> For the table, the alignment is only well defined when the affected row
>> (the children of tables are rows) has all its cells aligned by the
>> baseline, which is already possible to do with the current CSS
>> specification. Things are a little more disgusting because tables contain
>> an extra tbody element…
>>
>>
>>
>> Despite these minimal requirements, I implemented a version of the
>> polyfill that is able to align a flexbox or table according to any of its
>> descendants using a CSS like selector. It is fine to have such
>> functionality but maybe we are overkilling the solution.
>>
>>
>>
>> I used the handy selectionQuery method in JavaScript which seemed an
>> ideal solution until I discovered that selectionQuery never returned the
>> node I expected when multiple nodes satisfied the criteria. For example,
>> “:nth-child(2)” actually means any second child of any successor.
>>
>>
>>
>> Another idea is that probably makes more sense defining the “baseline”
>> than change the “vertical-align”. Thus,
>>
>> Preferred solution:
>>
>>             baseline: “:nth-child(2)”;
>>
>>             vertical-align: “baseline”;
>>
>> Less preferred solution:
>>
>>              vertical-align: “:nth-child(2)”
>>
>>
>>
>> I’ve also experimented with the stretchy solution. I think that it is
>> great but at the same time discovered that the browser does not render in
>> the same form normal text than scaled one (we already saw that in Peter’s
>> demo). This yields, again, that the different parts do not match perfectly.
>> For example, the minus sign had different weight when zoomed horizontally.
>> So the theory that this is a solution for perfect fraction lines is not
>> true. I’m not worried about that. Eventually we could blame the browsers
>> and they might fix it from their side.
>>
>>
>> I'm still with the idea of going to TPAC. But I'm not satisfied with the
>> current polyfill status.
>>
>>
>> Regards,
>>
>>
>> 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: Polyfill and meeting

Source: public-mathonwebpages@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • October 30, 2017 • Permalink

Hi,

https://codepen.io/daniwiris/project/editor/ZWbYxB .

My first thought was to extend the CSS style vertical-align. But then, I
changed my mind in favor of the CSS style baseline-shift (
https://www.w3.org/TR/css-inline-3/#baseline-shift-property). That’s more
powerful since, for example, it would be possible to combine
vertical-align="mathematical" with baseline-shift.

In any case, I would like to sate the following objectives:

1. To use only html5/css/web-fonts (no JavaScript) to display statically
independent-target-device math (but also some physics and chemistry)
simple-enough formulas. This means:
1. To target a common subset of simple math formulas.
2. To be robust to browser and OS change. Firefox, Chrome, Safari,
Edge, ... Windows, Mac, Linux, iOs, Android, ...
3. To be robust to scale. For example, device pixel ratio in retina
display and browser zoom.
4. To be robust to font family change within the same type of font
(Arial, Helvetica or Lucida Sans). Changing from Arial to
Courier New might
not work so well.
5. To be robust to font size change.
6. It is fine to embed fonts for math symbols. Especially stretchy
parts, including parts of roots.
2. To be enough semanticaly rich for copying, pasting and providing
accessibility.
3. To be able to recompose a formula if any subpart of such formula is
dynamically changed with the help of JavaScript. Because, if you are able
to change subparts of a formula, it means that the device is using
JavaScript anyway.

Of course, the html5/css/web-fonts representation of a given formula can be
generated once programmatically. Since it must not depend on the target
device, it can be generated either in the server or in the browser. Once
such formula is created, the exactly same html is send to all devices.
eBooks will be published with static html formulas.

After giving many thoughts to the topic I realized that current HTML
technology has already solved problem 1. Maybe one possible task of the
MathOnWebPages CG could be to explain how to do it. In a form of paper in a
conference? In a blog? A new project in Github?

For formulas that cannot be achieved with html5/css/web-fonts, let’s use
SVG. I don’t think it is possible to do all imaginable formulas with either
LaTeX or MathML. Remember that math are more than just formulas: plots,
graphs, movies…

The second objective is more ambitious. What I suggest is that we need to
markup the html in order to be able to recover the underlying math
structure. We are entering in the swampy zone of the semantics. I suggest a
lightweight semantics style like presentation-MathML on first place and,
optionally, add an extra layer of heavyweight semantics the way
content-MathML, Open Math or whatever format is decided.

It should be possible to add this layer of semantics also to a SVG image.

Dani

On Wed, Oct 25, 2017 at 4:03 PM, Daniel Marques <dani@wiris.com> wrote:

> Hi,
>
>
>
> First of all, my apologies since I’m not available tomorrow/today for the
> meeting since I’m travelling to a conference.
>
>
>
> The good news is that I’ve not been idle and I’ve added two further
> examples to the polyfill:
>
> 1.     Matrix alignment with fences
> 2.     Grammar analysis (language subject)
>
> Unfortunately, I’m travelling and I’m not able to update the examples
> online. The old version is still available at: https://codepen.io/
> daniwiris/pen/rGKENd
>
>
>
> From the current examples, I learnt that the minimum requirements are to
> be able to align respect to a given child in the following two scenarios:
>
> 1.     A vertical flexbox
> 2.     A table or grid
>
> For the table, the alignment is only well defined when the affected row
> (the children of tables are rows) has all its cells aligned by the
> baseline, which is already possible to do with the current CSS
> specification. Things are a little more disgusting because tables contain
> an extra tbody element…
>
>
>
> Despite these minimal requirements, I implemented a version of the
> polyfill that is able to align a flexbox or table according to any of its
> descendants using a CSS like selector. It is fine to have such
> functionality but maybe we are overkilling the solution.
>
>
>
> I used the handy selectionQuery method in JavaScript which seemed an ideal
> solution until I discovered that selectionQuery never returned the node I
> expected when multiple nodes satisfied the criteria. For example,
> “:nth-child(2)” actually means any second child of any successor.
>
>
>
> Another idea is that probably makes more sense defining the “baseline”
> than change the “vertical-align”. Thus,
>
> Preferred solution:
>
>             baseline: “:nth-child(2)”;
>
>             vertical-align: “baseline”;
>
> Less preferred solution:
>
>              vertical-align: “:nth-child(2)”
>
>
>
> I’ve also experimented with the stretchy solution. I think that it is
> great but at the same time discovered that the browser does not render in
> the same form normal text than scaled one (we already saw that in Peter’s
> demo). This yields, again, that the different parts do not match perfectly.
> For example, the minus sign had different weight when zoomed horizontally.
> So the theory that this is a solution for perfect fraction lines is not
> true. I’m not worried about that. Eventually we could blame the browsers
> and they might fix it from their side.
>
>
> I'm still with the idea of going to TPAC. But I'm not satisfied with the
> current polyfill status.
>
>
> Regards,
>
>
> 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.


## [math-on-web] CG meeting minutes, 2017/10/26

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • October 26, 2017 • Permalink

Hi everyone,

Due to low attendance and connection issue, this meeting was mostly a
casual chat about various projects. We cut it short after 30 minutes and
did not keep formal minutes.

The next meeting will be on November 9 and we plan to continue the
discussion around CSS polyfills.

Best,
Peter.

# [math on web CG] minutes 2017-10-26

[no formal minutes]


## [math-on-web] CG meeting minutes, 2017/10/12

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • October 26, 2017 • Permalink

Hi everyone,

Below are the minutes from the last CG meeting.

As Dani wrote, the next meeting is today (and about to start actually --
sorry for the delay for the minutes).

Best,
Peter.

# MathOnWeb CG meeting 2017/10/12

* Dani's demo
* https://codepen.io/daniwiris/pen/rGKENd/
* https://codepen.io/daniwiris/pen/rGKENd/
* Dani: should we use a new name or a new value?
* flex-vertical-align vs vertical-align
* Volker: "1child" looks weird is that normal?
* Peter: nth-child(n+kl)
* Volker: what about binomial notation? Where to align?
* Peter: Tab wrote at https://github.com/w3c/csswg-drafts/issues/1339
* "Usually, rather than explicitly indicating an element in a property,
we invert control and have the target indicate that it's the one to be used
(and when necessary, have some sort of tie-breaker for ambiguous
situations)."
* Dani: example maybe overly complicated due to alignment at minus
* brings in all kinds of other topics (stretchy etc)
* maybe 3x3 matrix is better
* [discussion]
* Neil: if we have to tell the child to be target, in the 3x3, can we
expect it to bubble it up? I.e. cell tells row tells matrix tells ...
* Peter: CSSWG would tell us. I don't know if there are problems
* e.g., expect we can have different cells influencing their rows and
the rows working differently
* Volker: with matrix, what if we want to align in "the middle"
* and we remove a row.
* Neil: maybe it's then more about making Dani's polyfill bubble up the
property
* Dani: minus sign stretch.
* Peter: stretchy chars in MathJax v3
* https://codepen.io/pkra/pen/aLjGxZ
* https://codepen.io/pkra/pen/NaBMOE/
* Dani: so the main trick is scaling in the direction and using
overflow-hidden to crop it
* Dani: what are fractions like in MathJax v3?
* Peter: I'll have to ask Davide
* but links to pre-alpha example:
* https://rawgit.com/mathjax/mathjax-v3/demo/demo/index.html
* ACTIONS
* Dani rewrite


## [CSSWG] Minutes Telecon 2017-10-25 [css-ui-3] [css-ui-4] [css-fonts] [css-text-decor]

Source: www-style@w3.org Mail Archives • Dael Jackson (daelcss@gmail.com) • October 26, 2017 • Permalink

=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
with an appropriate subject line.
=========================================

CSS UI 3 & 4
------------

- RESOLVED: Take CSS UI 3 to PR.
- RESOLVED: Take CSS UI 4 to an updated WD.
- RESOLVED: Re-point CSS UI link to CSS UI 4 spec.

Fonts 3
-------

- RESOLVED: Publish a new Fonts 3 CR.

HTML
----

- Though the group is generally supportive of the effort to
incorporate better typography in issue #1888, the proposal to
change <sup> and <sub> has a very high likelihood of causing
breakage. This should instead be filed as a bug against Fonts 4
or 5 as a proposal to change CSS. Any request should also have
test cases to demonstrate what would be different between the
current and proposed approach.

CSS Text Decor
--------------

- RESOLVED: Add the statement that stroke should follow the curve of
the glyph as well as adding a non-normative note that
points out anything captured in the Github issue and add
better pictures.

CSS Grid
--------

- The remaining open topics on issue #509 (percentages and intrinsic
sizes: https://github.com/w3c/csswg-drafts/issues/509 ) will be
discussed at the F2F.

F2F Meetings
------------

- RESOLVED: Have the mid-2018 meeting held week of July 2nd in

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2017Oct/0042.html

Present:
Rossen Atanassov
Daid Baron
Tantek Çelik
Dave Cramer
Alex Critchfield
Benjamin De Cock
Javier Fernandez
Dael Jackson
Chris Lilley
Peter Linss
Myles Maxfield
Anton Prowse
Manuel Rego Casasnovas
Melanie Richards
Florian Rivoal
Jen Simmons
Alan Stearns
Greg Whitworth

Regrets:
Rachel Andrew
Tab Atkins
Tony Graham
Michael Miller
Lea Verou

Scribe: dael

Rossen: Let's get going. Hello everyone.
Rossen: Are there any additional items for the agenda or any changes
we need to make?
Chris: I sent one for CSS Fonts 3 which could do with a republish.
Updated CR.
Rossen: Thank you.
Rossen: Any others?

Spec Rec Next Steps
===================

CSS UI 3 & 4
------------

Rossen: First one is CSS 3 UI.
<florian> http://www.w3.org/mid/BBBF6365-4251-426D-A3F0-4F3E7D6C48A4@rivoal.net
Email Body:
[
## CSS-UI-3 ##
* There are 0 open issues:
https://github.com/w3c/csswg-drafts/labels/css-ui-3
* The change section is up to date:
https://drafts.csswg.org/css-ui-3/#changes
* All changes are fairly minor: mostly clarifications, and
some small tweaks to align the spec with implementation
* All testable / normative changes since last CR have tests
* The test suite is (IMO) sufficiently complete for REC
* The pass rate of the test suite meets CR exit criteria:
https://test.csswg.org/harness/results/css-ui-3_dev/grouped/
(minus one test, which is pending the next build of the
test-suite builder, and will be fine once that happens)
* Implementation report:
https://drafts.csswg.org/css-ui-3/implementation-report
* The DoC is up to date:
https://drafts.csswg.org/css-ui-3/issues-2017-2
]

<Rossen> https://drafts.csswg.org/css-ui-3/implementation-report
Rossen: florian sent an email yesterday summarizing state. There are
no issues open, changes are up to date. Test suite is, in
his opinion, meeting exit criteria. There is an
implementation report ^
<Rossen> https://drafts.csswg.org/css-ui-3/issues-2017-2
Rossen: DoC is up to date.

florian: Clarification. Since I wrote this there was a new test
using box-sizing with grid. That test has bugs and isn't
passing, but since it's grid I don't think we need to take
it into account. Test isn't fail/pass it's just buggy.
Rossen: Is the test necessary?
<Chris> mark the test as optional
florian: No, it's just linked because it uses box-sizing. I just
wanted to clarify.
Rossen: Reasonable.
Chris: florian I suggest we mark the test as optional.
florian: It's not optional for grid.
florian: We can't mark it as optional just for UI.
Chris: Okay. Then we just have to explain in the request.
florian: I'll update the impl report to mention that.

Chris: Everything looks great. Are there substantive changes since
last CR?
florian: Yes, there are some. I think that we might not have to
cycle CR, but that's a judgment.
Chris: My preference would be assemble a proposed PR and if it fails
cycle CR.
Rossen: Okay, that sounds great.
Rossen: Are there any reasons why we shouldn't take this to a PR?
Rossen: Chris any reasons?
Chris: Nope.
tantek: We should do it.
Rossen: Not hearing objections.

RESOLVED: Take CSS UI 3 to PR.

Rossen: Congrats to editors and all involved.
florian: Thanks tantek for giving me the shoulders to stand on to
get this done.
tantek: Thanks for all the work for the tests.
florian: Chris will you work with me on requests?
Chris: Yes. You notice I've been doing them as markdown. Is that
okay?
florian: Yes.
Chris: I'll give you the checklist after the call.

tantek: Do we have a PR template?
tantek: The markdown template, is there a blank?
Chris: No. That's a good idea.

Rossen: There was a tag on topic to this summary about UI 4.
florian: UI 4 was a delta over 3, but since 3 is kinda done I merged
in the 3 stuff to L4. I also caught up on pending actions
and warnings on unstable sections. I think that warrants a
2nd public WD. Should we?
Chris: Go for it.
Rossen: Objections?

RESOLVED: Take CSS UI 4 to an updated WD.

florian: Two follow-ups on this topic.
florian: Should we switch unversioned prefix to be L4?
Rossen: I don't see why we wouldn't.
Rossen: CSS UI 4 will be the currently worked on.
tantek: Do we have a policy of when we do that switch?
Chris: We don't. We do it when the current one worked on switches.
plinss: Policy is what's considered current. Someone looking for the
first time, where do they look.
Rossen: 3 isn't intended to move so 4 is the current.
plinss: It's no longer a delta.
florian: Yeah.
plinss: Then it should be 4.
tantek: It's reasonable to do at same time as PR request.
florian: A resolution on that would be nice.

RESOLVED: Re-point CSS UI link to CSS UI 4 spec.

<plinss> (switch css-ui to css-ui-4 done)

florian: Last, there is one thing in CSS UI that doesn't really
belong. It's box-sizing. It's a patch over from CSS2.1.
Some other spec should cover that...it should go into css
sizing I think. Once that happens we can remove the patch
from L4. For now it will be there, but I think other
editors should look into doing this.
tantek: That's a long standing request.
florian: I think it was waiting for this patch to get to REC so it's
a decent time to start looking at that.
tantek: We looked at the permalinking.
florian: Keep the section heading, but if a non-patch version starts
to exist I can point there.
plinss: No one should use unversioned short paths for permalinks.
tantek: Is there a github?
florian: No, but I'll make one.

Flexbox
-------

Rossen: Moving on. Flexbox testing.
Rossen: There was a bunch of work by gregwhitworth and company. I
called for volunteers last week. I don't think there were
updates. gregwhitworth can you summarize what you need help
with?
gregwhitworth: Melanie offered, but it would help for there to be
more people. I opened all the issues about
non-trivial stuff on github. At somebody's leisure
they could start squashing those. Melanie and I have
started pivoting in that direction. They are where
they should live. If you can do any part of if and
submit a PR it helps me out.
Chris: I can try and help depending on what else I have to do.
Rossen: Thank you Chris.

Rossen: gregwhitworth You said you needed help with bucketizing?
gregwhitworth: No, I sent it to the list yesterday.
<gregwhitworth>
https://github.com/w3c/web-platform-tests/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20%5Bcss-flex%5D%5Bspec-rec%5D
gregwhitworth: I bucketized the non-trivial ones. I need to do some
trivial stuff but these are the buckets of tests we
need. If you can help, please self-assign and
describe what you're going to do. These are the 6
categories of areas we need help.
gregwhitworth: Reach out to me if you have questions or update it on
Rossen: Thank you gregwhitworth for this awesome work and thanks
Chris for volunteering.

Fonts 3
-------

Rossen: Next and final is Fonts.
Chris: What's happened is there are a few sections marked as at
risk. Some may need to move, some we're not sure. Seems
worthwhile to update the spec that was last published in 2013
so people know things are at risk. Means if we drop moving to
PR we're good.
Chris: I believe changes list is up to date. Maybe need to mention
more on OM stuff.
myles: I thought it was, but you're probably right I need to make
another pass.
Chris: I think it's just putting it in the changes section.
myles: Sure. And if we republish I'll need help.
Chris: Right.
Rossen: Is this CR or WD?
Chris: Updated CR with technical changes?
Rossen: When will you be ready?
Chris: I'll leave it to myles.
myles: End of the week.
Chris: Ping me when you're ready and I can send the request.

Rossen: But you want a resolution.
Rossen: Objections to publish a new Fonts 3 CR spec?

RESOLVED: Publish a new Fonts 3 CR

Rossen: Thank you chris and myles for all the awesome work.

HTML
====

Change default <sup> and <sub> styling?
---------------------------------------
github: https://github.com/w3c/csswg-drafts/pull/1888

Rossen: Anyone want to take this? florian and dbaron were involved,
I know. Or myles.
myles: I can summarize.
myles: In HTML there's <sup> and <sub> that are defined in UA
stylesheet to do vertical align and reduce font size. Now
that open type fonts are available it may be that there are
specific information in the font for this.
myles: Issue proposes we change UA style sheet to turn on the font
features.
* tantek is going to go out on a limb and say there are likely major
compat issues with touching this
<tantek> perhaps experiment with MathML super/subscripts first?

fantasai: Problem with this is that it doesn't handle anything that
is nested so if you have any elements inside it like
something to an exponent and the exponent has an exponent
in it the feature won't work. So this breaks cases that
would have worked.
fantasai: We had when designing font variant feature it was decided
not to do that which is why font spec doesn't recommend
this as a replacement. Given that's the case we should
advise HTML to not make this change.
<tantek> fantasai's answer makes sense and would likely make a good
FAQ in the spec.

florian: I followed up trying to make a hybrid using font features
for first level and then fallback for nesting. I'm not sure
it handles all cases. If people want to keep investigating
if we can write such rules maybe we can look into that. I'm
not confident it's sufficient.
Chris: I think it's a good approach. The PR is sent for tests for
CSS 3 fonts actually mentions that. I think it's better to
make the single level of nesting use the open type feature
which will give you a better result in the common and if
you're complex maybe you should use MathML.
dbaron: I don't think...I think what chris suggests for top level
won't work if the font metrics are inaccurate which is
common. There's no guarantee it'll work or that a subscript
will align anywhere correct so you could distinguish the
super script of a superscript.
florian: I think it works mostly.
dbaron: It depends on how well the font metrics match the characters.
fantasai: It also doesn't handle images in the subscript so I think
there's a lot of things that will break.

myles: First, I'd like to agree with fantasai and dbaron. Apart from
that we would like some ability for the UA to use the glyphs
if it can figure out the right way. We don't think this
proposal is sufficient, but it is possible for a UA to use
these glyphs. This proposal isn't the right way but we'd like
some sort of affordance in the future.
fantasai: But that would require new CSS features. We've discussed
that in the past and people didn't want to do it. We can
re-open those discussions. We should close this request
and say you can't do that, but if you want to make a bug
against Fonts 4 or 5 to make this possible you can do that.
myles: I agree. This isn't the right place but the goal is noble.
fantasai: We appreciate the effort to incorporate better typography,
but this isn't the right place and it's not able to handle
it currently.
Rossen: Any other comments or suggestions?
Rossen: If not we can close with fantasai's suggested rec.

tantek: A couple of comments. I would suspect that changing this for
sub and sup it will break compat in unpredictable ways
since those tags have been used so long.
tantek: Second question is, I didn't see a URL to a test case that
demos what this would look like old vs new style. I think at
a minimum we need that to consider this proposal.
<fantasai> tantek's got a good point
* bradk agrees with tantek, just didn’t want to beat a dead horse
Rossen: Anyone have a test case or code that can demo this side by
side?
Rossen: I don't hear any. We can go back to the issue and wait for
the people discussing it to see if anything will come
through.

fantasai: I think tantek has a good point about how this has been
used a long time. People have tweaked their style sheet to
make these tags look better and may be relying on
vertical-align or font-size cascading through. We will
break pages if we try and change the default stylesheet.
* bradk always changes font-size, vertical-align, and relative
position in order to “fix” SUPs
fantasai: That will apply to any case where we try and make things
better unless it's really automagic.

Rossen: Anything else on this topic?

CSS Text Decor
==============

ink skipping should conform to glyph shape
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1093

fantasai: There was a complaint about how implementations, when they
cut off the underline they cut off in a straight line. You
don't want the underline to stop with a blunt edge and
then have a gap between glyph edges, you want it to follow
the edges of the glyph.
fantasai: The spec doesn't say anything specific so I was thinking
we could have advice, you should have underline edges hug
the glyph.
fantasai: There was a concern on performance which is why I'm
suggesting a should. An implementation could decide to do
it if font size is large enough, but not in general case.
That would resolve a lot of performance considerations. I
think spec should offer this advice.
<fantasai> https://www.ietf.org/rfc/rfc2119.txt
<fantasai> proposed text: "stroke endings should follow the curve of
the glyph"

myles: You can have a description of good typography. There's more
to good underlining then having it follow contours of glyph.
You'll want a larger explanation of good typography of
underlines and that doesn't feel like it should be a
normative description. It feels another spec or note.
florian: Are they big enough that they cannot be phrased as shoulds?
florian: Do you think it's too high level for normative?
myles: Yeah.
myles: If you're going to have a couple paragraphs on good
typography it shouldn't be normative.

Rossen: I'm hearing one proposal for adding the should which
suggests how a good typography works for underlining and I
heard some push back on why is this normative and not
informative somewhere.
dbaron: One comment on myles' statement. I don't want to get into a
situation where you need to be an expert in other fields to
impl the spec. The spec ought to say what you need to do to
impl. If there's advice on good typography that should be
known by an impl it should be on the WG to have that as part
of the behavior the spec describes.
myles: I think the spec does that as is.
fantasai: It describes certain necessary things. We'd like the
impl...given the option we'd say yes you should have the
to think about that, but that's why we shouldn't be over
specific. That's why we word things with an appropriate
level of specificity so you know what to do.
myles: Point I was trying to make...for example if the spec says
underline should follow contour of glyph and implementors
could use mask-base and then you have underlines in the curve
of the g and that's worse typography. If you're going to have
this it needs to be much longer. If it's a general of how
underlines should work...
fantasai: Typography is very broad. If you want more description on
ways you can mess this up, that's fine. Typography of
underlines in general is out of scope for this.
myles: Right. Doing this..
fantasai: It's not out of scope for the spec. L4 has the ability to
adjust underline and will have much more detail. This
topic isn't position, this is where you don't draw a line.
A description here should assume position and thickness
myles: I'm not talking position and thickness.
<dbaron> If the spec says "use the position and thickness specified
in the font metrics" then position and thickness aren't
something that implementors need to think about

Rossen: myles is your push back on adding this statement very strong
or is this something you can live with?
myles: I'm not going to object.
Rossen: Okay. And fantasai if this was a non-normative note would
you be okay or would you prefer the should?
fantasai: I'd prefer the should so it's clear to implement this is
the behavior that we want. We can add a note saying
there's things you need to watch out for and if myles
wants to point out anything not in the issue when doing
the note I can add that.
Rossen: In summary you propose to add the stroke of the underline
should follow the curve of the glyph. That's the text?
fantasai: Yes and a note to address myles's concerns.
myles: We should also add a picture because the one in the spec is
2px tall.
fantasai: Good idea. We can have some of those Gs.
dbaron: Will the note have the thing about maybe doing it only at
large font sizes?
fantasai: I can do that.
<tantek> "large" = when it uses a lot of physical pixels
<fantasai> probably px units is appropriate here, as resolutions
increase we don't want to be doing it for paragraph-size
text

Rossen: Proposed resolution: add the statement that stroke should
non-normative note that points out anything captured in the
Github issue and add better pictures.

the glyph as well as adding a non-normative note that
points out anything captured in the Github issue and add
better pictures.

CSS Grid
========

Percentages and intrinsic size
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/509

Rossen: mats added a quick explanation of what Mozilla's back
computation looks like for grid-gap.
<rego> https://github.com/w3c/csswg-drafts/issues/509#issuecomment-334075296
Rossen: I want to ask if anyone is prepared to speak to this issue.
Rossen: If not we can push to next week or F2F.
rego: Last week we said we'd leave for TPAC. We need more
implementors. We resolved that we should back compute, but
anyway it needs a lot further discussion.
Rossen: I agree. It sounds like...I don't see in last week's
resolution we'll discuss for F2F. I'll tag for F2F and
remove the agenda+ for weekly calls.
Rossen: I propose we switch topics if there are any.

F2F Meetings
============

Rossen: If there's no other topics we can end early or we can
discuss mid-2018 F2F.
Rossen: Are we ready to discuss mid-2018 F2F meeting?
Rossen: If not we can push this off.
tantek: I'd like thoughts on that.

Australia or Toronto.
<tantek> +1 to both
ericwilligers: We thought we were picking Sydney and dates the week
of July 2nd
<nainar> I'm not on the call. But what ericwilligers said.
ericwilligers: Do we need to wait for someone to confirm?
Rossen: We did pick dates, but there was an open question as to if
Toronto was still on the table. That's my recollection. If
we agree it's Sydney week of July 2 we can put that on the
record and go with it.
ericwilligers: That's my understanding.
Rossen: I see nainar confirmed on IRC that's the proposal.
Rossen: Objections to having mid-2018 meeting held week of July 2nd
in Sydney with Google as host?
<tantek> for some reason I recall August, but ok with July
<nainar> I would say lets lock in July 2nd week for Sydney.
<tantek> note US Holiday July 4th
<tantek> just a note, no objection :)

RESOLVED: Have the mid-2018 meeting held week of July 2nd in Sydney

Rossen: Any 4 minute topics?
Rossen: Thank you everyone and thanks Google to host us mid-2018.
We'll talk next week.
<nainar> Rossen happy to host! :)
accommodation for F2F.
Rossen: Remember next week is different time.
<dbaron> next week's call will also be an hour earlier for Europeans
than other APAC calls
<dbaron> since Europe will have changed off summer time, but the US
won't


## Polyfill and meeting

Source: public-mathonwebpages@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • October 25, 2017 • Permalink

Hi,

First of all, my apologies since I’m not available tomorrow/today for the
meeting since I’m travelling to a conference.

The good news is that I’ve not been idle and I’ve added two further
examples to the polyfill:

1.     Matrix alignment with fences
2.     Grammar analysis (language subject)

Unfortunately, I’m travelling and I’m not able to update the examples
online. The old version is still available at:
https://codepen.io/daniwiris/pen/rGKENd

>From the current examples, I learnt that the minimum requirements are to be
able to align respect to a given child in the following two scenarios:

1.     A vertical flexbox
2.     A table or grid

For the table, the alignment is only well defined when the affected row
(the children of tables are rows) has all its cells aligned by the
baseline, which is already possible to do with the current CSS
specification. Things are a little more disgusting because tables contain
an extra tbody element…

Despite these minimal requirements, I implemented a version of the polyfill
that is able to align a flexbox or table according to any of its
descendants using a CSS like selector. It is fine to have such
functionality but maybe we are overkilling the solution.

I used the handy selectionQuery method in JavaScript which seemed an ideal
solution until I discovered that selectionQuery never returned the node I
expected when multiple nodes satisfied the criteria. For example,
“:nth-child(2)” actually means any second child of any successor.

Another idea is that probably makes more sense defining the “baseline” than
change the “vertical-align”. Thus,

Preferred solution:

baseline: “:nth-child(2)”;

vertical-align: “baseline”;

Less preferred solution:

vertical-align: “:nth-child(2)”

I’ve also experimented with the stretchy solution. I think that it is great
but at the same time discovered that the browser does not render in the
same form normal text than scaled one (we already saw that in Peter’s
demo). This yields, again, that the different parts do not match perfectly.
For example, the minus sign had different weight when zoomed horizontally.
So the theory that this is a solution for perfect fraction lines is not
true. I’m not worried about that. Eventually we could blame the browsers
and they might fix it from their side.

I'm still with the idea of going to TPAC. But I'm not satisfied with the
current polyfill status.

Regards,

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] Reminder: Meeting today

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • October 12, 2017 • Permalink

Hi everyone,

A uick reminder that we are scheduled to meet today, Oct 12, 12pm Eastern
time on appear.in.

We'll focus on polyfill ideas for layout (e.g., Dani's vertical align,
MathJax v3's new approach to stretchy) .

Best,
Peter.


## Vertical align polyfil

Source: public-mathonwebpages@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • October 12, 2017 • Permalink

HI,

Just uploaded the vertical-align polyfill to codepen.io
https://codepen.io/daniwiris/pen/rGKENd/

Tomorrow (or today depending on the time zone) during the meeting I would
appreciate any feedback!

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.


## Setting and Getting Math Speech, Braille, UnicodeMath, LaTeX…

Source: Murray Sargent: Math in Office • MurrayS3 • September 28, 2017 • Permalink

This post augments the post Inserting and Getting Math Text in RichEdit by documenting the RichEdit options for ITextRange2::SetText2(options, bstr) and ITextRange2::GetText2(options, pbstr) including those for math speech and math braille. As such, this post is for programmers. But more generally, it reveals that RichEdit supports Nemeth math braille (!). All options work in the current Microsoft Office RichEdit (riched20.dll in an Office subdirectory); the Windows RichEdit (msftedit.dll) hasn’t exposed math functionality yet. The options are defined in the following table in which s/g stands for SetText2/GetText2. For convenience, non-math-specific flags are also included

 Option Value s/g Meaning tomUnicodeBiDi 0x00000001 s Use Unicode BiDi algorithm for inserted text tomAdjustCRLF 0x00000001 g If range start is inside multicode unit like CRLF, surrogate pair, etc., move to start of unit tomUseCRLF 0x00000002 g Paragraph ends use CRLF (U+000D U+000A) tomTextize 0x00000004 g Embedded objects export alt text; else U+FFFC tomAllowFinalEOP 0x00000008 g If range includes final EOP, export it; else don’t tomUnlink 0x00000008 s Disables link attributes if present tomUnhide 0x00000010 s Disables hidden attribute if present tomFoldMathAlpha 0x00000010 g Replace math alphanumerics with ASCII/Greek tomIncludeNumbering 0x00000040 g Lists include bullets/numbering tomCheckTextLimit 0x00000020 s Only insert up to text limit tomDontSelectText 0x00000040 s After insertion, call Collapse(tomEnd) tomTranslateTableCell 0x00000080 g Export spaces for table delimiters tomNoMathZoneBrackets 0x00000100 g Used with tomConvertUnicodeMath and tomConvertTeX. Set discards math zone brackets tomLanguageTag 0x00001000 s/gg Sets BCP-47 language tag for range; gets tag tomConvertRTF 0x00002000 s/g Set or get RTF tomGetTextForSpell 0x00008000 g Export spaces for hidden/math text, table delims tomConvertMathML 0x00010000 s/g Set or get MathML tomGetUtf16 0x00020000 g Causes tomConvertRTF, etc. to get UTF-16. SetText2 accepts 8-bit or 16-bit RTF tomConvertLinearFormat 0x00040000 s/g Alias for tomConvertUnicodeMath tomConvertUnicodeMath 0x00040000 s/g UnicodeMath tomConvertOMML 0x00080000 s/g Office MathML tomConvertMask 0x00F00000 s/g Mask for mutually exclusive modes tomConvertRuby 0x00100000 s See Inserting and Getting Math Text… tomConvertTeX 0x00200000 s/g See LaTeX Math in Office tomConvertMathSpeech 0x00300000 g Math speech (English only here) tomConvertSpeechTokens 0x00400000 g Simple Unicode and speech tokens tomConvertNemeth 0x00500000 s/g Nemeth math braille in U+2800 block tomConvertNemethAscii 0x00600000 g Corresponding ASCII braille tomConvertNemethNoItalic 0x00700000 g Nemeth braille in U+2800 block w/o math italic tomConvertNemethDefinition 0x00800000 g Fine-grained speech in braille tomConvertCRtoLF 0x01000000 g Plain-text paragraphs end with LF, not CRLF tomLaTeXDelim 0x02000000 g Use LaTeX math-zone delimiters $$...$$ inline, $...$ display; else $...$, $$...$$. Set handles all

## Mutually exclusive options

Nonzero values within the mask defined by tomConvertMask (0x00F00000) are mutually exclusive, that is, they cannot be combined (OR’d) with one another. These options include setting text as UnicodeMath, [La]TeX (tomConvertTeX), and Nemeth math braille (tomConvertNemeth). You can set only one at a time. But other options can be OR’d in if desired.

## Nemeth math braille options

A string bstr of Nemeth math braille coded in the Unicode range U+2800..U+283F can be inserted and built up by calling ITextRange2::SetText2(tomConvertNemeth, bstr). If the string is valid, you can get it back in any of the math formats including Nemeth math braille. For example, if you insert the string

⠹⠂⠌⠆⠨⠏⠼⠮⠰⠴⠘⠆⠨⠏⠐⠹⠨⠈⠈⠙⠨⠹⠌⠁⠬⠃⠀⠎⠊⠝⠀⠨⠹⠼⠀⠨⠅⠀⠹⠂⠌⠜⠁⠘⠆⠐⠤⠃⠘⠆⠐⠻⠼

you see

You can also input braille with a standard keyboard by typing a control word \braille assigned to the Unicode character U+24B7 (Ⓑ). (See LaTeX Math in Office for how to add commands to math autocorrect). The \braille command causes math input to accept braille input via a regular keyboard using the braille ASCII codes sometimes referred to as North American Braille Computer Codes. The character ~ (U+007E) disables this input mode. These braille codes are described in the post Nemeth Braille—the first math linear format and can be input using refreshable braille displays. Alternatively, such input can be automated by calling ITextSelection::TypeText(bstr). Just as in entering UnicodeMath, the equations build up on screen as soon as the math braille input becomes unambiguous. The implementation includes the math braille UI that cues the user where the insertion point is for unambiguous editing of math zones using braille. Note that as of this posting, the math braille facility isn’t hooked up to Narrator or other screen readers.

## Getting (and Setting?) Math Speech

The tomConvertMathSpeech currently only gets math speech in English. Microsoft Office apps like Word, PowerPoint and OneNote deliver math speech in over 18 languages to the assistive technology (AT) program Narrator via the UIA ITextRangeProvider::GetText() function. Other ATs could also get math speech this way. Dictating (setting) math speech would be nice for both blind and sighted folks. Imagine, you can say a² + b² = c² faster than you can type it or write it! The SetText2(tomConvertMathSpeech, bstr) is ready to handle such input, but it’s not implemented yet anyhow.

## [MathOnWeb] skip meeting Sept 28 / next meeting Oct 12

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • September 28, 2017 • Permalink

Hi MathOnWebCG,

The next meeting will be on Oct 12.

I suspect "recent news" will be a sufficient topic for the next meeting but
please suggest another one if you prefer.

Best wishes,
Peter.


## [mathonweb] Reminder: Meeting today

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

Hi everyone,

We are scheduled to meet today, Sept 14, 12pm Eastern time.

Best,
Peter.


## Introduction

For many years Igalia has been committed to and dedicated efforts to the improvement of Web Platform in all open-source Web Engines (Chromium, WebKit, Servo, Gecko) and JavaScript implementations (V8, SpiderMonkey, ChakraCore, JSC). We have been working in the implementation and standardization of some important technologies (CSS Grid/Flexbox, ECMAScript, WebRTC, WebVR, ARIA, MathML, etc). This blog post contains a review of these activities performed during the first half (and a bit more) of 2017.

## Projects

### CSS

A few years ago Bloomberg and Igalia started a collaboration to implement a new layout model for the Web Platform. Bloomberg had complex layout requirements and what the Web provided was not enough and caused performance issues. CSS Grid Layout seemed to be the right choice, a feature that would provide such complex designs with more flexibility than the currently available methods.

We’ve been implementing CSS Grid Layout in Blink and WebKit, initially behind some flags as an experimental feature. This year, after some coordination effort to ensure interoperability (talking to the different parties involved like browser vendors, the CSS Working Group and the web authors community), it has been shipped by default in Chrome 58 and Safari 10.1. This is a huge step for the layout on the web, and modern websites will benefit from this new model and enjoy all the features provided by CSS Grid Layout spec.

Since the CSS Grid Layout shared the same alignment properties as the CSS Flexible Box feature, a new spec has been defined to generalize alignment for all the layout models. We started implementing this new spec as part of our work on Grid, being Grid the first layout model supporting it.

Finally, we worked on other minor CSS features in Blink such as caret-color or :focus-within and also several interoperability issues related to Editing and Selection.

### MathML

MathML is a W3C recommendation to represent mathematical formulae that has been included in many other standards such as ISO/IEC, HTML5, ebook and office formats. There are many tools available to handle it, including various assistive technologies as well as generators from the popular LaTeX typesetting system.

After the improvements we performed in WebKit’s MathML implementation, we have regularly been in contact with Google to see how we can implement MathML in Chromium. Early this year, we had several meetings with Google’s layout team to discuss this in further details. We agreed that MathML is an important feature to consider for users and that the right approach would be to rely on the new LayoutNG model currently being implemented. We created a prototype for a small LayoutNG-based MathML implementation as a proof-of-concept and as a basis for future technical discussions. We are going to follow-up on this after the end of Q3, once Chromium’s layout team has made more progress on LayoutNG.

### Servo

Servo is Mozilla’s next-generation web content engine based on Rust, a language that guarantees memory safety. Servo relies on a Rust project called WebRender which replaces the typical rasterizer and compositor duo in the web browser stack. WebRender makes extensive use of GPU batching to achieve very exciting performance improvements in common web pages. Mozilla has decided to make WebRender part of the Quantum Render project.

We’ve had the opportunity to collaborate with Mozilla for a few years now, focusing on the graphics stack. Our work has focused on bringing full support for CSS stacking and clipping to WebRender, so that it will be available in both Servo and Gecko. This has involved creating a data structure similar to what WebKit calls the “scroll tree” in WebRender. The scroll tree divides the scene into independently scrolled elements, clipped elements, and various transformation spaces defined by CSS transforms. The tree allows WebRender to handle page interaction independently of page layout, allowing maximum performance and responsiveness.

### WebRTC

WebRTC is a collection of communications protocols and APIs that enable real-time communication over peer-to-peer connections. Typical use cases include video conferencing, file transfer, chat, or desktop sharing. Igalia has been working on the WebRTC implementation in WebKit and this development is currently sponsored by Metrological.

This year we have continued the implementation effort in WebKit for the WebKitGTK and WebKit WPE ports, as well as the maintenance of two test servers for WebRTC: Ericsson’s p2p and Google’s apprtc. Finally, a lot of progress has been done to add support for Jitsi using the existing OpenWebRTC backend.

Since OpenWebRTC development is not an active project anymore and given libwebrtc is gaining traction in both Blink and the WebRTC implementation of WebKit for Apple software, we are taking the first steps to replace the original WebRTC implementation in WebKitGTK based on OpenWebRTC, with a new one based on libwebrtc. Hopefully, this way we will share more code between platforms and get more robust support of WebRTC for the end users. GStreamer integration in this new implementation is an issue we will have to study, as it’s not built in libwebrtc. libwebrtc offers many services, but not every WebRTC implementation uses all of them. This seems to be the case for the Apple WebRTC implementation, and it may become our case too if we need tighter integration with GStreamer or hardware decoding.

### WebVR

WebVR is an API that provides support for virtual reality devices in Web engines. Implementation and devices are currently actively developed by browser vendors and it looks like it is going to be a huge thing. Igalia has started to investigate on that topic to see how we can join that effort. This year, we have been in discussions with Mozilla, Google and Apple to see how we could help in the implementation of WebVR on Linux. We decided to start experimenting an implementation within WebKitGTK. We announced our intention on the webkit-dev mailing list and got encouraging feedback from Apple and the WebKit community.

### ARIA

ARIA defines a way to make Web content and Web applications more accessible to people with disabilities. Igalia strengthened its ongoing committment to the W3C: Joanmarie Diggs joined Richard Schwerdtfeger as a co-Chair of the W3C’s ARIA working group, and became editor of the Core Accessibility API Mappings, [Digital Publishing Accessibility API Mappings] (https://w3c.github.io/aria/dpub-aam/dpub-aam.html), and Accessible Name and Description: Computation and API Mappings specifications. Her main focus over the past six months has been to get ARIA 1.1 transitioned to Proposed Recommendation through a combination of implementation and bugfixing in WebKit and Gecko, creation of automated testing tools to verify platform accessibility API exposure in GNU/Linux and macOS, and working with fellow Working Group members to ensure the platform mappings stated in the various “AAM” specs are complete and accurate. We will provide more information about these activities after ARIA 1.1 and the related AAM specs are further along on their respective REC tracks.

### Web Platform Predictability for WebKit

The AMP Project has recently sponsored Igalia to improve WebKit’s implementation of the Web platform. We have worked on many issues, the main ones being:

• Frame sandboxing: Implementing sandbox values to allow trusted third-party resources to open unsandboxed popups or restrict unsafe operations of malicious ones.
• Frame scrolling on iOS: Addressing issues with scrollable nodes; trying to move to a more standard and interoperable approach with scrollable iframes.
• Root scroller: Finding a solution to the old interoperability issue about how to scroll the main frame; considering a new rootScroller API.

This project aligns with Web Platform Predictability which aims at making the Web more predictable for developers by improving interoperability, ensuring version compatibility and reducing footguns. It has been a good opportunity to collaborate with Google and Apple on improving the Web. You can find further details in this blog post.

### JavaScript

Igalia has been involved in design, standardization and implementation of several JavaScript features in collaboration with Bloomberg and Mozilla.

In implementation, Bloomberg has been sponsoring implementation of modern JavaScript features in V8, SpiderMonkey, JSC and ChakraCore, in collaboration with the open source community:

• Implementation of many ES6 features in V8, such as generators, destructuring binding and arrow functions
• Async/await and async iterators and generators in V8 and some work in JSC
• Optimizing SpiderMonkey generators
• Ongoing implementation of BigInt in SpiderMonkey and class field declarations in JSC

On the design/standardization side, Igalia is active in TC39 and with Bloomberg’s support

In partnership with Mozilla, Igalia has been involved in the specification of various JavaScript standard library features for internationalization, in specification, implementation in V8, code reviews in other JavaScript engines, as well as working with the underlying ICU library.

## Other activities

### Preparation of Web Engines Hackfest 2017

Igalia has been organizing and hosting the Web Engines Hackfest since 2009. This event under an unconference format has been a great opportunity for Web Engines developers to meet, discuss and work together on the web platform and on web engines in general. We announced the 2017 edition and many developers already confirmed their attendance. We would like to thank our sponsors for supporting this event and we are looking forward to seeing you in October!

### Coding Experience

Emilio Cobos has completed his coding experience program on implementation of web standards. He has been working in the implementation of “display: contents” in Blink but some work is pending due to unresolved CSS WG issues. He also started the corresponding work in WebKit but implementation is still very partial. It has been a pleasure to mentor a skilled hacker like Emilio and we wish him the best for his future projects!

### New Igalians

During this semester we have been glad to welcome new igalians who will help us to pursue Web platform developments:

• Daniel Ehrenberg joined Igalia in January. He is an active contributor to the V8 JavaScript engine and has been representing Igalia at the ECMAScript TC39 meetings.
• Alicia Boya joined Igalia in March. She has experience in many areas of computing, including web development, computer graphics, networks, security, and software design with performance which we believe will be valuable for our Web platform activities.
• Ms2ger joined Igalia in July. He is a well-known hacker of the Mozilla community and has wide experience in both Gecko and Servo. He has noticeably worked in DOM implementation and web platform test automation.

# Conclusion

Igalia has been involved in a wide range of Web Platform technologies going from Javascript and layout engines to accessibility or multimedia features. Efforts have been made in all parts of the process:

• Participation to standardization bodies (W3C, TC39).
• Elaboration of conformance tests (web-platform-tests test262).
• Implementation and bug fixes in all open source web engines.
• Discussion with users, browser vendors and other companies.

Although, some of this work has been sponsored by Google or Mozilla, it is important to highlight how external companies (other than browser vendors) can make good contributions to the Web Platform, playing an important role on its evolution. Alan Stearns already pointed out the responsibility of the Web Plaform users on the evolution of CSS while Rachel Andrew emphasized how any company or web author can effectively contribute to the W3C in many ways.

As mentioned in this blog post, Bloomberg is an important contributor of several open source projects and they’ve been a key player in the development of CSS Grid Layout or Javascript. Similarly, Metrological’s support has been instrumental for the implementation of WebRTC in WebKit. We believe others could follow their examples and we are looking forward to seeing more companies sponsoring Web Platform developments!

## [math-on-web] CG meeting minutes, 2017/08/31

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

Hi everyone,

Below are the minutes from the last CG meeting.

The next meeting will be on Sep14. We'll continue the discussion around CSS
polyfills.

Best,
Peter.

# [math on web CG] minutes 2017-08-31

* Dani, Neil, Peter, Volker
* Dani: new stretchy polyfill at
https://w3c.github.io/mathonwebpages/examples/display/stretchy1.html
* splits up vertical vs horizontal
* also probably need to separate serif vs sans-serif, so we should have a
custom attribute for that
* Neil: not sure how serifs would show up in stretchy chars
* Dani: horizontal lines can be thinner, vertical more bold
* publishers will want distinction.
*  ideally, match fonts in terms of thickness
* Peter: do you want to go thorough the polyfill?
* Dani: prefer for people to take a closer look first
* Dani: I'm thinking we should create a collection of such polyfills
* Dani: it would be good to have something like a Unicode point for
"fraction line"
* [discussion about exposing fraction lines to AT]
* Peter: in MathJax v3, stretchy will be done purely in CSS, no JS
required, just growing with the box
* JS still necessary for choosing between the available sizes in a font
vs the truly stretchy constructoin
* CSS element queries could help solve that.
* Neil: can you share?
* [screenshare]
* Peter: ACTION yes, will have a public sample by next meeting
* Peter: of course all approaches have drawbacks
* [discussion about CSS approaches to stretchy]
* Peter: variable fonts could solve a lot of issues
* and even more so things like https://spectral.prototypo.io/
* Peter: Dani can you post to the CSS tracker on vertical-align?
* Dani: ACTION yes but want to publish polyfill first
* Dani: it would be good to get feedback for stretchy and fraction
construction


## RE: [math-on-web] CG meeting minutes, 2017/08/17

Source: public-mathonwebpages@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • August 31, 2017 • Permalink

Hi Everybody,

I updated a new proof-of-concept “polyfil” with stretchy square brackets

https://w3c.github.io/mathonwebpages/examples/display/stretchy1.html

Planning to put all the examples at https://codepen.io

See you in a few minutes!

Dani

*From:* Peter Krautzberger [mailto:peter@krautzource.com]
*Sent:* lunes, 28 de agosto de 2017 10:41
*To:* mathonweb
*Subject:* [math-on-web] CG meeting minutes, 2017/08/17

Hi everyone,

Sorry for the very long delay in posting this.

Below are the minutes from the last CG meeting.

The next meeting will be on August 31 and we'll be focusing (and deciding)
on a TPAC meeting.

Best,

Peter.

# [math on web CG] minutes 2017-08-17

* first approach done

* https://w3c.github.io/mathonwebpages/examples/display/fraction1.html

* Peter: only concern about polyfilling is that I can't see a JS math
rendering engine using this polyfill because of its complexity

* Peter: do you want to post this to the CSSWG thread?

* Daniel: let me clean it up first

* TPAC

* Peter: not many people at TPAC, those who are seem very busy

* Tzviya: if focus is on CSSWG, maybe meet them outside TPAC

* Daniel: call sounds a good idea

* Daniel: if we publish the polyfill and get some feedback, that's great

* if I manage to get to TPAC and can talk to folks in person, that
would be worth it

* ACTION Daniel will try to organize something with CSSWG

* ACTION: Peter to write intro email to Alan

* once we know more, we will update group

* otherwise just spontaneous meeting

* Tzviya: get Alan or Rawson today and announce as soon as possible.

* [DONE]

* Tzivya: where is the group at accessible math

* getting lots more request

* accessibility object model

* now in Chrome

* Peter: AOM is very interesting

* Peter: but generally it seems the web platform is sufficient, cf.
speech-rule-engine, Desmos's accessible editing interface etc

* personally I'd recommend simply using alt-text generated by
speech-rule-engine to annotate HTML or SVG equation rendering -- anyone can
do this.

* advanced: adding aria labels on MathML and expose them in HTML or SVG
rendering to fix a11y tree

* but that's obviously expensive right now though MathJax is doing
research to automate that.


## TL;DR

The AMP Project and Igalia have recently been collaborating to improve WebKit’s implementation of the Web platform. Both teams are committed to make the Web better and we expect that all developers and users will benefit from this effort. In this blog post, we review some of the bug fixes and features currently being considered:

• Frame sandboxing: Implementing sandbox values to allow trusted third-party resources to open unsandboxed popups or restrict unsafe operations of malicious ones.

• Frame scrolling on iOS: Trying to move to a more standard and interoperable approach via iframe elements; addressing miscellaneous issues with scrollable nodes (e.g. visual artifacts while scrolling, view not scrolled when using “Find Text”…).

• Root scroller: Finding a solution to the old interoperability issue about how to scroll the main frame; considering a new rootScroller API.

Some demo pages for frame sandboxing and scrolling are also available if you wish to test features discussed in this blog post.

## Introduction

AMP is an open-source project to enable websites and ads that are consistently fast, beautiful and high-performing across devices and distribution platforms. Several interoperability bugs and missing features in WebKit have caused problems to AMP users and to Web developers in general. Although it is possible to add platform-specific workarounds to AMP, the best way to help the Web Platform community is to directly fix these issues in WebKit, so that everybody can benefit from these improvements.

Igalia is a consulting company with a team dedicated to Web Platform developments in all open-source Web Engines (Chromium, WebKit, Servo, Gecko) working in the implementation and standardization of miscellaneous technologies (CSS Grid/flexbox, ECMAScript, WebRTC, WebVR, ARIA, MathML, etc). Given this expertise, the AMP Project sponsored Igalia so that they can lead these developments in WebKit. It is worth noting that this project aligns with the Web Predictability effort supported by both Google and Igalia, which aims at making the Web more predictable for developers. In particular, the following aspects are considered:

• Interoperability: Effort is made to write Web Platform Tests (WPT), to follow Web standards and ensure consistent behaviors between web engines or operating systems.
• Compatibility: Changes are carefully analyzed using telemetry techniques or user feedback in order to avoid breaking compatibility with previous versions of WebKit.
• Reducing footguns: Removals of non-standard features (e.g. CSS vendor prefixes) are attempted while new features are carefully introduced.

Below we provide further description of the WebKit improvements, showing concretely how the above principles are followed.

## Frame sandboxing

A sandbox attribute can be specified on the iframe element in order to enable a set of restrictions on any content it hosts. These conditions can be relaxed by specifying a list of values such as allow-scripts (to allow javascript execution in the frame) or allow-popups (to allow the frame to open popups). By default, the same restrictions apply to a popup opened by a sandboxed frame.

Figure 1: Example of sandboxed frames (Can they navigate their top frame or open popups? Are such popups also sandboxed?)

However, sometimes this behavior is not wanted. Consider for example the case of an advertisement inside a sandboxed frame. If a popup is opened from this frame then it is likely that a non-sandboxed context is desired on the landing page. In order to handle this use case, a new allow-popups-to-escape-sandbox value has been introduced. The value is now supported in Safari Technology Preview 34.

While performing that work, it was noticed that some WPT tests for the sandbox attribute were still failing. It turns out that WebKit does not really follow the rules to allow navigation. More specifically, navigating a top context is never allowed when such context corresponds to an opened popup. We have made some changes to WebKit so that it behaves more closely to the specification. This is integrated into Safari Technology Preview 35 and you can for example try this W3C test. Note that this test requires to change preferences to allow popups.

It is worth noting that web engines may slightly depart from the specification regarding the previously mentioned rules. In particular, WebKit checks a same-origin condition to be sure that one frame is allowed to navigate another one. WebKit always has contained a special case to ignore this condition when a sandboxed frame with the allow-top-navigation flag tries and navigate its top frame. This feature, sometimes known as “frame busting,” has been used by third-party resources to perform malicious auto-redirecting. As a consequence, Chromium developers proposed to restrict frame busting to the case where the navigation is triggered by a user gesture.

According to Chromium’s telemetry frame busting without a user gesture is very rare. But when experimenting with the behavior change of allow-top-navigation several regressions were reported. Hence it was instead decided to introduce the allow-top-navigation-by-user-activation flag in order to provide this improved safety context while still preserving backward compatibility. We implemented this feature in WebKit and it is now available in Safari Technology Preview 37.

Finally, another proposed security improvement is to use an allow-modals flag to explicitly allow sandboxed frames to display modal dialogs (with alert, prompt, etc). That is, the default behavior for sandboxed frames will be to forbid such modal dialogs. Again, such a change of behavior must be done with care. Experiments in Chromium showed that the usage of modal dialogs in sandboxed frames is very low and no users complained. Hence we implemented that behavior in WebKit and the feature should arrive in Safari Technology Preview soon.

Check out the frame sandboxing demos if if you want to test the new allow-popup-to-escape-sandbox, allow-top-navigation-without-user-activation and allow-modals flags.

## Frame scrolling on iOS

Apple’s UI choice was to (almost) always “flatten” (expand) frames so that users do not require to scroll them. The rationale for this is that it avoids to be trapped into hierarchy of nested frames. Changing that behavior is likely to cause a big backward compatibility issue on iOS so for now we proposed a less radical solution: Add a heuristic to support the case of “fullscreen” iframes used by the AMP Project. Note that such exceptions already exist in WebKit, e.g. to avoid making offscreen content visible.

We thus added the following heuristic into WebKit Nightly: do not flatten out-of-flow iframes (e.g. position: absolute) that have viewport units (e.g. vw and vh). This includes the case of the “fullscreen” iframe previously mentioned. For now it is still under a developer flag so that WebKit developers can control when they want to enable it. Of course, if this is successful we might consider more advanced heuristics.

The fact that frames are never scrollable in iOS is an obvious interoperability issue. As a workaround, it is possible to emulate such “scrollable nodes” behavior using overflow: scroll nodes with the -webkit-overflow-scrolling: touch property set. This is not really ideal for our Web Predictability goal as we would like to get rid of browser vendor prefixes. Also, in practice such workarounds lead to even more problems in AMP as explained in these blog posts. That’s why implementing scrolling of frames is one of the main goals of this project and significant steps have already been made in that direction.

Figure 2: C++ classes involved in frame scrolling

The (relatively complex) class hierarchy involved in frame scrolling is summarized in Figure 2. The frame flattening heuristic mentioned above is handled in the WebCore::RenderIFrame class (in purple). The WebCore::ScrollingTreeFrameScrollingNodeIOS and WebCore::ScrollingTreeOverflowScrollingNodeIOS classes from the scrolling tree (in blue) are used to scroll, respectively, the main frame and overflow nodes on iOS. Scrolling of non-main frames will obviously have some code to share with the former, but it will also have some parts in common with the latter. For example, passing an extra UIScrollView layer is needed instead of relying on the one contained in the WKWebView of the main frame. An important step is thus to introduce a special class for scrolling inner frames that would share some logic from the two other classes and some refactoring to ensure optimal code reuse. Similar refactoring has been done for scrolling node states (in red) to move the scrolling layer parameter into WebCore::ScrollingStateNode instead of having separate members for WebCore::ScrollingStateOverflowScrollingNode and WebCore::ScrollingStateFrameScrollingNode.

The scrolling coordinator classes (in green) are also important, for example to handle hit testing. At the moment, this is not really implemented for overflow nodes but it might be important to have it for scrollable frames. Again, one sees that some logic is shared for asynchronous scrolling on macOS (WebCore::ScrollingCoordinatorMac) and iOS (WebCore::ScrollingCoordinatorIOS) in ancestor classes. Indeed, our effort to make frames scrollable on iOS is also opening the possibility of asynchronous scrolling of frames on macOS, something that is currently not implemented.

Figure 4: Video of this demo page on WebKit iOS with experimental patches to make frame scrollables (2017/07/10)

Finally, some more work is necessary in the render classes (purple) to ensure that the layer hierarchies are correctly built. Patches have been uploaded and you can view the result on the video of Figure 4. Notice that this work has not been reviewed yet and there are known bugs, for example with overlapping elements (hit testing not implemented) or position: fixed elements.

Various other scrolling bugs were reported, analyzed and sometimes fixed by Apple. The switch from overflow nodes to scrollable iframes is unlikely to address them. For example, the “Find Text” operation in iOS has advanced features done by the UI process (highlight, smart magnification) but the scrolling operation needed only works for the main frame. It looks like this could be fixed by unifying a bit the scrolling code path with macOS. There are also several jump and flickering bugs with position: fixed nodes. Finally, Apple fixed inconsistent scrolling inertia used for the main frame and the one used for inner scrollable nodes by making the former the same as the latter.

## Root Scroller

The CSSOM View specification extends the DOM element with some scrolling properties. That specification indicates that the element to consider to scroll the main view is document.body in quirks mode while it is document.documentElement in no-quirks mode. This is the behavior that has always been followed by browsers like Firefox or Interner Explorer. However, WebKit-based browsers always treat document.body as the root scroller. This interoperability issue has been a big problem for web developers. One convenient workaround was to introduce the document.scrollingElement which returns the element to use for scrolling the main view (document.body or document.documentElement) and was recently implemented in WebKit. Use this test page to verify whether your browser supports the document.scrollingElement property and which DOM element is used to scroll the main view in no-quirks mode.

Nevertheless, this does not solve the issue with existing web pages. Chromium’s Web Platform Predictability team has made a huge communication effort with Web authors and developers which has drastically reduced the use of document.body in no-quirks mode. For instance, Chromium’s telemetry on Figure 3 indicates that the percentage of document.body.scrollTop in no-quirks pages has gone from 18% down to 0.0003% during the past three years. Hence the Chromium team is now considering shipping the standard behavior.

Figure 3: Use of document.body.scrollTop in no-quirks mode over time (Chromium's UseCounter)

In WebKit, the issue has been known for a long time and an old attempt to fix it was reverted for causing regressions. For now, we imported the CSSOM View tests and just marked the one related to the scrolling element as failing. An analysis of the situation has been left on WebKit’s bug; Depending on how things evolve on Chromium’s side we could consider the discussion and implementation work in WebKit.

Related to that work, a new API is being proposed to set the root scroller to an arbitrary scrolling element, giving more flexibility to authors of Web applications. Today, this is unfortunately not possible without losing some of the special features of the main view (e.g. on iOS, Safari’s URL bar is hidden when scrolling the main view to maximize the screen space). Such API is currently being experimented in Chromium and we plan to investigate whether this can be implemented in WebKit too.

## Conclusion

In the past months, The AMP Project and Igalia have worked on analyzing some interoperability issue and fixing them in WebKit. Many improvements for frame sandboxing are going to be available soon. Significant progress has also been made for frame scrolling on iOS and collaboration continues with Apple reviewers to ensure that the work will be integrated in future versions of WebKit. Improvements to “root scrolling” are also being considered although they are pending on the evolution of the issues on Chromium’s side. All these efforts are expected to be useful for WebKit users and the Web platform in general.

Last but not least, I would like to thank Apple engineers Simon Fraser, Chris Dumez, and Youenn Fablet for their reviews and help, as well as Google and the AMP team for supporting that project.

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