LGTM2 I agree that it makes sense to wait with the shorthand until we support both of the longhand properties. Some developers may be surprised when text-spacing doesn't work but text-spacing-trim does, but it can be feature detected so I don't think it's worth delaying all 3 properties to ship together.
On Tue, Feb 13, 2024 at 10:13 AM Domenic Denicola <dome...@chromium.org> wrote: > LGTM1 > > On Thursday, February 1, 2024 at 8:42:36 PM UTC+9 Koji Ishii wrote: > >> 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/CAARdPYfqvBkiYkW2n%2BZ%2BvKpYLKDw3FLvvJ9VJfhC-yFMTR8fzg%40mail.gmail.com.
