[css-text] shaping breaks and typographic characters

[r12a]

8.3. Shaping Across Element Boundaries
https://drafts.csswg.org/css-text/#boundary-shaping

for any box whose boundary separates the two typographic character units

i'm not clear how typographic units are relevant here – in fact, i think it may be incorrect to invoke them. Apart from the fact that what constitutes a typographic unit is particularly vague here, i think that actually we just want to say "for any box whose boundary separates two characters", where character refers to Unicode code points. For example, these rules should presumably apply to diacritics (it is a common use case to want to colour diacritics or accents differently from a base character), or a part of a grapheme cluster.

(See the tests at https://www.w3.org/International/tests/repo/results/css-text-shaping.en.html#diacritics for examples that actually show browsers applying the same behaviour to diacritics as to normal letters.)

[fantasai]

Hi Richard,
The case of a boundary within a typographic character unit is defined slightly differently, in the last section of https://drafts.csswg.org/css-text-3/#characters ; there are more allowances for that case, such as treating the whole unit as part of one element or the other.

Let me know if this seems acceptable or if there are specific changes to the spec you think are necessary.

[r12a]

I assume you mean

The rendering characteristics of a typographic character unit divided by an element boundary is undefined: it may be rendered as belonging to either side of the boundary, or as some approximation of belonging to both. Authors are forewarned that dividing grapheme clusters by element boundaries may give inconsistent or undesired results.

This doesn't really help for my use case. Suppose you want to colour the diacritic red in "é". Afaict, there is no guarrantee i'd be able to do it given the non-committal text in the spec, and therefore the use case produces non-interoperable results across browsers (as you say in the second sentence). I see that as a significant problem, because for educational texts you often want to do that kind of thing (not just for accents, but for parts of all kinds of elements of a grapheme cluster in other scripts).

I'd rather see text that says that UAs should seek to maintain the positioning of the glyphs involved in a typographic unit, regardless of where the element boundaries are.

[behdad]

This doesn't really help for my use case. Suppose you want to colour the diacritic red in "é". Afaict, there is no guarrantee i'd be able to do it given the non-committal text in the spec

There is not guarantee you can do that, since a font might decide to produce that shape using one glyph instead of two.

[r12a]

Then it would presumably be obvious straight away that it wasn't working, and i could use a different font. Whereas with the current approach it might look fine in my normal browser, but not as intended in anyone else's, which is why i think is a case for standardisation.