W3C home > Mailing lists > Public > public-css-archive@w3.org > March 2019

Re: [csswg-drafts] [css-text] Add new CSS text-transform values for math (#3745)

From: fantasai via GitHub <sysbot+gh@w3.org>
Date: Tue, 26 Mar 2019 19:53:42 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-476821281-1553630021-sysbot+gh@w3.org>
Wrt accessibility, agreed 100% with @frivoal's comment in https://github.com/w3c/csswg-drafts/issues/3745#issuecomment-476474263 The entire point of 'text-transform' is to alter visual styling without changing the underlying content as it is read aloud or presented in alternative ways (e.g. alternate styling, reader mode, etc.). If AT is exposing these transformations when reading text aloud, this means we have no way to make these visual transformations without distorting the text for AT. I think @frivoal's examples of ::first-line capitalization and full-size-kana show why dissociating the visual and AT texts is necessary and useful.

Currently `text-transform` is defined to affect *rendering only*. https://www.w3.org/TR/css-text-3/#text-transform-property It does not change the underlying document semantics. It does not affect plaintext copy/paste (and imo should not affect speech rendering). Using `text-transform`, like using `order`, is about _intentionally_ creating a _discrepency_ between the underlying text and the visual rendering, because the ideal visual rendering, if reflected in the document content, would inappropriately distort that content.

Which brings us back to the original point: should we add these values to better support MathML. I'm not entirely clear on the problem we're trying to solve here and why this would be the right approach. If math wants to shift visual styling to better reflect semantics already in the document, that would be inherent even if CSS is turned off, then that's one thing. But if this request is because it is more convenient to do the transformation in CSS than in a preprocessor even though it should be done in a preprocessor, then I don't think that's a good justification for adding it to CSS. (If the concern is just about fallbacks between glyphs assigned to these math Unicode codepoints vs font variations, we can talk about how to solve that at the glyph selection level.) Are there fundamental use cases other than supporting the mathvariant attribute that we need to solve?

GitHub Notification of comment by fantasai
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3745#issuecomment-476821281 using your GitHub account
Received on Tuesday, 26 March 2019 19:53:44 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:45 UTC