[css-text] Add new CSS text-transform values for math

[fred-wang]

cc @mrego @emilio @rwlbuis @bfgeek

The proposal is to introduce new values for the text-transform properties in order to map alphanumeric text to equivalent Mathematical Alphanumeric Symbols. For details, see the explainer from the MathML Refresh CG repository.

Tentative tests:
web-platform-tests/wpt#16922
All the tests pass in Igalia's chromium-mathml build.

Draft:
https://mathml-refresh.github.io/mathml-core/#new-text-transform-values

[bkardell]

After discussing this with @fred-wang and @mrego, I think that we agree that we probably want the values list to be just

none | [capitalize | uppercase | lowercase ] || full-width || full-size-kana | math-auto | math-bold | math-italic | math-bold-italic | math-double-struck | math-bold-fraktur | math-script | math-bold-script | math-fraktur | math-sans-serif | math-bold-sans-serif | math-sans-serif-italic | math-sans-serif-bold-italic | math-monospace | math-initial | math-tailed | math-looped | math-stretched

That's more in keeping with what is there today, it's one less character to type, and it doesn't get us into a whole host of other questions about why is it a function, what does the function produce and so on. Ultimately this is really just a name that identifies the transform, I think, and unless we want to start tackling the thing at the end of section 2

Note: A future level of CSS may introduce the ability to create custom mapping tables for less common text transforms, such as by an @text-transform rule similar to @counter-style from

And try explaining these in terms of those then I don't think there is a need for more. But, I also don't think that's necessary or maybe even desirable because of what/where this sits?

[AmeliaBR]

I think this is a good idea. In addition to their use in math typesetting, these characters have gained some notoriety as faux-fonts & it would be nice to have a way to use them without destroying the meaning of the text content.

