[csswg-drafts] [css-text-4] text-transform: full-size-kana

frivoal has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-text-4] text-transform: full-size-kana ==
Many years ago, we [discussed, and eventually rule against](https://www.w3.org/Search/Mail/Public/search?keywords=full-size-kana&hdr-1-name=subject&hdr-1-query=&index-grp=Public_FULL&index-type=t&type-index=www-style), a `full-size-kana` value to `text-transform`

It would have turned something like しゃ into しや. The two are not equivalent, (the first is pronounced “sha”, the second “shiya”), but at very small font sizes inside ruby text, this substitution is sometimes used to keep things at a legible size.

Without this text transform, authors wanting this effect will just hard code the transformed string into the source, which does the wrong thing from searches or speech synthesis.

The main argument against this feature was that this was a rather niche i18n feature, and if we started to add those to text-transform, there'd be no end to it, so it would be better to pursue a generic extension mechanism. I was one of those pushing this line of thought, and even drafted a possible generic mechanism: https://specs.rivoal.net/css-custom-tt/

I repent, and I think we should have added/kept `full-size-kana`.

* In the years since, there hasn't been an avalanche of requests for more i18n transforms like this one, so the slippery slope concern does seem to have been founded.
* In the meanwhile, the i18n/a11y problem that this was meant to solve remains unsolved.
* The custom text-transform mechanism has some interesting difficulties, and has not received any attention since then.

I think we should consider adding this value back.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3143 using your GitHub account

Received on Tuesday, 25 September 2018 05:50:52 UTC