- From: Frédéric Wang via GitHub <sysbot+gh@w3.org>
- Date: Wed, 27 Mar 2019 09:57:37 +0000
- To: public-css-archive@w3.org
Thank you everybody for the feedback.
First let me do a small digression as I'd like to clarify the somewhat separate MathML thing, which is the main motivation for this proposal:
1) Both mathvariant or using the transformed character will be preserved on MathML formulas (and their containing document). So it's still correct to use the mathvariant attribute, even if one could just using the transformed character.
2) In practice there are still a lot of existing tools/content using the mathvariant attribute so we are not going to just get rid of it, we need a native implementation. This is used by e.g. all MathJax or Wikipedia pages or those generated by the bottom-to-top itex2MML converter (which has been there for 20 years).
3) Existing math fonts (including Cambria Math pre-installed on Windows or the popular STIX fonts) don't provide glyph-level selection for these mathvariant transforms. Instead it is expected that math rendering engines (modern LaTeX, browsers...) will just know how to perform the transform to the Math Alphanumeric Symbols. Again, we cannot just expect the fonts to be modified and updated so we need to do something at the browser level.
4) Experience for native MathML implementations showed that appropriate way to implement mstyle attributes is to rely on CSS properties rather than duplicating the mechanism somewhere (that's how it used to be done in Firefox and caused some issues). In the case of mathvariant, the feature is very similar to text-transform so the most natural thing is to rely on it. Some Apple reviewer commented that WebKit does not allow "internal" CSS properties so we have a hacky/partial implementation until we can standardize a CSS property for mathvariant.
5) Experience in browsers/assistive technologies by @joanmarie to make mathvariant accessible showed that if text-transform does not expose the transformed text we would need to perform the mathvariant transform somewhere else. This is basically the general problem @jcsteh described.
Now coming back to the CSS issue, I thought extending text-transform for these existing math characters is sensible and would be easy to implement and test (do everybody agree with that?). Igalia offers to implement it and we already have some similar tests for mathvariant, and it is important for native MathML implementations as I previously explained. In addition, it could be useful for people implementing "math polyfill" e.g. using some CSS stylesheet with `mstyle[mathvariant="double-struck"] { text-transform: math-double-struck; }` is much more efficient and lightweight than a script that goes over all the DOM and modifies the text nodes to transform characters. Of course, nobody uses text-transform for such use case yet, so it shouldn't be a concern for now, contrary to the MathML use case.
Regarding the a11y issue, I believe a11y and CSS people should first agree on whether to expose the text-transform text as what the CSS spec says and the actual a11y implementations seem to differ. I don't see any consensus on this thread or https://groups.google.com/a/chromium.org/forum/#!msg/chromium-accessibility/enk1PBjEfRc/InWurOYUg0EJ. Probably this can be discussed in a separate GitHub issue and we can still add these math text-transforms in the meantime. Depending on the outcome, we would either have nothing to do to make mathvariant accessible (my personal preference) or keep doing the extra effort that we experimented in (5).
--
GitHub Notification of comment by fred-wang
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3745#issuecomment-477071245 using your GitHub account
Received on Wednesday, 27 March 2019 09:57:39 UTC