MathML Refresh Heads up

# Frédéric Wang (7 days ago)

Hello WebKit developers,

As some of you may know, Igalia is working on MathML support in Chromium this year [1]. As part of that effort we joined a new MathML Refresh Community Group [2] and one goal is to focus on a core spec for browser implementations [3] to:

  • Remove deprecated/uncommon/duplicate math features that could be implemented by polyfills (relying on MathML core and other web technologies).
  • Add more detailed algorithms (based on TeX/OpenType/CSS layout) to help implementation and conformance testing.
  • Align MathML with CSS/HTML (parsing, layout...), introducing new web platform features (CSS, fonts...) for math if necessary.

We expect that this effort will improve browser interoperability and reduce complexity of current implementations.

This is just a heads up to say that we will send patches to update/remove/add features. For people who are interested, we opened a meta bug to track these changes [4].

Frédéric Wang and Rob Buis,

[1] mathml.igalia.com [2] mathml-refresh.github.io [3] mathml-refresh.github.io/mathml-core [4] bugs.webkit.org/show_bug.cgi?id=195797

Contact us to advertise here
# Ryosuke Niwa (7 days ago)

On Fri, Mar 15, 2019 at 3:08 AM Frédéric Wang <fwang at igalia.com> wrote:

Hello WebKit developers,

As some of you may know, Igalia is working on MathML support in Chromium this year [1]. As part of that effort we joined a new MathML Refresh Community Group [2] and one goal is to focus on a core spec for browser implementations [3] to:

  • Remove deprecated/uncommon/duplicate math features that could be implemented by polyfills (relying on MathML core and other web technologies).

I'd be very much concerned about backwards compatibility here when it come to removing any features. It's important to notice that WebKit is also used by hundreds of thousands of iOS apps and macOS apps. How do we know we won't break those applications?

In general, I don't agree with whatever Google said about MathML being too complex, etc...

  • Add more detailed algorithms (based on TeX/OpenType/CSS layout) to

    help implementation and conformance testing.

    • Align MathML with CSS/HTML (parsing, layout...), introducing new web platform features (CSS, fonts...) for math if necessary.

On the other hand, these seem like very valuable improvements.

We expect that this effort will improve browser interoperability and

reduce complexity of current implementations.

Given there aren't too many websites that deploy MathML directly on production, my concerns are more about existing iOS and madOS apps that embed WKWebView or WebView / UIWebView and use MathML.

  • R. Niwa
# Myles C. Maxfield (7 days ago)

On Mar 15, 2019, at 11:29 AM, Ryosuke Niwa <rniwa at webkit.org> wrote:

On Fri, Mar 15, 2019 at 3:08 AM Frédéric Wang <fwang at igalia.com <mailto:fwang at igalia.com>> wrote: Hello WebKit developers,

As some of you may know, Igalia is working on MathML support in Chromium this year [1]. As part of that effort we joined a new MathML Refresh Community Group [2] and one goal is to focus on a core spec for browser implementations [3] to:

  • Remove deprecated/uncommon/duplicate math features that could be implemented by polyfills (relying on MathML core and other web technologies).

I'd be very much concerned about backwards compatibility here when it come to removing any features. It's important to notice that WebKit is also used by hundreds of thousands of iOS apps and macOS apps. How do we know we won't break those applications?

In general, I don't agree with whatever Google said about MathML being too complex, etc…

The original sentence doesn’t say they will be removing anything in WebKit. There are plenty of features that have been removed from specs that we continue supporting in WebKit for backwards compatibility.

We could also consider migrating our implementation to a JS polyfill if one exists.

Is there a characterization of which features are planned for deprecation? We might be able to do some analysis on iBooks' and iOS apps’ content.

  • Add more detailed algorithms (based on TeX/OpenType/CSS layout) to help implementation and conformance testing.
  • Align MathML with CSS/HTML (parsing, layout...), introducing new web platform features (CSS, fonts...) for math if necessary.

This sounds wonderful! A more coherent MathML story going forward would be fantastic.

