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".
- 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.
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.
- 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).
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
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No.
- 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
DevTrial on desktop | 103 |
DevTrial on Android | 103 |
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/5866-- 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:
At that time, we believe the implementation is good enough for a first release. To be fully transparent these are known issues:
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
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.
Resending since it seems the email failed to be delivered...
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
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."
--
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
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.
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.
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.
--
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.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
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.
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
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