[css-writing-modes] spacing within text-combine-upright

[fantasai]

https://www.w3.org/TR/css-writing-modes-4/#text-combine-layout

When combining text as for text-combine-upright: all, the glyphs of the combined text are bidi-isolated and composed horizontally (ignoring letter-spacing and any forced line breaks, but using the specified font settings), similar to the contents of an inline-block box with a horizontal writing mode and a line-height of 1em.

We specify ignoring letter-spacing, but what should we do about word-spacing, text-autospace and text-spacing-trim? It's unlikely that any of these will be relevant, but if someone does try to use the affected characters, should these properties be honored or ignored? @kojiishi @MurakamiShinyu what do you think?

[fantasai]

Fwiw, my inclination is to ignore all of the spacing properties, and force text-spacing-trim to behave like trim-all.

[frivoal]

I agree the question is worth answering, and I probably agree with @fantasai 's suggestion above, although it could make sense to give authors a choice between trim-all and and no trimming at all.

[frivoal]

Not sure if this should be considered part of the same issue or an adjacent one, https://wpt.fyi/results/css/css-text/text-autospace/text-autospace-vertical-combine-001.html?label=experimental&label=master&aligned assumes that text-autospace has no effect at the boundaries of a text-combine-upright. I think that can be derived from existing text spec, as autospace

controls spacing between adjacent characters on the same line within the same inline formatting context

(cf https://drafts.csswg.org/css-text-4/#text-autospace-property)

and

When combining text as for text-combine-upright: all, the glyphs of the combined text are bidi-isolated and composed horizontally (ignoring letter-spacing and any forced line breaks, but using the specified font settings), similar to the contents of an inline-block box

(cf https://www.w3.org/TR/css-writing-modes-3/#text-combine-layout)

so you could say that text-combine-upright creates a distinct inline formatting context, and that's why there's no spacing. But it is a bit indirect, and not very precise ("similar to […]"). I think we could try and make that a tad more explicit.

EDIT: resolved by the explanation given in #9430 (comment)

[fantasai]

I don't think there's much utility to giving a choice here, and adding more properties and values to do it seems excessive.

[css-meeting-bot]

The CSS Working Group just discussed [css-writing-modes] spacing within text-combine-upright, and agreed to the following:

• RESOLVED: All of the text spacing properties don't apply to the squished-together character of t-c-u; text-spacing-trim is treated as trim-all

The full IRC log of that discussion

<TabAtkins> fantasai: there's a feature text-combing-upright which causes glyphs in upright vertical text to combine into a single combined block
<TabAtkins> like if you want "23" it'll smush into one block
<TabAtkins> fantasai: we specify that letter-spacing doesn't apply inside the smushed box, we treat it like a single character
<TabAtkins> fantasai: we didn't specify the other spacing properties, like word-spacing
<TabAtkins> fantasai: Proposal is we ignore all of them
<TabAtkins> fantasai: and for text-spacing-trim we treat it as trim-all
<TabAtkins> fantasai: generally you won't run into these sitautions anyway, but if you do you probably dont' want extra space making it even more squished
<TabAtkins> florian: I initially thought we wanted some optoins here, but on further thought i think we don't, and that fantasai is right
<TabAtkins> +1
<TabAtkins> Rossen_: objections?
<fantasai> illustration -> https://www.w3.org/TR/css-writing-modes-4/images/tate-chu-yoko.png
<TabAtkins> RESOLVED: All of the text spacing properties don't apply to the squished-together character of t-c-u; text-spacing-trim is treated as trim-all