[css-text-3] text-transform: full-size-kana

[frivoal]

Many years ago, we discussed, and eventually rule against, 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.

[fantasai]

This was originally defined in CSS Text Level 3: https://www.w3.org/TR/2012/WD-css3-text-20120119/#text-transform and was removed in 2012: https://www.w3.org/TR/2012/WD-css3-text-20120814/#recent-changes

[momdo]

FYI, see also section 3.3.3 in jlreq:

(note 3) | Slightly different from the question of the size of ruby, there is a question of whether or not small kana (cl-11) characters should be used in ruby annotations. Because the size is so small, there was no choice of using small kana in letterpress printing. Today there are cases where small kana are used in ruby annotations, but taking legibility into consideration, these cases should be limited to those where accurate readings are needed, such as for proper nouns.

[kojiishi]

The main argument against this feature was that...

Wasn't the main argument about preferring font-variant-east-asian: ruby?

[Crissov]

For the custom transforms mechanism I recently filed #3132, by the way.

[frivoal]

Wasn't the main argument about preferring font-variant-east-asian: ruby?

I don't think it was the main argument back then, but it is certainly worth considering now.

font-variant-east-asian: ruby seems aimed at a slightly different problem: both our spec and the open-type spec seem to advocate using in on regular kana to get better visual pairing between the base text and the ruby text. (css-text does that by showing an example of the word しんかんせん, which does not contain small kana, with thicker glyphs, and open type documentation suggests using it on U+3042, which is not a small kana).

That said, it is true that it could also be used to show large glyphs for small kana. Should it:

• pro: It allows, on a per-font basis, to pick a different way to cope with overly small kana
• pro: It exists, so there's no need to introduce anything new in css
• con: Doing it with a text-transform works even if the font fails to download
• con: Doing it with a text-transform works even if there's no available font that uses this open-type feature that way

[upsuper]

I would also think it's better be addressed by font-variant-east-asian: ruby.

con: Doing it with a text-transform works even if the font fails to download

I don't see why this is a con. Fonts provided by operating system is probably more likely to have better support on this kind of OpenType features. At least, Hiragino on macOS and Meiryo on Windows both have so (although Gecko has to avoid applying this feature on Windows due to a bug in old versions of Meiryo). None of them make the small kana's bigger, though.

[frivoal]

Fonts provided by operating system is probably more likely to have better support on this kind of OpenType features. [...] None of them make the small kana's bigger, though.

System fonts could do it, but don't. In-the-wild fonts might do it, but I don't know any that does, and even if we find some, it will have to be used as a web font.

So, if an author wants this effect, they have to rely on a web font (which might fail to download), and they have a very limited choice of fonts which actually do this, given that this is not what the feature was advertised to be about in the open type spec, and that therefore most font don't do the small-kana -> big-kana conversion.

That makes me think that the text transform avenue is still quite a reasonable one.

[fantasai]

I think the more important reason not to rely on font-variant: ruby is that font-variant: ruby is primarily about matching the weight of the glyph: whether you want to also use full-size kana is a separate question, you might or you might not. As has been noted, using full-size kana makes the kana a little easier to read because it's bigger, but it loses the distinction between two letters which are in fact different letters. It would be better if fonts were not encouraged to use full-size kana when font-variant: ruby is on so that the choice about whether full-size the kana remains open to the author and user.

[css-meeting-bot]

The CSS Working Group just discussed text-transform: full-size-kana, and agreed to the following:

• RESOLVED: Add text-transform: full-size-kana to Text L3 marked at-risk

The full IRC log of that discussion