(It wouldn't get rid of the underlying reason they became popular: social media that supports full Unicode but not rich text formatting. But, it would mean that a conscientious web developer working an a CSS environment could recreate that visual effect in an accessible way.)

I agree with Brian about using keywords instead of a function notation, since the math() function in the proposal seems to be merely a namespacing technique, and doesn't imply an operation

Some other thoughts:

1. Can the auto value be handled by user agent stylesheets? We don't really have a pseudoclass for "has no element children", but that seems to be all you want: math|mi:no-children { text-transform: math-italic }

2. If we're considering the general/decorative use case, and not just math typesetting, there are a few other conversions that I'd include:

   • circled for ASCII letters and digits (ⒶⒷⒸⓐⓑⓒ①②③) and maybe some punctuation (⊜⊛) and Hangul, katakana, and CJK ideographs (I don't know enough about what the circled CJK characters mean/how they are used to know if it makes sense as a stylistic transform)

   • circled-black or circled-negative for digits and capital ASCII letters (🅐🅑🅒❶❷❸)

   • squared (🄰🄱🄲) and squared-black or squared-negative (🅰🅱🅲) for capital ASCII letters (Note: would have to deal with browsers that upgrade some of the negative squared letters to "blood type marker emoji")

   Both the circled and squared transformations could be made more general if we accept that a text-transform can consist of adding a combining character after each character in the sequence.

3. Should there be any Unicode normalization happening before the transformation? E.g., to decompose é into e +´ so that the letter can be transformed to a math formatting character and then the accent combined with the replacement?

4. Based on the grammar, text-transform: capitalize math-fraktur would be allowed. It should probably be clear what the order of operations is, because there are a few case conversions that switch letters in/out of the ASCII range and therefore affect whether there are formatting conversions available.

5. I think the grammar Brian posted should be modified to include square brackets around full-width || full-size-kana, otherwise it also allows text-transform: full-width math-fraktur. I don't think full-width variants of the math characters exist, at least not as dedicated Unicode points.

[frivoal]

unless we want to start tackling the thing at the end of section 2

Note: A future level of CSS may introduce the ability to create custom mapping tables for less common text transforms, such as by an @text-transform rule similar to @counter-style from

I did have a go at it a while back. If someone wants to revive / refine / debug this, let me know: https://specs.rivoal.net/css-custom-tt/

[fred-wang]

I think this is a good idea. In addition to their use in math typesetting, these characters have gained some notoriety as faux-fonts & it would be nice to have a way to use them without destroying the meaning of the text content.

(It wouldn't get rid of the underlying reason they became popular: social media that supports full Unicode but not rich text formatting. But, it would mean that a conscientious web developer working an a CSS environment could recreate that visual effect in an accessible way.)

Thanks for the feedback!

About keeping the meaning of the text content, from the math point of view, a A with fraktur style should have the same meaning as the transformed character MATHEMATICAL FRAKTUR CAPITAL A' (U+1D504). Or at least a11y tools should find some way to indicate that it is a fraktur A and not a normal A. Not sure if that's the case currently for text-transform, see for example https://groups.google.com/a/chromium.org/forum/#!msg/chromium-accessibility/enk1PBjEfRc/InWurOYUg0EJ

I agree with Brian about using keywords instead of a function notation, since the math() function in the proposal seems to be merely a namespacing technique, and doesn't imply an operation

Yes, sorry that was a misunderstanding on my side. I thought the CSS WG had requested to change my initial proposal to use math( ) but that was just some random idea from @rego. I'm happy with any solution that makes implementation easy.

1. Can the `auto` value be handled by user agent stylesheets? We don't really have a pseudoclass for "has no element children", but that seems to be all you want: `math|mi:no-children { text-transform: math-italic }`

AFAIK not with current CSS capability. It's not "mi with no children" but "mi with a unique text node which itself has a single character" (e.g. <mi>x</mi> is italic but <mi>sin</mi> is not). Gecko handles that outside the CSS engine (which does not know about the DOM) by adding some special flag on the text node.

3. Should there be any Unicode normalization happening before the transformation? E.g., to decompose é into e +´ so that the letter can be transformed to a math formatting character and then the accent combined with the replacement?

I personally don't know math use cases for that. At least for MathML, accents (https://en.wikibooks.org/wiki/LaTeX/Special_Characters#Math_mode) are generally placed in a separate <mo> elements.

4. Based on the grammar, `text-transform: capitalize math-fraktur` would be allowed. It should probably be clear what the order of operations is, because there are a few case conversions that switch letters in/out of the ASCII range and therefore affect whether there are formatting conversions available.

5. I think the grammar Brian posted should be modified to include square brackets around `full-width || full-size-kana`, otherwise it also allows `text-transform: full-width math-fraktur`. I don't think full-width variants of the math characters exist, at least not as dedicated Unicode points.

I think Brian's grammar does not allow mixing math-* values with others (if I understand correctly https://drafts.csswg.org/css-values-4/#component-combinators). That was the initial intention since I'm not sure there is a clear use case for that (again from the math point of view).

However, I agree that mixing math-* values with capitalize, uppercase or lowercase has obvious interpretation and could be acceptable, at least for latin letters. If so, I believe the grammar should be something like

none | [capitalize | uppercase | lowercase ] || full-width || full-size-kana | [capitalize | uppercase | lowercase ] || [ math-auto | math-bold | math-italic | math-bold-italic | math-double-struck | math-bold-fraktur | math-script | math-bold-script | math-fraktur | math-sans-serif | math-bold-sans-serif | math-sans-serif-italic | math-sans-serif-bold-italic | math-monospace | math-initial | math-tailed | math-looped | math-stretched ]

But maybe we just want to allow to mix everything and ignore transforms that don't make sense, so that the grammar is just

none | [capitalize | uppercase | lowercase ] || full-width || full-size-kana || [ math-auto | math-bold | math-italic | math-bold-italic | math-double-struck | math-bold-fraktur | math-script | math-bold-script | math-fraktur | math-sans-serif | math-bold-sans-serif | math-sans-serif-italic | math-sans-serif-bold-italic | math-monospace | math-initial | math-tailed | math-looped | math-stretched ]

[AmeliaBR]

About keeping the meaning of the text content, from the math point of view, a A with fraktur style should have the same meaning as the transformed character MATHEMATICAL FRAKTUR CAPITAL A' (U+1D504). Or at least a11y tools should find some way to indicate that it is a fraktur A and not a normal A.

That's a good point, and is different from how we want assistive text to expose text-transform changes to case. It doesn't mean it isn't do-able, it just means that the accessible version of the transformed text needs to be clearly defined. You'd want to get input from people who work on tools that expose math to screen readers and Braille display and so on, to find out how they implement it.

[joanmarie]

That's a good point, and is different from how we want assistive text to expose text-transform changes to case. It doesn't mean it isn't do-able, it just means that the accessible version of the transformed text needs to be clearly defined. You'd want to get input from people who work on tools that expose math to screen readers and Braille display and so on, to find out how they implement it.

As a screen-reader developer, my preference is that the transformed/rendered text is what gets exposed via the platform accessibility APIs. For instance if the DOM text is "foo", but that gets CSS transformed into rendered text of "FOO", atk_text_get_text(0, -1) (and all other AtkText text-retrieval methods) should return "FOO"; not "foo".

Screen readers, as a general rule, want to present the content sighted users see. Exactly how it got rendered is, more often than not, irrelevant.* Furthermore, it's a drag for an AT to have to take every single bit of accessible text, retrieve some additional property "just in case", and occasionally do additional work to transform it. The render tree already contains the final/displayed version, so please share that with me. 😄

*But if any ATs might have a need, exposing the transform property as an attribute on the accessible object shouldn't hurt anything and should be relatively easy to implement within the user agent.

[frivoal]

@joanmarie, I am genuiely curious, can you explain a bit more about why you'd want the transform to be preserved in general? How do screen readers read words in all uppercase? For instance, if text-transform:uppercase is applied to a first line, how does that get read out?

[joanmarie]

@joanmarie, I am genuiely curious, can you explain a bit more about why you'd want the transform to be preserved in general?

Because one of the primary functions of a screen reader is to present (in speech and in braille) what is on the screen. If sighted users see capital letters and blind users see lower-case letters, the latter group is missing out on information. And at least some of them -- if not many of them -- would report it as a bug in the screen reader.

How do screen readers read words in all uppercase? For instance, if text-transform:uppercase is applied to a first line, how does that get read out?

That depends on two things: 1) The screen reader and 2) User preference. For instance some screen readers have options like:

• Use higher pitch
• Play a tone
• Say "cap"

The user can then pick which option(s) work best, and often configure the options on a per-app basis.

For the braille display, the indication would be based on the braille code being used. For instance, in the U.S. each capitalized word would be preceded by two dot-6 cells.

[AmeliaBR]

Thanks for the insights, @joanmarie. This is very different from the "common sense" (but I guess outdated) advice I'd been given — that one should always use text-transform: uppercase instead of using all caps in the text content because all caps text content is often read out as initials instead of words.

For the math use case, it does greatly simplify things if the proper accessibility practice is to expose the formatted text.

It doesn't help the accessibility issues of decorative-characters, though, but I think that's beside the point, since this is already an accessibility issue without text-transform. Misuse of math characters has become so common on social media that screen readers probably need to add smart heuristics so they can read out 𝕸𝖆𝖙𝖍 in a way similar to how they'd announce Math or MATH.

[joanmarie]

FWIW, user agents are already exposing the rendered (transformed) text. Below are three screenshots, the first from Firefox Nightly, the second from Epiphany (WebKitGtk), and the third a locally-built Chrome. All three are from Linux. I can grab macOS next in case that would be helpful.

In the meantime, what you'll see in each is that I've:

• Loaded data:text/html,<div style="text-transform: uppercase;">foo</div>
• As a result of the above, I'm seeing a rendered all-caps version of the text, namely "FOO"
• Using Accerciser's iPython console, I've used the Python bindings for AT-SPI2, to retrieve all of the accessible text for the accessible object backing the div whose text has been transformed. The command happens to be acc.queryText().getText(0, -1). What I get (and what the screen reader Orca gets) is the all-caps, rendered text, namely "FOO"

So the good news is that I'm already getting what I'd expect/want. 😄 Assuming this is the same on other platforms (my guess is that it is, with one caveat I'll come back to momentarily), it really doesn't matter if you type a literal all-caps or use CSS to transform it into all caps -- as far as the end user is concerned -- because the end user will wind up with the same result regardless of whether or not he/she happens to be sighted.

The caveat I mentioned is this: Some (Windows) screen readers historically have had virtual buffers or other recreations of the content. For any that still do: If they are grabbing the text from the DOM rather than from the accessibility tree, then one might indeed see differences in what the end user gets.

[joanmarie]

Update: On the Mac, I just performed the same experiment using Chrome Canary and Safari Technology Preview. And I got the same results, namely the accessible value obtained by inspecting the element with XCode's Accessibility Inspector is the all-caps, rendered "FOO."

[frivoal]

@joanmarie (disclaimer: you clearly know what you're talking about. I am not dismissing your expertise, but trying to understand it, as it doesn't quite mesh with my own sense of how this is supposed to work).

This is a bit counter intuitive to me, as I'd expect an upper-casing text transform to be the stylistic in the same way as a font-feature or a color change would be, and therefore that it should not be preserved, to avoid having ::first-line { text-transform: uppercase} result in the first line being read in a screaming voice or spelled out (neither of which seem the intended effect), or to avoid having 𝕸𝖆𝖙𝖍 being read as "mathematical bold fraktur capital M, mathematical bold fraktur small a, mathematical bold fraktur small t, mathematical bold fraktur small h" instead of as "math". This is not to say that this styling information should not be available to a user of the screen reader in some form (but then I'd expect similar announcements for text-transform: uppercase and font-variant-caps: all-small-caps to be announced in a similar way, or for text-transform: math-bold-fraktur and font-family: "Fraktur Bold"), but when reading "just the text", I'd expect the transform not to be applied. If it's semantically important, shouldn't it be in the source?

Also, only having access to the post-transform text seems to play poorly of the i18n oriented values:

• It breaks text-transform: full-width. Using it to display "IBM" as "ＩＢＭ" can be desirable in Chinese / Japanese / Korean text (particularly but not only in vertical text), but that doesn't mean that it should be read aloud as "full width Latin capital letter I, full width Latin capital letter B, full width Latin capital letter M". I still want to hear IBM. It's even worse if the word isn't an accronym to begin with. Maybe the Text-to-speech engine can be smart enough to know how to read words regardless of which character variant is being used, but short of reversing the transform (but then why have it applied in the first place), I expect it will, at least occasionally, run into things it doesn't know how to say other than by enumerating the Unicode character names. That sounds bad.
• It defeats the point of text-transform: full-size-kana: "りょ" and "りよ" are different (the first is ryo, the second is riyo), but at the very small font sizes sometimes used in ruby, using the smaller ょ in りょ can make the text hard to see, and so authors sometimes want to display りよ instead of りょ despite the difference. The whole point of doing it using text-transform: full-size-kana rather than by hard-coding りよ into the DOM is so that screen readers can read it as ryo instead of riyo. For example, if the ruby for 無料 (which means free / costless) is encoded (as it should) as むりょう, that is read is muryō, and all is understandable. If it is encoded (or rendered into) むりよう/muriyō, this could be misinterpreted as 無利用, which means "useless". For a sighted reader, the potential confusion is probably preferable to the letter being too small to read, and they would see the original ideographs next to it, clearing things up if they can read them. But for someone going through a screen reader, it could be pretty confusing. If the screen reader reads both the original text and the ruby, you still hear "free and useless", and if it sustitutes the ruby for the original text, you would just hear "useless", instead of the intended "free (free)".

All in all, I'd definitely expect the styling information to be available to the screen reader so that it can do something useful with it and inform the user of notable styling features that are deemed relevant (such as, as you mentioned, playing some tone, changing the voice pitch, displaying two dot-6 cells on a braille display, or whatever is appropriate), but I'd expect the text itself to be the untransformed text. If we don't have that, I don't really understand what the point of having text-transform in CSS instead of doing some server side preprocessing change to the document content itself (or the same DOM change in js/react/vue/… for people who're more fashionable than me).