W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2020

Re: [csswg-drafts] [css-text] text-transform's design, intent and reality resolution (#3775)

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Thu, 02 Jul 2020 01:54:58 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-652733256-1593654897-sysbot+gh@w3.org>
My understanding is that the question here was in essence:

"Can we agree that it is a fundamental part of the design of text-transform that it must in all cases be reflected everywhere including in the screen-reader rendering, and therefore that we can base decisions about future values on that fact?"

I believe the answer is no.

It is true that there are values of text-transform that affect the rendering in screen readers, and that's intentional on their part. For example changes of case.

* There are also values of text-transform that do not affect the rendering in screen readers, and that distinction is critical to their purpose. For example full-width or full-size-kana.

* In all of these cases, screen readers should also be allowed, if they so desire, to present the alternate view to their users (maybe on demand, maybe based on a setting… this is a UX problem, and is out of scope for the spec).

* There are cases where CSS doesn't load, so counting on it to change semantics is unreliable anyway.

The design principle, to me, is that text-transform does not alter the meaning of the styled text. User agents such as screen readers that provide a non-visual rendering may take that styling into account when deciding how to present the text, but it is not a thing that should be relied on as a design principle of this feature. (Whether users of a particular implementation can rely on that implementation doing is separate, and not particularly relevant here.)

The way to apply that principle to the proposed math related text-tranform would be:
- adding these transforms is OK.
- using these transforms to explain how various pieces of mathML markup (such as the mathvariant attribute) cause endering changes is OK.
- relying on these transforms to alter the meaning of the document, and to semantically distinguish between 'a' and '<span style=text-tranform:math-fraktur>a</span> is not robust.
- Markup is what needs to alter the semantics. The [spec of mathvariant attribute](https://www.w3.org/TR/MathML3/chapter3.html#presm.mstyle) is already fairly clear about that, but it could be further clarified that it is expected to affect all renderings, including the accessibility tree and other non visual renderings.

GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3775#issuecomment-652733256 using your GitHub account
Received on Thursday, 2 July 2020 01:55:00 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:11 UTC