# Frédéric Wang (7 days ago)

and Myles,

Thank you for your reply. First, the exact thing about what will be in MathML Core is still open, people are welcome to join and participate to the MathML CG [1] or comment on the GitHub tracker [2].

Our plan was also to remove features from WebKit but of course ultimately the consensus has to be made in the WebKit community (hence our heads up email). What do you suggest? Should we send "intent to remove" to this mailing list? Or is it enough to cc' Apple reviewers on bugs in order to get the approval? Something else?

For now, these are the features the CG has already agreed to not include in MathML Core (more to come). We would like to propose to remove them from WebKit:

In any case, it would be very appreciated to get some analysis about the usage of MathML markup used in Apple's product. How can we proceed to obtain it?

Thanks,

[1] www.w3.org/community/mathml4 [2] mathml-refresh/mathml/issues

# Ryosuke Niwa (7 days ago)

On Fri, Mar 15, 2019 at 3:33 PM Frédéric Wang <fwang at igalia.com> wrote:

Hi Ryosuke and Myles,

Thank you for your reply. First, the exact thing about what will be in MathML Core is still open, people are welcome to join and participate to the MathML CG [1] or comment on the GitHub tracker [2].

Our plan was also to remove features from WebKit but of course ultimately the consensus has to be made in the WebKit community (hence our heads up email). What do you suggest? Should we send "intent to remove" to this mailing list?

Ultimately, we need some testing to ensure whatever iOS and macOS apps, or websites that specifically target WebKit and Gecko that use MathML don't get broken by those removals. Because there isn't an easy way to do that right now, my suggestion is not remove any features for now.

Put it another way, what's the benefit of removing features in WebKit before fixing other MathML bugs? If the only benefit is that Blink may have an easier time implementing the rest and therefore might be more interoperable, I really don't buy that argument given MathML isn't supported at all in Blink today.

For now, these are the features the CG has already agreed to not include in

MathML Core (more to come). We would like to propose to remove them from WebKit:

These all seem like something out in the wild might be using. search?q=mathml+fontweight&type=Code yields quite a few examples in which fontweight content attribute is being used for example.

In any case, it would be very appreciated to get some analysis about the

usage of MathML markup used in Apple's product. How can we proceed to obtain it?

Unfortunately, there isn't an easy way to do this right now. I wish there was, and it's something we want to improve over time.

  • R. Niwa
# Maciej Stachowiak (7 days ago)

On Mar 15, 2019, at 3:33 PM, Frédéric Wang <fwang at igalia.com> wrote:

Hi Ryosuke and Myles,

Thank you for your reply. First, the exact thing about what will be in MathML Core is still open, people are welcome to join and participate to the MathML CG [1] or comment on the GitHub tracker [2].

Our plan was also to remove features from WebKit but of course ultimately the consensus has to be made in the WebKit community (hence our heads up email). What do you suggest? Should we send "intent to remove" to this mailing list? Or is it enough to cc' Apple reviewers on bugs in order to get the approval? Something else?

It’s easier for us to check Apple Books and iOS App compatibility for a batch of possible removals at once, instead of one at a time. We can start by looking at the set of items below.

It’s helpful to give a heads-up other than the normal review process, because our main concern is compatibility, and not all reviewers will be able to easily access the corpus of app-specific or books-specific content that may be affected.

We assume web compatibility is not a major issue since MathML isn’t in all browsers and in general is not widely used on websites, but there might also be some value in doing web usage analysis for these features if there’s any meaningful web usage of MathML at all.

# Frédéric Wang (2 days ago)

On 16/03/2019 00:29, Maciej Stachowiak wrote:

It’s easier for us to check Apple Books and iOS App compatibility for a batch of possible removals at once, instead of one at a time. We can start by looking at the set of items below.

It’s helpful to give a heads-up other than the normal review process, because our main concern is compatibility, and not all reviewers will be able to easily access the corpus of app-specific or books-specific content that may be affected.

We assume web compatibility is not a major issue since MathML isn’t in all browsers and in general is not widely used on websites, but there might also be some value in doing web usage analysis for these features if there’s any meaningful web usage of MathML at all.

