Implementing MathML stylistic attributes in WebKit

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

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] mathml-refresh.github.io/mathml-core/#the-mathvariant-attribute [2] mathml-refresh.github.io/mathml-core/#the-displaystyle-and-scriptlevel-attributes [3] trac.webkit.org/browser/webkit/trunk/Source/WebCore/css/mathml.css [4] trac.webkit.org/browser/webkit/trunk/Source/WebCore/rendering/mathml/MathMLStyle.cpp [5] trac.webkit.org/browser/webkit/trunk/Source/WebCore/rendering/mathml/RenderMathMLToken.cpp#L593 [6] mathml-refresh.github.io/mathml-core/#css-extensions-for-math-layout [7] bugs.webkit.org/show_bug.cgi?id=133845#c5 [8] bug-201242-attachments.webkit.org/attachment.cgi?id=377730

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

On Mon, Sep 2, 2019 at 7:11 AM Frédéric Wang <fwang at 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
# Frédéric Wang (a day ago)

On 02/09/2019 22:12, Ryosuke Niwa wrote: >

On Mon, Sep 2, 2019 at 7:11 AM Frédéric Wang <fwang at igalia.com

<mailto:fwang at 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.

Want more features?

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