<dael> Topic: text-transform: full-size-kana
<dael> github: https://github.com/w3c/csswg-drafts/issues/3143
<dael> florian: Wediscussed this a long time ago. I was opposed originally, but I regret that. Had in spec this value. It is meant to be used within Ruby. b/c characters in Ruby are very small there is a typographical process where you use different characters in very small font sizes [gives example]
<dael> florian: If people do that using the wrong letter in markup speech syntesis reads it wrong. So this was proposed to do the typographical thing without using a different character.
<myles_> U+3083 HIRAGANA LETTER SMALL YA
<myles_> U+3084 HIRAGANA LETTER YA
<dael> florian: Original objection was this is niche and instead of doing this we should allow authors to make custom text transforms. Wrote a spec for custom, but no one paid attention and there have been no additional us c ases. So there is no slippery slope.
<myles_> q+
<dael> florian: Another thing is there is an open type feature that can be turned on for Ruby and allow fonts to do this. That would only work if font you're using has that. But i t's not clear that it's meant for this effect in Ruby. And as far as I know actual fonts don't do that.
<dael> myles_: I think the general idea here is good. One thought and question. Thought I don't think font-varient is right. It is a unicode transformation. Font features weren't designed for this. We should model this as a text-transform. Is there ever a situation where Ruby wouldn't want this? Can it be on by default?
<dael> florian: I don't think on by default. Semantically it reads different. If he font size isnt' so small it's unreadable you might not want this.
<dael> fantasai: Agree with florian and myles_ that we should add. This is important for a11y. It keeps the underlying text data the same while allowing authors to do the style they want. And I agree font-varient Ruby is not right. That's about changing shape, not changing one letter to another.
<Rossen_> q?
<Rossen_> ack myles_
<myles_> q-
<dael> florian: Some authors might not want it because they argue it's not a legibility issue, people just got into the habit of doing it. If people want to do it is something that's disagreed on so it would not work as a default.
<dael> Rossen_: I hear support to add this. I also hear we should add this to transforms and not variants
<dael> Rossen_: Do we have other opinions?
<dael> fantasai: Do we add to L3 o r L4 of text? Originally in L3 but was removed.
<dael> Rossen_: Reason not to put it in L4?
<dael> fantasai: I think it's simple enoughwe won't get i ssues
<dael> florian: at-risk i n L3?
<dael> myles_: Will spec include list of mappings?
<dael> fantasai: Definitely.
<dael> Rossen_: L3 still h as quite a bit of open issues. Adding this to L3 won't delay. Let's add there and not mark at-risk
<dael> florian: I would mark at-risk. We're getting closer to CR
<dael> Rossen_: Looking at # of open issues I don't think we're close
<dael> florian: Really?
<dael> Rossen_: Please prove me wrong.
<dael> fantasai: We can adjust at-risk later.
<dael> Rossen_: Objections to adding text-transform: full-size-kana to Text L3 marked at-risk
<dael> RESOLVED: Add text-transform: full-size-kana to Text L3 marked at-risk

[macnmm]

I actually am not in favor of this feature for ruby -- when the ruby is over the base text, it is not correct to use small kana glyphs, or glyphs of the same weight. The glyphs for small kana with ruby variants should be full size and thicker. My reasoning is about the text stream and placement being separable -- if you place the ruby after the text in parentheses, you want small kana, but over the base text you do not. Transforming the text stream would be an extra destructive step when switching presentation styles.

[frivoal]

@macnmm I am not sure I understand your point. You say you disagree, but your arguments seem to be in favor:

when the ruby is over the base text, it is not correct to use small kana glyphs, or glyphs of the same weight. The glyphs for small kana with ruby variants should be full size and thicker.

I don't believe there is universal agreement that using full size kana on ruby over the base text is the only correct thing to do, although I do agree that there are authors who think it is. I am not speculating on the percentage, but it is more than a negligible share, and less than everybody, which I think is all we need to know in this case.

The addition of text-transform: full-size-kana is precisely to support authors who want full size kana glyphs in ruby over the base text.

My reasoning is about the text stream and placement being separable -- if you place the ruby after the text in parentheses, you want small kana, but over the base text you do not. Transforming the text stream would be an extra destructive step when switching presentation styles.

text-transform does not affect the underlying text stream (in other words, the DOM), only the way it is visually rendered. text-transform does not affect speech synthesis, nor copy&paste. Any such operation would still see the transformed small size kana.

The kind of style switching you mention is exactly what text-transform: full-size-kana enables. If an author uses ruby over the base text, they can turn this on, and if they use inline parenthesized ruby they can leave it off, since the markup contains the correct characters. Without this feature, we'd have the opposite problem: an author who'd want full-size-kana in ruby over the base text, they would have to use the full size characters in the markup, and therefore could not use the same markup to display parenthesized inline ruby without getting the characters wrong.

(not the topic of this issue, but the same is true for font-variant-east-asian: ruby to deal with thickness)

The alternative that would do enable the behavior you asked would be instead of having a property that lets authors opt in or out of this, to always and automatically do it as soon as we're using ruby over the base text. However, I insist that while a common and valid practice, it is not universally agreed upon, which means having it as an automatic default