[css-text-4] SVSes should be considered when classifying punctuations

[AmeroHan]

Standardized variation sequences should be considered when classifying punctuations (fullwidth/halfwidth, corner-justified/centered).

In UAX #11: East Asian Width:

4.3 Variation Sequences

In some cases, variation sequences have been defined that request a character to be displayed as wide or narrow. These variation sequences are defined in StandardizedVariants.txt [StandardizedVariants] in the [UCD], but they are identified via the description of the intended glyph style and not via a formal property of the variation sequence. Nevertheless, the presence of the respective variation selector should be considered a sufficient condition to resolve ambiguous width to either wide or narrow, perhaps subject only to availability in the actual font used. If the font does not have a wide form, a variation sequence requesting the wide form would be ignorable and it makes no sense to treat the character as “Wide” if it is being displayed as “Narrow.”

5 Recommendations

…

Note: Some variation sequences may specify a narrow or wide presentation behaviour. (This can be true for sequences defined in StandardizedVariants.txt [StandardizedVariants] in the [UCD] or in emoji-variation-sequences.txt in [UTS51].) For such sequences, the width behaviour specified by a variation sequence can differ from the East_Asian_Width property of the base character of that variation sequence. The width indication of the variation sequence can specify some aspects of glyph appearance such as advance width, while not specifying other aspects of presentation, such as rotational behavior in vertical text.

Some variation sequences are as follows (image from Source Han Sans readme file):

The current CSS specification does not mention SVSes, nor do browsers handle them correctly. On Chrome 143:

<ol>
  <li>
    <!-- `text-spacing-trim` succeeds -->
    测试“测试<mark>”</mark><mark>“</mark>测试”测试
  </li>
  <li>
    <!-- `text-spacing-trim` fails -->
    测试“&#xFE01;测试<mark>”&#xFE01;</mark><mark>“&#xFE01;</mark>测试”&#xFE01;测试
  </li>
  <li>
    <!-- to make sure that SVSes are effective -->
    测试“&#xFE00;测试”&#xFE00;“&#xFE00;测试”&#xFE00;测试
  </li>
</ol>
<ol>
  <li>
    <!-- `text-spacing-trim` succeeds -->
    测试<mark>：</mark><mark>（</mark>测试
  </li>
  <li lang="zh-Hant-TW">
    <!-- `text-spacing-trim` succeeds -->
    测试<mark>：</mark><mark>（</mark>测试
  </li>
  <li>
    <!-- `text-spacing-trim` fails -->
    测试<mark>：&#xFE01;</mark><mark>（</mark>测试
  </li>
</ol>

:root {
  font-family: 'Source Han Sans SC';
  font-feature-settings: 'locl';
}
mark {
  background-color: aqua;
}
mark + mark {
  background-color: yellow;
}

Interactive test

Related Issues: w3c/clreq#637

[AmeroHan]

We also need to consider the following cases:

1. If the current font does not provide a glyph for a variation sequence, should the variation selector be ignored, or should the user agent switch to the next font in the fallback list?
2. If we choose to ignore the variation selector, or if we opt to search through fallback fonts but none of them provide a glyph for the variation sequence, then there are two scenarios:
   • The most common scenario: Neither the variation sequence nor the variation selector has a glyph. In this case, we need to pretend the variation selector does not exist and perform possible spacing trim. In other words, <…, punctuation, VS, punctuation, VS, …> should be treated as <…, punctuation, punctuation, …> rather than <…, punctuation, ZWSP, punctuation, ZWSP, …>.
   • Another less common scenario: The final chosen font does not define a glyph for the variation sequence, but does define a glyph for the variation selector (such as Last Resort Font). In this case, we may need to skip spacing trim and render the glyph instead.