Open fantasai opened 3 years ago
I expanded upon the cited email at https://github.com/w3c/csswg-drafts/issues/5927#issuecomment-779562023.
Even though it wouldn't solve all of the cited issues, I think Unicode normalization is probably a good idea. It would address the fullwidth versus normal width punctuation cases between CJK and Latin languages where I would expect a match (and autohiding). I also would expect Hangul characters built from component characters (Hangul Jamo) to match the precomposed versions, though I'm not sure where that would occur in practice.
It would also allow matching in a weird case I ran into where I deliberately used a combining diacritic plus base letter variant of a character instead of the precomposed diacritic-plus-letter version because the latter was missing in a designer font I was using, so the former looked better. In this case, while I was using ruby, I didn't have to match anything, but would nevertheless expect a match in a comparison to the precomposed character.
I can't find the minutes, so maybe @r12a or @aphillips or @frivoal can confirm if this discussion I remember actually happened. :) But IIRC the i18nWG concluded that NFKC would be too aggressive in at least some cases, but wanted to know if the CSSWG would consider NFC and/or ignoring white space.
@fantasai It's here in our TPAC minutes--almost exactly as you remember it :-). Search for the word "hide" and the conversation proceeds from there.
The CSS Working Group just discussed [css-ruby-1] Should auto-hide match use NFKC and/or strip white space?
, and agreed to the following:
RESOLVED: only perform whitespace stripping before comparing the base and annotation texts
(responding to the IRC log discussion in the comment above)
Note that I18N spent a long time creating a document about string matching Charmod-Norm. When specifying string matching or when considering what to apply, consider referencing the best practices found there. In particular, I18N recommends against performing Unicode normalization for most matching regimes. I think our previous half-hearted recommendation to look at NFC for ruby base matching came out of a TPAC discussion in which NFKC was being considered. But upon reflection, if the base and ruby text were not encoded the same except under NFC, treating them as different would be unsurprising (and represents a pretty rare corner case in any event--the only case that springs to mind might be the handling of dakuten marks in Japanese, which are sometimes combining, but even then the difference might be intentional??)
https://lists.w3.org/Archives/Public/www-style/2016Dec/0108.html raised some use cases for ruby auto-hiding other than strict string equality. Many of the examples would require custom rules (which could be done manually with
visibility: collapse
), but some of these could be automatically solved by stripping white space and/or matching via NFKC. Should we enable such normalization for auto-hiding string comparison?