Intent to Ship: MathML
Frédéric Wang
Contact emails
fw...@chromium.org, rb...@chromium.org, bkar...@igalia.comExplainer
https://github.com/mathml-refresh/mathml-core/blob/master/docs/explainer.mdhttps://people.igalia.com/fwang/explainer-font-family-math
Specification
https://mathml-refresh.github.io/mathml-coreDesign docs
https://drafts.csswg.org/css-fonts-4/#valdef-font-family-math
https://w3c.github.io/mathml-aam
https://docs.google.com/document/d/1biGEaWN8ThNTDtAbT1M5GIf6N5uQLWdxh2QhrG9uN5c
https://docs.google.com/document/d/1bvY_Npe2zLW_705KXdmecsH6P9I9wBMpHRsZ9CxWNOI/edit#heading=h.u9hwm9tp8nuy
Summary
Adds native DOM/IDL, accessibility support and CSS-compatible OpenType-based layout of mathematical formulas. The reference specifications are MathML Core (which describes in extensive details a fundamental subset of the MathML 3 recommendation), MathML AAM (which describes mapping to platform accessibility APIs). This includes the "math" font-family as well as features included in section "CSS Extensions for Math Layout".
Blink component
BlinkSearch tags
mathmlTAG review
https://github.com/w3ctag/design-reviews/issues/438 https://github.com/w3ctag/design-reviews/issues/313#issuecomment-460523527TAG review status
Issues addressedRisks
Interoperability and Compatibility
- This is not implementing the complete list of MathML3, OpenType MATH or accessibility features that one can find in other browsers.
- New enhancements (e.g. clarification regarding CSS
interoperability) may not be implemented in other browsers
yet.
- MathML Core and MathML AAM are still working drafts.
Gecko: Shipped/Shipping
WebKit: Shipped/Shipping
Web developers: Positive (https://twitter.com/search?q=mathml%20chrome&f=live) Users have recently been excited about it, experimented exiting implementation under a flag and are eager to see it shipped soon. It is currently the 5th most starred Blink issue, see https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component:Blink&sort=-stars&colspec=ID%20Stars%20Pri%20Status%20Component%20Opened%20Summary
Other signals:
Ergonomics
In the past, MathML trees were not treated specially at all and this was fast ! Now, more work is needed for pages that do math rendering e.g. accessing data from the MATH table, handling operator dictionary, using ink text bounds, performing low-level shaping of stretchy operators, loading and applying CSS UA sheet, or exposing an accessibility tree. However, the only performance report we received so far was issue #1073760, which was discarded after further analysis. In any case, performance is definitely better than existing non-native technologies. Additionally, pages will likely need loading WOFF fonts on operating systems that don't ship math fonts. Work is in progress here, see https://frederic-wang.fr/update-on-open-type-math-fonts.html for recent status.
Activation
- Editing MathML source is difficult but special authoring tools & converters do exist.
- Implementation may not be as complete as expected by users
but the spec tries to allow extensibility and the Math WG
provides polyfills at https://github.com/mathml-refresh/mathml-polyfills
- Users may require WOFF fonts to properly render formulas (see above).
Security
There is a risk due to the new attack surface:
- Relatively large amount of new code.
- Newly exposed APIs.
- Interacting with several parts of the web platform.
However, risks related to violation of layout algorithm are reduced now that the specification clarifies how to perform it in a CSS-compatible way. We've fixed 17 issues reported during 2.5 years of development and there are currently 0 open security issues (last report was in March).
Finally, similar security & privacy considerations as existing layout specifications apply, see the relevant sections from the MathML Core spec: https://w3c.github.io/mathml-core/#security-considerations https://w3c.github.io/mathml-core/#privacy-considerations
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No.
Debuggability
- Nothing particular expected besides what is already provided for SVG and HTML.
- Existing devtools API was extended to handle "font-family: math", see https://chromedevtools.github.io/devtools-protocol/tot/Page/#method-setFontFamilies
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
YesIs this feature fully tested by web-platform-tests?
YesFlag name
MathMLCoreRequires code in //chrome?
True (this is only to implement support for “font-family: math”, which has a user preference menu for math font, see https://docs.google.com/document/d/1bvY_Npe2zLW_705KXdmecsH6P9I9wBMpHRsZ9CxWNOI/edit#heading=h.u9hwm9tp8nuy).Tracking bug
http://crbug.com/6606Sample links
https://people.igalia.com/fwang/2022-06-igalia-week-shipping-mathml-in-chromium/#/12
https://fred-wang.github.io/MathFonts
Estimated milestones
| DevTrial on desktop | 103 |
| DevTrial on Android | 103 |
Anticipated spec changes
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
https://github.com/w3c/csswg-drafts/issues/5866Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5240822173794304Links to previous Intent discussions
Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/OOZIrtSPLeM-- Frédéric Wang
Frédéric Wang
Hello,
My previous email was generated from the information of chromestatus.com ; I’d like to elaborate a bit more about the situation of MathML in Chromium. In 2019, we published a roadmap [1] which we basically implemented downstream the same year. As of today, we consider this roadmap complete upstream, modulo imperfect math layout of stretchy operators due to the limitation of the current LayoutNG architecture (the rendering team is aware of that and consensus is that it’s ok for a first implementation).
In addition, we have been receiving feedback from various people and tried to adjust our initial roadmap accordingly:
- Some concerns were shared by some browser vendors, TAG members or some participants to the “Getting Math onto Web Pages CG” and are summarized on the official TAG’s feedback [2]. During these recent years, we’ve collaborated with the MathML and CSS working groups as well as browser vendors to publish specifications & tests that address these concerns. This also added many new tasks on the roadmap (e.g. new CSS properties, MathMLElement IDL, mixing with CSS/SVG, etc).
- MathML supporters have also been asking a more complete support for MathML3 features, raising concerns about backward compatibility. Apple shares this concern about breaking content from their applications (e.g. Apple Books) and is generally reluctant to remove shipped features. Mozilla has been more positive about that and several patches landed to unship legacy features with low usage. We decided to solve that disagreement by publishing two specifications: MathML Core (intended to be implemented in browsers) and a superset called “MathML Full”. Polyfills for MathML features that are not part of the core spec have also been written. Incidentally, the layering/extensibility effort for (1) became instrumental to write such polyfills.
- We also received feedback about making MathML accessible, so we added that in our plan. We implemented parity with Gecko/WebKit for macOS/NSAccessibility and Linux/ATK. We’ve also been working on a corresponding MathML AAM specification to standardize existing support and we wrote (currently internal) tests for that. Other platforms (Windows, ChromeOS, Android) don’t seem to have any special way to expose MathML nodes to assistive technologies, so instead we continue to rely on existing DOM-based approaches.
- Finally, a lot of users have praised our work, tested existing support by enabling web platform features, reported bugs and they keep asking us when this is going to be officially shipped. Hopefully this intent-to-ship will allow to address that last feedback :-)
At that time, we believe the implementation is good enough for a first release. To be fully transparent these are known issues:
- There are bugs to fix or more features users would like to see. We expect the layering/extensibility approach will make possible to work around current limitations.
- Not all operating systems come with a pre-installed OpenType MATH font, which means poor math rendering on such systems by default. However, Windows has Cambria Math pre-installed and things seem to improve on the macOS & Android side [3]. The workaround for that is to use web fonts (on pages or as a web extension).
- There are a few interactions with CSS properties (e.g. width/height, out-of-flow, etc) that we would like to clarify in the spec and/or the implementation and ensure we have interoperability tests for that. These are likely edge cases for MathML authors but can be important for polyfills.
That’s it, we are looking forward to hearing your feedback !
[1] https://mathml.igalia.com/project/
[2] https://github.com/w3ctag/design-reviews/issues/313#issuecomment-460523527
[3] https://frederic-wang.fr/update-on-open-type-math-fonts.html
-- Frédéric Wang
Chris Harrelson
Web developers: Positive (https://twitter.com/search?q=mathml%20chrome&f=live) Users have recently been excited about it, experimented exiting implementation under a flag and are eager to see it shipped soon. It is currently the 5th most starred Blink issue, see https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component:Blink&sort=-stars&colspec=ID%20Stars%20Pri%20Status%20Component%20Opened%20Summary
Other signals:
Ergonomics
In the past, MathML trees were not treated specially at all and this was fast ! Now, more work is needed for pages that do math rendering e.g. accessing data from the MATH table, handling operator dictionary, using ink text bounds, performing low-level shaping of stretchy operators, loading and applying CSS UA sheet, or exposing an accessibility tree. However, the only performance report we received so far was issue #1073760, which was discarded after further analysis. In any case, performance is definitely better than existing non-native technologies. Additionally, pages will likely need loading WOFF fonts on operating systems that don't ship math fonts. Work is in progress here, see https://frederic-wang.fr/update-on-open-type-math-fonts.html for recent status.
Activation
- Editing MathML source is difficult but special authoring tools & converters do exist.
- Implementation may not be as complete as expected by users but the spec tries to allow extensibility and the Math WG provides polyfills at https://github.com/mathml-refresh/mathml-polyfills
- Users may require WOFF fonts to properly render formulas (see above).
Security
There is a risk due to the new attack surface:
- Relatively large amount of new code.
- Newly exposed APIs.
- Interacting with several parts of the web platform.
However, risks related to violation of layout algorithm are reduced now that the specification clarifies how to perform it in a CSS-compatible way. We've fixed 17 issues reported during 2.5 years of development and there are currently 0 open security issues (last report was in March).
Finally, similar security & privacy considerations as existing layout specifications apply, see the relevant sections from the MathML Core spec: https://w3c.github.io/mathml-core/#security-considerations https://w3c.github.io/mathml-core/#privacy-considerations
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No.
Debuggability
- Nothing particular expected besides what is already provided for SVG and HTML.
- Existing devtools API was extended to handle "font-family: math", see https://chromedevtools.github.io/devtools-protocol/tot/Page/#method-setFontFamilies
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6234d4e1-208b-d3d1-10b3-dddb164c010f%40igalia.com.
Frédéric Wang
Resending since it seems the email failed to be delivered...
-------- Forwarded Message --------
| Subject: | Re: [blink-dev] Intent to Ship: MathML |
|---|---|
| Date: | Thu, 23 Jun 2022 09:24:43 +0200 |
| From: | Frédéric Wang <fw...@igalia.com> |
| To: | Chris Harrelson <chri...@chromium.org> |
| CC: | blink-dev <blin...@chromium.org> |
They ship MathML, but could you speak to the conformance level with the Core spec? In cases where there are gaps, are they going to cause significant web compat issues that will need to be addressed with implementation improvements to other browser implementations?
Chromium implements MathML Core which is smaller than what
WebKit & Gecko have today. If authors stick to formulas
based on the core subset (which we believe should the case for
the majority of existing content), the interoperability is quite
good as can be see visually with
https://people.igalia.com/fwang/2022-06-igalia-week-shipping-mathml-in-chromium/#/5
VS
https://people.igalia.com/fwang/2022-06-igalia-week-shipping-mathml-in-chromium/#/6
In practice interop gaps are more likely to come with existing
MathML3 content that rely on more features. Our proposal is to
rely on polyfills so they work in Chromium too and to try to
carefully deprecate & unship these legacy features from
WebKit/Gecko.
Additionally, if/when web authors & developers start to make
use of them, then we foresee some interop gaps will happen with
the new math-related CSS properties proposed to expose the
internal magic (display: math, font-family: math, math-style,
etc) as well as interaction with existing CSS properties (e.g.
padding/margin/borders to tweak spacing).
So the short answer is that yes there is likely to be interop
gaps and yes some work will be needed on the WebKit/Gecko side.
Igalia actually already started to unship legacy features from
WebKit (under a flag) and Gecko and did a few improvements
regarding the CSS part. We've been focusing mostly on Chromium
since that's where the biggest & most serious interop gap
exist for users (no MathML support at all!) but it's very
possible we'll put more effort on Gecko/WebKit after that
(that's my personal preference but work sponsors may have a
different opinion).
Relatedly, is it the case that the Chromium implementation passes all of the WPT tests and is in complete agreement with the Core spec?
Good question and this is what I presented during the Web Engines Hackfest: https://people.igalia.com/fwang/2022-06-igalia-week-shipping-mathml-in-chromium/#/11
The 3 categories of failures are the following:
1. A large amount of WPT failures are related to CSS
text-transform (https://w3c.github.io/mathml-core/#new-text-transform-mappings)
and the mathvariant attribute (https://w3c.github.io/mathml-core/#the-mathvariant-attribute).
There were some disagreements between CSS and a11y folks in
general here (see https://github.com/w3c/csswg-drafts/issues/3775)
and the outcome of the math-related proposal ( https://github.com/w3c/csswg-drafts/issues/5386
) was only to support automatic italic of variables. Some
members of the Math CG feel strongly about keeping the
mathvariant attribute for backward compatibility with existing
content but as mentioned in the spec, one can actually just use
the Unicode characters after transformation. So we didn't
consider critical to try to push harder for this on the CSS
side, even if we have a patch ready for that ( https://bugs.chromium.org/p/chromium/issues/detail?id=1076420
).
2. Another feature that was initially planned is the href
attribute. One of the issue here is that MathML3 allows links on
*all* MathML elements (rather than just e.g. a dedicated
`<a>` element). Emilio Cobos from Mozilla raised the issue
about the complexity cost of that choice. For example there are
some privacy concerns related to the :visited selector which
requires to implement mitigation, links also needs special to
work with the tabindex attributes, etc Also at the WHATWG, it
was decided a long time ago that linkable elements should not be
able to have a shadow DOM (I believe it was for security reason)
which we feel would prevent some interesting use cases for
extensibility of MathML elements. At the end, we decided to
remove href from the MathML Core specification for now as they
are not really the most critical part of MathML and will discuss
it for a future version, but existing tests written for
WebKit/Gecko are still there. For details see https://github.com/w3c/mathml-core/issues/142
and https://github.com/w3c/mathml-core/issues/63
https://github.com/w3c/mathml-core/issues/69
3. Finally, the remaining important failures are related to
interpretation of CSS specifications (e.g. width/height,
out-of-flow, display, etc) as mentioned at the end of my second
email. Again MathML authors don't really care about this and we
have freedom to choose how we interpret these CSS properties as
long as that doesn't break existing content. However, we believe
it can be quite critical and a source of interoperability
concern if people start to write polyfills and the like on top
of MathML. Here, the issue is that the MathML CG proposed
resolutions to issues, but Chromium reviewers suggested a
different approach during the implementation phase so we have
inconsistencies between spec and implementation, and even
sometimes between two tests. These points were discussed at the
hackfest (
https://people.igalia.com/fwang/2022-06-igalia-week-shipping-mathml-in-chromium/#/13
) and fixing that is the very next task to tackle on our list.
The rest of the failures are less concerning from an interop
point of view, they are either due to some bugs that can be
fixed in Chromium (e.g. implement the new onbeforeload event
attribute) or some issues with the design of legacy MathML tests
(e.g. not relying on a web font for better accuracy).
You mentioned in your other email that some platforms don't have good enough pre-installed Math fonts. It seems your recommendation would be to make sure STIX Two Math is installed, and macOS will have that soon.
Have you inquired about ChromeOS also?
What will math look like on platforms that don't have a pre-installed font, and for pages that don't use a web font? Will it not render at all or render with illogical fallback glyphs?
So this is a quotation from the "font-family: math" design doc: "The math font family is intended for displaying mathematical expressions. Such expressions not only require special symbols but also extra data provided by the OpenType MATH table such as dedicated layout parameters or stretchy constructions. Except for very simple cases, mathematical formulas will render poorly without such a math font."
https://frederic-wang.fr/update-on-open-type-math-fonts.html
provides some screenshots with Cambria Math (shipped on
Windows), STIX Two Math (shipped on macOS13 Ventura beta,
packages available in most Linux distros) and Latin Modern Math
(packages available in most Linux distros and likely to be
installed with TeX).
Regarding ChromeOS and Android, i understand they both ship
Roboto & Noto families. There is a Noto math font which
addresses the "No Tofu" for mathematical symbols from the
relevant unicode blocks ; this is enough for simple math and
even makes more complex formulas readable. However, it currently
lacks an OpenType MATH table and so won't work well with more
advanced constructions that require glyph stretching, proper
spacing, and the like. I'm attaching screenshots of Chromium
102, Firefox 101 and WebKitGTK 2.36.3 on Linux with Noto Sans
Math vs STIX Two Math vs Latin Modern. Note that Chromium won't
stretch the radical symbol and won't make the integral big ;
WebKit works around the first issue by using a scale transform
(glyph distorted) while Gecko works around both of them by
fallbacking to an available OpenType MATH fonts on the system
(glyphs from Latin Modern Math).
Again we discussed this during the hackfest. We proposed to
consider the STIX font but it seems others are currently
considering to add a MATH table to the Noto Sans Math font: https://github.com/notofonts/math/issues/14#issuecomment-1161414437
-- Frédéric Wang
Frédéric Wang
They ship MathML, but could you speak to the conformance level with the Core spec? In cases where there are gaps, are they going to cause significant web compat issues that will need to be addressed with implementation improvements to other browser implementations?
Chromium implements MathML Core which is smaller than what WebKit
& Gecko have today. If authors stick to formulas based on the
core subset (which we believe should the case for the majority of
existing content), the interoperability is quite good as can be
see visually with
https://people.igalia.com/fwang/2022-06-igalia-week-shipping-mathml-in-chromium/#/5
VS
https://people.igalia.com/fwang/2022-06-igalia-week-shipping-mathml-in-chromium/#/6
In practice interop gaps are more likely to come with existing
MathML3 content that rely on more features. Our proposal is to
rely on polyfills so they work in Chromium too and to try to
carefully deprecate & unship these legacy features from
WebKit/Gecko.
Additionally, if/when web authors & developers start to make
use of them, then we foresee some interop gaps will happen with
the new math-related CSS properties proposed to expose the
internal magic (display: math, font-family: math, math-style, etc)
as well as interaction with existing CSS properties (e.g.
padding/margin/borders to tweak spacing).
So the short answer is that yes there is likely to be interop gaps
and yes some work will be needed on the WebKit/Gecko side. Igalia
actually already started to unship legacy features from WebKit
(under a flag) and Gecko and did a few improvements regarding the
CSS part. We've been focusing mostly on Chromium since that's
where the biggest & most serious interop gap exist for users
(no MathML support at all!) but it's very possible we'll put more
effort on Gecko/WebKit after that (that's my personal preference
but work sponsors may have a different opinion).
Relatedly, is it the case that the Chromium implementation passes all of the WPT tests and is in complete agreement with the Core spec?
Good question and this is what I presented during the Web Engines Hackfest: https://people.igalia.com/fwang/2022-06-igalia-week-shipping-mathml-in-chromium/#/11
The 3 categories of failures are the following:
1. A large amount of WPT failures are related to CSS
text-transform
(https://w3c.github.io/mathml-core/#new-text-transform-mappings)
and the mathvariant attribute
(https://w3c.github.io/mathml-core/#the-mathvariant-attribute).
There were some disagreements between CSS and a11y folks in
general here (see https://github.com/w3c/csswg-drafts/issues/3775)
and the outcome of the math-related proposal (
https://github.com/w3c/csswg-drafts/issues/5386 ) was only to
support automatic italic of variables. Some members of the Math CG
feel strongly about keeping the mathvariant attribute for backward
compatibility with existing content but as mentioned in the spec,
one can actually just use the Unicode characters after
transformation. So we didn't consider critical to try to push
harder for this on the CSS side, even if we have a patch ready for
that (
https://bugs.chromium.org/p/chromium/issues/detail?id=1076420 ).
2. Another feature that was initially planned is the href
attribute. One of the issue here is that MathML3 allows links on
*all* MathML elements (rather than just e.g. a dedicated
`<a>` element). Emilio Cobos from Mozilla raised the issue
about the complexity cost of that choice. For example there are
some privacy concerns related to the :visited selector which
requires to implement mitigation, links also needs special to work
with the tabindex attributes, etc Also at the WHATWG, it was
decided a long time ago that linkable elements should not be able
to have a shadow DOM (I believe it was for security reason) which
we feel would prevent some interesting use cases for extensibility
of MathML elements. At the end, we decided to remove href from the
MathML Core specification for now as they are not really the most
critical part of MathML and will discuss it for a future version,
but existing tests written for WebKit/Gecko are still there. For
details see https://github.com/w3c/mathml-core/issues/142 and
https://github.com/w3c/mathml-core/issues/63
https://github.com/w3c/mathml-core/issues/69
3. Finally, the remaining important failures are related to
interpretation of CSS specifications (e.g. width/height,
out-of-flow, display, etc) as mentioned at the end of my second
email. Again MathML authors don't really care about this and we
have freedom to choose how we interpret these CSS properties as
long as that doesn't break existing content. However, we believe
it can be quite critical and a source of interoperability concern
if people start to write polyfills and the like on top of MathML.
Here, the issue is that the MathML CG proposed resolutions to
issues, but Chromium reviewers suggested a different approach
during the implementation phase so we have inconsistencies between
spec and implementation, and even sometimes between two tests.
These points were discussed at the hackfest (
https://people.igalia.com/fwang/2022-06-igalia-week-shipping-mathml-in-chromium/#/13
) and fixing that is the very next task to tackle on our list.
The rest of the failures are less concerning from an interop point
of view, they are either due to some bugs that can be fixed in
Chromium (e.g. implement the new onbeforeload event attribute) or
some issues with the design of legacy MathML tests (e.g. not
relying on a web font for better accuracy).
You mentioned in your other email that some platforms don't have good enough pre-installed Math fonts. It seems your recommendation would be to make sure STIX Two Math is installed, and macOS will have that soon.
Have you inquired about ChromeOS also?
What will math look like on platforms that don't have a pre-installed font, and for pages that don't use a web font? Will it not render at all or render with illogical fallback glyphs?
So this is a quotation from the "font-family: math" design doc: "The math font family is intended for displaying mathematical expressions. Such expressions not only require special symbols but also extra data provided by the OpenType MATH table such as dedicated layout parameters or stretchy constructions. Except for very simple cases, mathematical formulas will render poorly without such a math font."
Morten Stenshorne
Since the layout implementation of MathML is pure NG (i.e. it has no
legacy engine counterpart), you should be aware that this is somewhat
uncharted territory. We *do* have mechanisms that kick in when we need
to fall back to legacy layout (e.g. when printing, or when there are
tables inside multicol), and have NG-only content inside (such as
MathML), but no pure NG features have shipped yet, so we don't really
know how well this works on the world wild web.
That said, we're also about to ship container queries, which has the
same problem - so you're not alone. I was hoping that we'd be rid of the
legacy engine completely before we started shipping pure NG features,
because of this risk. I'm not saying that we definitely need to wait for
the legacy engine to be completely gone, but you need to be aware of the
risk, at least. Maybe clusterfuzz will find something interesting once
this feature is switched to "stable". :)
By the way, I just tested, and MathML inside legacy layout doesn't seem
to work. I filed
https://bugs.chromium.org/p/chromium/issues/detail?id=1338882
Morten Stenshorne, Software developer,
Blink/Layout, Google, Oslo, Norway
Frédéric Wang
Thanks for raising this issue, I forgot to mention it. We experimented
this in the past and IIRC we found issues with:
- Printing: indeed printing pages with math is likely to happen!
- Multicol: Wikipedia uses that for the "References" section at the
bottom of articles and some pages actually do use math inside!
- SVG: definitely needed for math in graphics. This is no longer an
issue now that foreignObject was implemented in LayoutNG.
- Editing: I'm not sure what's the status of EditingNG but I believe we
wanted to disable editability on MathML anyway due to complexity for
editing math, which will require some tree fixup. This is better handled
by other tools.
I don't remember what was the recent status, but we definitely need to
check again. I believe we have crash tests in WPT and another to check
correct layout for math-in-svg.
Chris Harrelson
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/37ca5f43-60a8-54a6-e2e6-f781fe8c71bd%40igalia.com.
Frédéric Wang
Morten was actually only mentioning the case when table is within a multicol so probably that excludes the Wikipedia use case (I'm going to do more checks there).
Printing would still be an issue.
So yeah, I personally don't think that should block shipping MathML but there are remaining issues with legacy layout that we need to be aware of.
-- Frédéric Wang
Daniel Bratell
I'm really happy to see this coming along! Awesome work by
everyone involved!
I do agree that a feature of this size doesn't need to have all quirks ironed out before initial shipping. I expect some people to miss printing so I hope the gap where it doesn't work won't be too big.
You mentioned fuzzy testing. Do the fuzzing tools have support for mathml elements? If not, you should probably add a to-do item to teach them.
What is the situation for developers that learn about this and want to start using it? Are there good resources for learning how to write MathML? I think a feature like this also deserves some attention when it lands. Maybe that will happen by itself, or maybe someone needs to initiate it. That info should probably also mention initial limitations like printing, (multi-column?) and non-Core.
More about compatibility: Do you have any idea (guess really) of how much of existing MathML content will "work" with just MathML Core? Is it 99%, 90%, 50%, 10%?
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/354fba5f-de49-7e9a-dc91-440108e17908%40igalia.com.
Frédéric Wang
>
> I'm really happy to see this coming along! Awesome work by everyone
> involved!
>
> You mentioned fuzzy testing. Do the fuzzing tools have support for
> mathml elements? If not, you should probably add a to-do item to teach
> them.
>
fuzzers have some kind of support already. My understanding is that
fuzzing tools can either generate data or "shuffle" from existing input.
For the latter, we have now a bunch of WPT tests with MathML to feed the
fuzzers and I believe these are particularly interesting to cover edge
cases with CSS, JS, etc. For the former, I thought that was the case for
https://github.com/MozillaSecurity/ or https://github.com/renatahodovan/
but can't find any up-to-date repo for MathML currently, so I agree we
need to work on that.
> What is the situation for developers that learn about this and want to
> start using it? Are there good resources for learning how to write
> MathML? I think a feature like this also deserves some attention when
> it lands. Maybe that will happen by itself, or maybe someone needs to
> initiate it. That info should probably also mention initial
> limitations like printing, (multi-column?) and non-Core.
>
of resource available about MathML (e.g. MDN to mention the obvious one)
as wellas editors & converters to generate it, polyfills to cover
browser's limitations, etc but I agree they will probably need a refresh
since (1) we implement a core subset (2) we are moving to an extensible
approach based on web technologies (3) there are chrome-specific bugs
like the printing one.
> More about compatibility: Do you have any idea (guess really) of how
> much of existing MathML content will "work" with just MathML Core? Is
> it 99%, 90%, 50%, 10%?
>
it's between 90-99% of existing MathML content delivered to
Firefox/WebKit (note: they implement more than MathML Core but still not
the full MathML3 spec either). But if you want something more concrete,
regarding features we unshipped from Firefox I have a conversation on
Mozilla's matrix channel where we measured counters for deprecated
MathML3 features between 2020-08-11 and 2020-09-17. Most of them were
returning 0 count and only two of them were returning 1 count... to
compare with the counter for pages using MathML which was several millions!
--
Frédéric Wang
Brian Kardell
> More about compatibility: Do you have any idea (guess really) of how
> much of existing MathML content will "work" with just MathML Core? Is
> it 99%, 90%, 50%, 10%?
However, it is a somewhat tricky question because, what does it mean to "work" can vary (or maybe better, how does it 'fail'). So, for example, L1 does not include "math links". This turns out to be kind of trickily nested in a whole bunch of related questions that would take some real additional time to answer. Without answering them, you can still put a regular link inside a token element. Given that, if. you load up some older MathML that includes links on the token elements, it will render the math, but not the link. The working group decided that this was the right tradeoff, because for many things, that's the most important part and it wasn't getting done at all - so this is a dramatic improvement already. It fails better. However, with L1 we now also have the tools to include, with very little additional author effort just a little bit of transform or js handlers to make 'work' like a link too (for purposes they care about) until we can move beyond that.
So, basically: It's hard to say with authority but the working group itself has been both very cautious and pragmatic here. They definitely understand that even complete interoperability of L1 can't just make all MathML ever written work. They focused on making "the vast majority of stuff great" and making sure things outside that had a decent story too - be that it "failing" in a better way natively or just having a very simple remediation story, etc.
Mike West
slightlyoff via Chromestatus
Daniel Bratell
We discussed that option in the API Owner meeting and did not really like it. If there are no better alternatives, maybe it would be good enough but the typical people to encounter printing problems would probably not discover it.
I hope it's possible to find something more obvious so we don't
have to go that route. Missing printing and the effects that may
have on users was the only real blocking issue we identified.
/Daniel
Excited to see this moving forward. Happy to see this ship with printing caveats from Mike. For my part, even a console log message would suffice.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/000000000000af1d8605e2a719d2%40google.com.
Frédéric Wang
Just to follow-up on two points raised by Daniel:
On 25/06/2022 14:09, Frédéric Wang wrote:
>> You mentioned fuzzy testing. Do the fuzzing tools have support for
>> mathml elements? If not, you should probably add a to-do item to
>> teach them.
>>
> MathML has been there for several years so I do expect (naively?) that
> fuzzers have some kind of support already. My understanding is that
> fuzzing tools can either generate data or "shuffle" from existing
> input. For the latter, we have now a bunch of WPT tests with MathML to
> feed the fuzzers and I believe these are particularly interesting to
> cover edge cases with CSS, JS, etc. For the former, I thought that was
> the case for https://github.com/MozillaSecurity/ or
> https://github.com/renatahodovan/ but can't find any up-to-date repo
> for MathML currently, so I agree we need to work on that.
to make sure their tools handle MathML and are aware of MathML Core.
We've also spent some time focusing more precisely on Chromium-related
fuzzing, basically increasing code coverage of "in-process guided
fuzzing" for low-level font modules and teaching MathML Core grammar to
DOM fuzzers. For details please read
https://bugs.chromium.org/p/chromium/issues/detail?id=1340884
>>
>> What is the situation for developers that learn about this and want
>> to start using it? Are there good resources for learning how to write
>> MathML? I think a feature like this also deserves some attention when
>> it lands. Maybe that will happen by itself, or maybe someone needs to
>> initiate it. That info should probably also mention initial
>> limitations like printing, (multi-column?) and non-Core.
>>
> Similarly, MathML has been there for a while so there is already a
> bunch of resource available about MathML (e.g. MDN to mention the
> obvious one) as wellas editors & converters to generate it, polyfills
> to cover browser's limitations, etc but I agree they will probably
> need a refresh since (1) we implement a core subset (2) we are moving
> to an extensible approach based on web technologies (3) there are
> chrome-specific bugs like the printing one.
https://github.com/mdn/content/pull/17735
https://github.com/mdn/content/pull/17812
Of course, we can probably get help from the MathML community to update it.
--
Frédéric Wang
Benjamin Aster
Neil Soiffer
I don't mean to diminish the importance of print -- I'm old enough that I occasionally print things out. However, the situation now is that neither display nor print of MathML works natively in Chromium. In turning on MathML display, 99.99% (or more?) people will be happy to have fast display of math; some small number of people won’t be happy when they try to print it out.
For that group and the publishers that put out material that
tests whether MathML is available in the browser, this would be a regression. It
would be interesting to know if any sites sniff for MathML support, or whether
they simply look at the browser and decide based on their knowledge of support.
I know of at least one site that does the latter and so they wouldn’t suffer a
regression. Maybe all the sites do this because it is easy and reliable? Even if there is no regression, please don't put printing math on the back burner in terms of priorities.
Benjamin mentioned Wikipedia. I can’t speak for what Wikipedia would do, but as long as they know that printing is broken in Chromium, any decision to turn on direct MathML rendering is their call, not Chromium’s. I suspect given their concern that Wikipedia renders properly almost everywhere, it will be a long time before they make a switch. Right now, despite Firefox’s long support for MathML, they still use SVG with hidden MathML on it.
On the supposition that there are some sites that sniff for MathML, I think Benjamin’s suggestions are good. I don’t know how feasible it is to put up a dialog stating that printing math is not currently supported in Chromium, but doing that with some suggested workarounds would I think be a viable alternative until print is supported. One workaround would be to suggest they download an extension (that would need to be written) that loads MathJax into the page in question when clicked. Another suggestion could be to read the page with Firefox ;-). I’m sure there are many more clever people on this list than I am who might have other suggestions for workarounds.
My suggestion is to follow the somewhat worn out but still very true trope: "don't let perfect be the enemy of the good". People have been waiting years and years to get math to display natively in Chromium and now it is ready to happen. Please try to find a simple stopgap and get this long awaited feature turned on.
Daniel Herr
<link href="print.css" rel="stylesheet" media="print">
Chris Harrelson
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cc2a4fab-823d-467f-949e-385a150fa5fen%40chromium.org.
Yoav Weiss
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Mike Taylor
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/260d7448-c8cf-4503-99bb-8918bda112bbn%40chromium.org.
Frédéric Wang
LGTM3
On 9/14/22 8:37 AM, Yoav Weiss wrote:
LGTM2 with the above plan, assuming printing sticks.
On Wednesday, September 14, 2022 at 5:36:11 PM UTC+2 Chris Harrelson wrote:
Printing NG looks like it will ship in M108.
LGTM1 to ship MathML in M109 (just in case there is an issue that causes printing to be reverted).
Hi,
Some quick update on this...
LayoutNGPrinting has been enabled in [1]. I'm attaching PDF of [2] as printed by a recent Chromium trunk build (with LayoutNGPrinting enabled/disabled).
If I understand correctly [3], it is integrated in M108 (branched yesterday) and the feature freeze for M109 will be October 27. So we have two weeks to decide to enable MathML or not (if an issue with LayoutNGPrinting is detected) [4].
[1] https://chromium-review.googlesource.com/c/chromium/src/+/3925546
[2] https://fred-wang.github.io/MathFonts/mozilla_mathml_test/
[3] https://chromiumdash.appspot.com/schedule
[4] https://bugs.chromium.org/p/chromium/issues/detail?id=1321001
Frédéric Wang
Manuel Rego Casasnovas
On 14/10/2022 07:53, Frédéric Wang wrote:
> If I understand correctly [3], it is integrated in M108 (branched
> yesterday) and the feature freeze for M109 will be October 27. So we
> have two weeks to decide to enable MathML or not (if an issue with
> LayoutNGPrinting is detected) [4].
things like UI features and browser features. But not related to Blink
features, they sometimes get shipped just before the branch point, and
after the feature freeze date.
So we have some extra time to check if LayoutNGPrinting gets some
trouble or not. And if it sticks we could enable MathML too (maybe
adding a base feature [*] in case it needs to be disabled later).
Cheers,
Rego
[*]
https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/renderer/platform/RuntimeEnabledFeatures.md#generate-a-instance-from-a-blink-feature
Frédéric Wang
On 14/10/2022 07:53, Frédéric Wang wrote:If I understand correctly [3], it is integrated in M108 (branched yesterday) and the feature freeze for M109 will be October 27. So we have two weeks to decide to enable MathML or not (if an issue with LayoutNGPrinting is detected) [4].I believe "feature freeze" on that page is related to Chromium itself, things like UI features and browser features. But not related to Blink features, they sometimes get shipped just before the branch point, and after the feature freeze date.
Requires code in //chrome?
True (this is only to implement support for “font-family: math”, which has a user preference menu for math font, see https://docs.google.com/document/d/1bvY_Npe2zLW_705KXdmecsH6P9I9wBMpHRsZ9CxWNOI/edit#heading=h.u9hwm9tp8nuy).
So we have some extra time to check if LayoutNGPrinting gets some trouble or not. And if it sticks we could enable MathML too (maybe adding a base feature [*] in case it needs to be disabled later).
-- Frédéric Wang