Implementing MathML stylistic attributes in WebKit
Hello, Currently MathML attributes mathvariant, displaystyle and scriptlevel [1] [2] are implemented in WebKit using custom "style resolution" and "one-glyph rendering" inside the MathML layout code [3] [4] [5]. These features involve text rendering and interaction with CSS font-size, so it is difficult to implement them properly and completely that way. There are known bugs and missing features right now (e.g. mathvariant transform only applies to one-character strings, automatic displaystyle/scriptlevel does not work with fractions, etc) Several years ago, Gecko used to do something similar but that was causing a lot of problems (dynamic update, assertion failures...). At the end, this is now implemented in Gecko more reliably by mapping the attributes to internal CSS properties ; [6] is based on that. When I tried to do something like this in WebKit three years ago, I was only able to rely on proprietary -webkit-* extensions exposed to users [7]. So my questions are: (1) What is WebKit's mechanism to implement such stylistic attributes? (2) Is it possible to implement internal (i.e. not web-exposed to users) CSS properties/values in WebKit? (3) Is it ok to add more -webkit-* properties/values or should these properties be standardized at the CSS WG instead? I understand answers to these general questions from other browser project is either use internal properties or standardize them. Thanks, Frédéric PS: For a concrete example, see [8]. Automatic mathvariant is used for italic variables while font-size in fractions is calculated according to displaystyle / scriptlevel rules. The latter is incorrect (check the attached screenshot) while selection highlight is broken for the former. [1] https://mathml-refresh.github.io/mathml-core/#the-mathvariant-attribute [2] https://mathml-refresh.github.io/mathml-core/#the-displaystyle-and-scriptlev... [3] https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/css/mathml.css [4] https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/rendering/mathml... [5] https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/rendering/mathml... [6] https://mathml-refresh.github.io/mathml-core/#css-extensions-for-math-layout [7] https://bugs.webkit.org/show_bug.cgi?id=133845#c5 [8] https://bug-201242-attachments.webkit.org/attachment.cgi?id=377730 -- Frédéric Wang
On Mon, Sep 2, 2019 at 7:11 AM Frédéric Wang <fwang@igalia.com> wrote:
Currently MathML attributes mathvariant, displaystyle and scriptlevel [1] [2] are implemented in WebKit using custom "style resolution" and "one-glyph rendering" inside the MathML layout code [3] [4] [5]. These features involve text rendering and interaction with CSS font-size, so it is difficult to implement them properly and completely that way. There are known bugs and missing features right now (e.g. mathvariant transform only applies to one-character strings, automatic displaystyle/scriptlevel does not work with fractions, etc)
Several years ago, Gecko used to do something similar but that was causing a lot of problems (dynamic update, assertion failures...). At the end, this is now implemented in Gecko more reliably by mapping the attributes to internal CSS properties ; [6] is based on that. When I tried to do something like this in WebKit three years ago, I was only able to rely on proprietary -webkit-* extensions exposed to users [7].
So my questions are:
(1) What is WebKit's mechanism to implement such stylistic attributes?
It looks like -internal-text-autosizing-status is such a property. This is a property the author can never set and we set it internally for implementation purposes. ComputedStyleExtractor::valueForPropertyInStyle manually skips it so it's never exposed anywhere. One subtle thing I didn't check is whether it would affect the CSS parser or not (as in whether it would be considered as a valid CSS property or not). There might be some subtle effect there. -webkit-text-decorations-in-effect is also a CSS property we use internally to compute the effective set of text decorations applied to text for editing purposes. The author can never set it but it's unfortunately exposed via computed style. (2) Is it possible to implement internal (i.e. not web-exposed to users)
CSS properties/values in WebKit?
It appears possible today using the technique deployed by CSSPropertyInternalTextAutosizingStatus.
(3) Is it ok to add more -webkit-* properties/values or should these properties be standardized at the CSS WG instead?
N/A - R. Niwa
On 02/09/2019 22:12, Ryosuke Niwa wrote:
On Mon, Sep 2, 2019 at 7:11 AM Frédéric Wang <fwang@igalia.com <mailto:fwang@igalia.com>> wrote:
Currently MathML attributes mathvariant, displaystyle and scriptlevel [1] [2] are implemented in WebKit using custom "style resolution" and "one-glyph rendering" inside the MathML layout code [3] [4] [5]. These features involve text rendering and interaction with CSS font-size, so it is difficult to implement them properly and completely that way. There are known bugs and missing features right now (e.g. mathvariant transform only applies to one-character strings, automatic displaystyle/scriptlevel does not work with fractions, etc)
Several years ago, Gecko used to do something similar but that was causing a lot of problems (dynamic update, assertion failures...). At the end, this is now implemented in Gecko more reliably by mapping the attributes to internal CSS properties ; [6] is based on that. When I tried to do something like this in WebKit three years ago, I was only able to rely on proprietary -webkit-* extensions exposed to users [7].
So my questions are:
(1) What is WebKit's mechanism to implement such stylistic attributes?
It looks like -internal-text-autosizing-status is such a property. This is a property the author can never set and we set it internally for implementation purposes. ComputedStyleExtractor::valueForPropertyInStyle manually skips it so it's never exposed anywhere.
One subtle thing I didn't check is whether it would affect the CSS parser or not (as in whether it would be considered as a valid CSS property or not). There might be some subtle effect there.
-webkit-text-decorations-in-effect is also a CSS property we use internally to compute the effective set of text decorations applied to text for editing purposes. The author can never set it but it's unfortunately exposed via computed style.
(2) Is it possible to implement internal (i.e. not web-exposed to users) CSS properties/values in WebKit?
It appears possible today using the technique deployed by CSSPropertyInternalTextAutosizingStatus.
Thanks for the pointers! I think it is worth trying to (re-)implement these MathML attributes using internal properties. -- Frédéric Wang
On 02/09/2019 16:11, Frédéric Wang wrote:
Hello,
Currently MathML attributes mathvariant, displaystyle and scriptlevel [1] [2] are implemented in WebKit using custom "style resolution" and "one-glyph rendering" inside the MathML layout code [3] [4] [5]. These features involve text rendering and interaction with CSS font-size, so it is difficult to implement them properly and completely that way. There are known bugs and missing features right now (e.g. mathvariant transform only applies to one-character strings, automatic displaystyle/scriptlevel does not work with fractions, etc)
Hi, An update on this, we have been discussing these and new properties with the CSSWG: https://github.com/w3c/csswg-drafts/issues/5384 The math-depth / math-style CSS properties are being implemented in Chromium and renamed/exposed/tweaked in Gecko: https://mathml-refresh.github.io/mathml-core/#the-math-style-property https://mathml-refresh.github.io/mathml-core/#the-math-script-level-property So it makes sense to implement them in WebKit (it seems we still don't have a "intent to" mechanism, but people can follow https://bugs.webkit.org/show_bug.cgi?id=195797). The CSSWG is fine with a new text-transform value for automatic italic but using it for other values is controversial (see https://github.com/w3c/csswg-drafts/issues/3775). So if we want to preserve backward compatibility and fix existing bugs with mathvariant, we should probably re-implement it using an internal math-transform property (like what Gecko does) which according to our previous discussion is nowadays possible in WebKit. -- Frédéric Wang
On Fri, Sep 25, 2020 at 12:47 AM Frédéric Wang <fwang@igalia.com> wrote:
On 02/09/2019 16:11, Frédéric Wang wrote:
Hello,
Currently MathML attributes mathvariant, displaystyle and scriptlevel [1] [2] are implemented in WebKit using custom "style resolution" and "one-glyph rendering" inside the MathML layout code [3] [4] [5]. These features involve text rendering and interaction with CSS font-size, so it is difficult to implement them properly and completely that way. There are known bugs and missing features right now (e.g. mathvariant transform only applies to one-character strings, automatic displaystyle/scriptlevel does not work with fractions, etc)
Hi,
An update on this, we have been discussing these and new properties with the CSSWG:
https://github.com/w3c/csswg-drafts/issues/5384
The math-depth / math-style CSS properties are being implemented in Chromium and renamed/exposed/tweaked in Gecko:
https://mathml-refresh.github.io/mathml-core/#the-math-style-property
https://mathml-refresh.github.io/mathml-core/#the-math-script-level-property
So it makes sense to implement them in WebKit (it seems we still don't have a "intent to" mechanism, but people can follow https://bugs.webkit.org/show_bug.cgi?id=195797).
The CSSWG is fine with a new text-transform value for automatic italic but using it for other values is controversial (see https://github.com/w3c/csswg-drafts/issues/3775). So if we want to preserve backward compatibility and fix existing bugs with mathvariant, we should probably re-implement it using an internal math-transform property (like what Gecko does) which according to our previous discussion is nowadays possible in WebKit.
Adding the support for new properties sounds good! My concern here is really only about backwards compatibility. - R. Niwa
participants (2)
-
Frédéric Wang
-
Ryosuke Niwa