We'll try to provide heads-up on this mailing list and will work with the MathML Refresh CG in order to get more statistics. Having data from Apple products would be very useful, here are some first questions (this includes elements/attributes/values raised by the CG for removal/deprecation but most have not been decided yet):

  • Usage statistics for MathML elements used. More specifically, which of the following elements are used: munder, mover, msub, msup, msubsup, mlabeledtr, merror, mphantom, maction, mglyph, mfenced, mstyle, ms

  • Usage statistics for MathML attributes. More specifically, which of the following attributes are used: mathvariant, numalign, denomalign, align (on munderover/munder/mover elements), bevelled, subscripshift, superscriptshift, other, macros, mode, fontfamily, index, fontfamily, fontweight, fontstyle, fontsize, color, background, veryverythinmathspace, verythinmathspace, thinmathspace, mediummathspace, thickmathspace, verythickmathspace, veryverythickmathspace

  • Usage statistics for MathML attributes on the mstyle and math elements. More specifically, do mstyle elements use any attribute other than displaystyle, dir, mathsize, mathbackground, mathcolor, mathvariant, scriptlevel?

  • Attribute values. Is any of the following attribute used?

    • linethickness attribute with value "thin", "thick" or "medium"
    • mathsize attribute with value "small", "normal" or "big"
    • attribute with value a nonzero number without unit (e.g. "4") other than scriptlevel
    • attribute with value "veryverythinmathspace", "verythinmathspace", "thinmathspace", "mediummathspace", "thickmathspace", "verythickmathspace" or "veryverythickmathspace".
    • notation attribute containing the value "radical" (e.g. notation="radical circle")
    • attribute with leading or trailing white space characters (U+0020, U+0009, U+000A, U+000D or U+000C). For example width=" 5em ".
  • Trailing/leading whitespace in token elements (mi, mtext, mn, mo, mtext, ms). Do token elements contain text content with leading or trailing white space characters (U+0020, U+0009, U+000A, U+000D or U+000C). For example <mi> x </mi>.

Thanks,

# Frédéric Wang (2 days ago)

On 16/03/2019 00:04, Ryosuke Niwa wrote:

On Fri, Mar 15, 2019 at 3:33 PM Frédéric Wang <fwang at igalia.com

<mailto:fwang at igalia.com>> wrote:

Hi Ryosuke and Myles,

Thank you for your reply. First, the exact thing about what will
be in MathML Core is still open, people are welcome to join and
participate to the MathML CG [1] or comment on the GitHub tracker [2].

Our plan was also to remove features from WebKit but of course
ultimately the consensus has to be made in the WebKit community
(hence our heads up email). What do you suggest? Should we send
"intent to remove" to this mailing list?

Ultimately, we need some testing to ensure whatever iOS and macOS apps, or websites that specifically target WebKit and Gecko that use MathML don't get broken by those removals. Because there isn't an easy way to do that right now, my suggestion is not remove any features for now.

I agree on the goal but disagree on the suggestion. At minimum, we should decide each case separately and try to collect some data before.

Put it another way, what's the benefit of removing features in WebKit before fixing other MathML bugs?

This question sounds rhetorical, but basically this is already said in the initial email: improve browser interoperability and reduce complexity of current implementations. Especially, at Igalia we are working on several engines in parallel and it's much easier if the implementation logic and set of WPT tests is consistent in order to compare the code, fix bugs and implement new features. Maintaining WebKits-specific features and tests would be an extra burden, so it would be preferable to avoid it when possible.

If the only benefit is that Blink may have an easier time implementing the rest and therefore might be more interoperable, I really don't buy that argument given MathML isn't supported at all in Blink today.

Note that you are the only one who suggested on this thread that our WebKit announcement is made according to Google's opinion or Blink's development plan... I get that having more features in Gecko/WebKit might be an interoperability concern and maybe Apple actually has more information from Google, but so far Google people actually seem more interested in the two other points of the initial email.

