Hi Philip, thanks for the questions. Please see replies inline:

Thanks for linking the tests, judging just by the test names it looks like
> many combinations of languages and fonts are tested.
>

Yes, many combinations are to ensure they test different branches in our
code.

Some of the tests are failing though, is that expected?
>

Yes, this current implementation supports subset (see below), and failing
tests are for values that are not supported yet.

Also, I see that some of the tests don't actually use text-spacing-trim,
> are those just testing default behaviors or what's the reason?
>

Yes, the initial value `normal
<https://drafts.csswg.org/css-text-4/#valdef-text-spacing-trim-normal>`
applies the pair-kerning (adjacent) and line-end (the table below the value
list might be easier to know which value affects where). Tests without
`text-spacing-trim` are testing these behaviors.

The design doc says "This version implements a subset of the values defined
> in the spec", is that still accurate, or is there support for all
> of space-all | normal | trim-auto | trim-start | space-first | trim-all?
>

It's still accurate. The current implementation supports 4 values: normal |
trim-start | space-all | space-first. I added this to the chromestatus entry
<https://chromestatus.com/feature/5170044014690304> (I thought I did this
but it looks like it's gone somehow).

Finally, since text-spacing-trim and text-autospace are longhands
> for text-spacing, what is the plan for text-spacing? Will we introduce the
> shorthand later together with text-autospace? That should mean that
> something like `text-spacing: trim-all` won't work initially, even though
> it doesn't involve text-autospace. But on the other hand shipping the
> shorthand without text-autospace would break `text-spacing: punctuation`
> and similar. I don't have a suggestion here, but can you clarify what the
> overall plan is?
>

The current plan is to ship the shorthand when both properties ship.
Shipping the shorthand only for `text-spacing-trim` is technically
possible, but it complicates the code and tests. I think it's prudent to
defer until both properties ship.

Originally we thought the `text-autospace` could ship before
`text-spacing-trim` or together, but a blocking spec issue was found
recently. Given its complexity, it's likely to take a few quarters.

As a data point, I see that the flag in STP is called "CSS text-spacing
> property", which suggests all 3 properties behind a single flag. It might
> not ship together, but it's a good guess.


Right, the current code in WebKit under the flag isn't ready to ship yet,
but this is one of their 2024 plans discussed at the WebKit contributor
meeting. I'm talking to WebKit engineers about our status, they're
interested in seeing web developer feedback to Chromium. This is one of the
reasons I think we should ship `text-spacing-trim` first, without waiting
for `text-autospace` to be ready.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHe_1dK8uf9%3DGeK-PPx5YV7DaPBLpsyL%2BLuZXs%2BjraPMfC9F3w%40mail.gmail.com.

Reply via email to