FWIW, the removal/deprecation discussions are currently led by the MathML Refresh CG (which include browser implementers from Mozilla/Igalia, people from the former Math WG, scholars, publishers, a11y experts, authors of MathML tools...) and rely heavily on the experience from WebKit/Gecko/Stylo implementations.

These all seem like something out in the wild might be using. search?q=mathml+fontweight&type=Code yields quite a few examples in which fontweight content attribute is being used for example.

MathML is used as an exchange format in various tools, standards and documents so that's not really surprising to get matches. However, the MathML Core spec targets usage in web engines so what we need instead is to check content that is actually served to web engines in general and to WebKit in particular.

Note: There are straighforward CSS polyfills for the attributes previously mentioned. A JS polyfill would be needed for MathML nonzero unitless lengths (if they are really used) but removing the possibility to write "5" instead of "500%" is part of the general goal to align more with HTML/CSS. Regarding fontweight, it is known to require some extra code/tests in Gecko/Stylo in order to handle conflicts with mathvariant ( WebKit doesn't handle such conflicts trac.webkit.org/browser/webkit/trunk/Source/WebCore/mathml/MathMLElement.cpp#L122 ).

# Ryosuke Niwa (2 days ago)

On Wed, Mar 20, 2019 at 5:57 AM Frédéric Wang <fwang at igalia.com> wrote:

On 16/03/2019 00:04, Ryosuke Niwa wrote:

On Fri, Mar 15, 2019 at 3:33 PM Frédéric Wang <fwang at igalia.com> wrote:

Hi Ryosuke and Myles,

Thank you for your reply. First, the exact thing about what will be in MathML Core is still open, people are welcome to join and participate to the MathML CG [1] or comment on the GitHub tracker [2].

Our plan was also to remove features from WebKit but of course ultimately the consensus has to be made in the WebKit community (hence our heads up email). What do you suggest? Should we send "intent to remove" to this mailing list?

Ultimately, we need some testing to ensure whatever iOS and macOS apps, or websites that specifically target WebKit and Gecko that use MathML don't get broken by those removals. Because there isn't an easy way to do that right now, my suggestion is not remove any features for now.

I agree on the goal but disagree on the suggestion. At minimum, we should decide each case separately and try to collect some data before.

We can continue to agree to disagree on this point. But I strongly object to removing any features from MathML implementation of WebKit without having done comprehensive compatibility testing with various iOS and macOS apps that use MathML.

Put it another way, what's the benefit of removing features in WebKit

before fixing other MathML bugs?

This question sounds rhetorical, but basically this is already said in the initial email: improve browser interoperability and reduce complexity of current implementations Especially, at Igalia we are working on several engines in parallel and it's much easier if the implementation logic and set of WPT tests is consistent in order to compare the code, fix bugs and implement new features.

Then the best way to achieve that will be implementing what WebKit and Gecko implement in Blink, not remove features from WebKit and Gecko.

Maintaining WebKits-specific features and tests would be an extra burden, so it would be preferable to avoid it when possible.

I see why you'd prefer that but making one's job easier by breaking backwards compatibility with exiting apps and websites is not a good trade off.

If the only benefit is that Blink may have an easier time implementing the rest and therefore might be more interoperable, I really don't buy that argument given MathML isn't supported at all in Blink today.

Note that you are the only one who suggested on this thread that our WebKit announcement is made according to Google's opinion or Blink's development plan... I get that having more features in Gecko/WebKit might be an interoperability concern and maybe Apple actually has more information from Google, but so far Google people actually seem more interested in the two other points of the initial email.

I really don't care what maintainers of Blink say or do about MathML because they don't have MathML implementation right now. My primary concern as I've stated multiple times is iOS and macOS apps that currently use MathML.

These all seem like something out in the wild might be using. search?q=mathml+fontweight&type=Code yields quite a few examples in which fontweight content attribute is being used for example.

MathML is used as an exchange format in various tools, standards and documents so that's not really surprising to get matches. However, the MathML Core spec targets usage in web engines so what we need instead is to check content that is actually served to web engines in general and to WebKit in particular.

Note: There are straighforward CSS polyfills for the attributes previously mentioned. A JS polyfill would be needed for MathML nonzero unitless lengths (if they are really used) but removing the possibility to write "5" instead of "500%" is part of the general goal to align more with HTML/CSS. Regarding fontweight, it is known to require some extra code/tests in Gecko/Stylo in order to handle conflicts with mathvariant ( WebKit doesn't handle such conflicts trac.webkit.org/browser/webkit/trunk/Source/WebCore/mathml/MathMLElement.cpp#L122 ).

An existence of a bug in our code is not an evidence that the entire feature can be removed.

  • R. Niwa
# Ryosuke Niwa (2 days ago)

On Wed, Mar 20, 2019 at 10:42 AM Ryosuke Niwa <rniwa at webkit.org> wrote:

On Wed, Mar 20, 2019 at 5:57 AM Frédéric Wang <fwang at igalia.com> wrote:

On 16/03/2019 00:04, Ryosuke Niwa wrote:

On Fri, Mar 15, 2019 at 3:33 PM Frédéric Wang <fwang at igalia.com> wrote:

Hi Ryosuke and Myles,

Thank you for your reply. First, the exact thing about what will be in MathML Core is still open, people are welcome to join and participate to the MathML CG [1] or comment on the GitHub tracker [2].

Our plan was also to remove features from WebKit but of course ultimately the consensus has to be made in the WebKit community (hence our heads up email). What do you suggest? Should we send "intent to remove" to this mailing list?

Ultimately, we need some testing to ensure whatever iOS and macOS apps, or websites that specifically target WebKit and Gecko that use MathML don't get broken by those removals. Because there isn't an easy way to do that right now, my suggestion is not remove any features for now.

I agree on the goal but disagree on the suggestion. At minimum, we should decide each case separately and try to collect some data before.

We can continue to agree to disagree on this point. But I strongly object to removing any features from MathML implementation of WebKit without having done comprehensive compatibility testing with various iOS and macOS apps that use MathML.

Put it another way, what's the benefit of removing features in WebKit

before fixing other MathML bugs?

This question sounds rhetorical, but basically this is already said in the initial email: improve browser interoperability and reduce complexity of current implementations Especially, at Igalia we are working on several engines in parallel and it's much easier if the implementation logic and set of WPT tests is consistent in order to compare the code, fix bugs and implement new features.

Then the best way to achieve that will be implementing what WebKit and Gecko implement in Blink, not remove features from WebKit and Gecko.

Maintaining WebKits-specific features and tests would be an extra burden, so it would be preferable to avoid it when possible.

I see why you'd prefer that but making one's job easier by breaking backwards compatibility with exiting apps and websites is not a good trade off.

I guess one way to satisfy your desire without breaking WebKit in iOS and macOS would be to add a runtime feature flag which disables the parts of MathML that's not a part of core MathML, and then only enable this feature in your own port. That would allow you to have the same set of features between your products without breaking our ports.

If the only benefit is that Blink may have an easier time implementing the

# Frédéric Wang (20 hours ago)

On 20/03/2019 20:45, Ryosuke Niwa wrote: >

I agree on the goal but disagree on the suggestion. At minimum, we should decide each case separately and try to collect some data before.

We can continue to agree to disagree on this point. But I strongly
object to removing any features from MathML implementation of
WebKit without having done comprehensive compatibility testing
with various iOS and macOS apps that use MathML.

I'm also happy with more testing with iOS / macOS apps. I was just concerned by the "for now" and the "there isn't any easy way to do it" in your initial emails, it seems you were not open to accept any change for an undetermined period of time, just because of your ports...

    I guess one way to satisfy your desire without breaking WebKit
    in iOS and macOS would be to add a runtime feature flag which
    disables the parts of MathML that's not a part of core MathML,
    and then only enable this feature in your own port. That would
    allow you to have the same set of features between your
    products without breaking our ports.

...however that proposal from you last email sounds more constructive. That would still be extra burden for us to manage deprecated MathML code and the corresponding tests, but at least that will give us the opportunity to start disabling features & run tests without them, to better see which parts we can ignore when comparing code between web engines and even to have beta testers providing feedback. So that seems a good trade off until Apple is ready to accept the changes (or not).

    I really don't care what maintainers of Blink say or do about
    MathML because they don't have MathML implementation right
    now. My primary concern as I've stated multiple times is iOS
    and macOS apps that currently use MathML.

Again, you are the one who brought up that topic in this thread. If you really don't care about Blink maintainers or Google's opinion then please just don't mention them.

    These all seem like something out in the wild might be
    using. https://github.com/search?q=mathml+fontweight&type=Code yields
    quite a few examples in which fontweight content attribute is
    being used for example.
    MathML is used as an exchange format in various tools,
    standards and documents so that's not really surprising to get
    matches. However, the MathML Core spec targets usage in web
    engines so what we need instead is to check content that is
    actually served to web engines in general and to WebKit in
    particular.

    Note: There are straighforward CSS polyfills for the
    attributes previously mentioned. A JS polyfill would be needed
    for MathML nonzero unitless lengths (if they are really used)
    but removing the possibility to write "5" instead of "500%" is
    part of the general goal to align more with HTML/CSS.
    Regarding fontweight, it is known to require some extra
    code/tests in Gecko/Stylo in order to handle conflicts with
    mathvariant ( WebKit doesn't handle such conflicts
    https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/mathml/MathMLElement.cpp#L122
    ).

An existence of a bug in our code is not an evidence that the
entire feature can be removed.

That was not my point. I was just trying to explain that there are more issues involved when you analyze carefully each case, you cannot just rely on generic claims, quick searches or unilateral approaches in order to make a decision. Anyway that was just a side note, it's probably not worth entering into details on this mailing list.

Thank you,

# Ryosuke Niwa (20 hours ago)

On Thu, Mar 21, 2019 at 9:42 AM Frédéric Wang <fwang at igalia.com> wrote:

On 20/03/2019 20:45, Ryosuke Niwa wrote:

I agree on the goal but disagree on the suggestion. At minimum, we should decide each case separately and try to collect some data before.

We can continue to agree to disagree on this point. But I strongly object to removing any features from MathML implementation of WebKit without having done comprehensive compatibility testing with various iOS and macOS apps that use MathML.

I'm also happy with more testing with iOS / macOS apps. I was just concerned by the "for now" and the "there isn't any easy way to do it" in your initial emails, it seems you were not open to accept any change for an undetermined period of time, just because of your ports...

Yes, in general, I don't think we should be any feature from WebKit unless there is a good evidence that the removal won't affect any website or apps. This topic comes up of wanting to remove a feature comes up every now and then, and my answer is always that we should never remove a feature. The corollary of this position is that we should never add a feature unless it's absolutely necessary because we can never remove it once it's added.

I guess one way to satisfy your desire without breaking WebKit in iOS and

macOS would be to add a runtime feature flag which disables the parts of MathML that's not a part of core MathML, and then only enable this feature in your own port. That would allow you to have the same set of features between your products without breaking our ports.

...however that proposal from you last email sounds more constructive. That would still be extra burden for us to manage deprecated MathML code and the corresponding tests, but at least that will give us the opportunity to start disabling features & run tests without them, to better see which parts we can ignore when comparing code between web engines and even to have beta testers providing feedback. So that seems a good trade off until Apple is ready to accept the changes (or not).

I really don't care what maintainers of Blink say or do about MathML

because they don't have MathML implementation right now. My primary concern as I've stated multiple times is iOS and macOS apps that currently use MathML.

Again, you are the one who brought up that topic in this thread. If you really don't care about Blink maintainers or Google's opinion then please just don't mention them.

Well, you're the one who brought up Chromium in the very first email:

As some of you may know, Igalia is working on MathML support in Chromium this year

I think it would have been best if you didn't mention it if you didn't talk to talk about.

Want more features?

Request early access to our private beta of readable email premium.