LGTM2

We discussed this in the API owners meeting today (present: Chris, Yoav,
Vlad, Jeffrey, Daniel, Alex, me) and think it makes sense to ship matching
the initial value that Safari already shipped. At that point we expect
https://github.com/w3c/csswg-drafts/issues/12386 to be resolved to match
the shipping implementations. In other words, this will be an opt-in.

On Wed, Jul 2, 2025 at 5:19 PM Daniel Bratell <bratel...@gmail.com> wrote:

> LGTM1
>
> /Daniel
> On 2025-06-17 04:35, Domenic Denicola wrote:
>
> Thanks for these updates. Do you have any ideas on when the WebKit
> difference might be resolved? We shouldn't block shipping on them, but if
> there's a chance that the initial value might change due to ongoing
> discussions, it would be good to know that before we ship.
>
> On Fri, Jun 13, 2025 at 3:43 PM Koji Ishii <ko...@chromium.org> wrote:
>
>> Thank you for the detailed reply.
>>
>> 2025年6月13日(金) 10:33 Domenic Denicola <dome...@chromium.org>:
>>
>>> Summary
>>>
>>> Inserts small spacings to match the established typographic rules
>>> automatically. The spec currently defines one rule for Han ideographic
>>> characters and one for French. The initial implementation focuses on the
>>> Han ideographic characters rule. Text written in Han ideographic writing
>>> systems often mixes multiple scripts, usually the Han ideographic scripts,
>>> Latin scripts, and ASCII digits. Small spacings when switching from and to
>>> non-Han ideographic scripts often help readability. This property lets
>>> browsers insert such spacings automatically. This property has several
>>> values, including values for other writing systems. The initial
>>> implementation supports the following subset: `text-autospace: normal |
>>> no-autospace`. This feature also includes the `text-spacing` shorthand, as
>>> now all longhands are available.
>>>
>>>
>>> Not blocking, but I am curious if we have an objection to the other 6
>>> values? Or are they just lower priority?
>>>
>>
>> No objections, just lower priority. Many apps/platforms implemented this
>> feature, Blink's initial support is at the same level as iOS. MS Word
>> provides alpha/numeric distinctions. As far as I know, InDesign is the only
>> app that provides `punctuation`, and no apps provide `insert` and `replace`.
>>
>> *WebKit*: Shipped/Shipping (https://developer.apple.com/
>>> documentation/safari-release-notes/safari-18_4-release-notes#CSS)
>>>
>>>
>>> It seems like we will not be interoperable with Safari by shipping this,
>>> because of the different initial value. So, I think opening a standards
>>> position request would be valuable. If they do not intend to align their
>>> initial value with the spec, e.g. for performance reasons, then that would
>>> be good for us to know.
>>>
>>
>> They have filed a bug by themselves
>> <https://bugs.webkit.org/show_bug.cgi?id=287355>, and we're discussing
>> it offline. I shared our experiences on the performance with them and
>> they're looking into it.
>>
>> Is this feature fully tested by web-platform-tests
>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>> ?Yes
>>>
>>>
>>> https://wpt.fyi/results/css/css-text?label=master&label=experimental&aligned&q=text-autospace
>>>
>>>
>>> Safari fails many of these tests. Is that only due to the initial value
>>> difference? Or are the mismatches here revealing other interoperability
>>> issues?
>>>
>>
>> For parsing tests, they also shipped a subset, so they're fine.
>>
>> For rendering, 2 out of 4 failures are due to the initial value
>> difference. One real failure is an RTL test which I think is not likely a
>> real use case. Another is a Chinese test for a recent spec change.
>>
>> Also, you state that shipping this feature will include shipping the
>>> text-spacing shorthand. Are there tests available for that property?
>>>
>>
>> Thanks, good catch, I missed it. Since this is a shorthand, there're only
>> parsing tests (added to the chromestatus page too)
>>
>> https://wpt.fyi/results/css/css-text/parsing?label=master&label=experimental&aligned&q=text-spacing%20and%20not%28text-spacing-trim%29
>> One failure in Blink is due to not shipping the `auto
>> <https://drafts.csswg.org/css-text-4/#valdef-text-autospace-auto>`
>> value. This is a platform-specific value, but we can't simulate what iOS
>> does.
>>
>>  Flag name on about://flags
>>>
>>>
>>> Finch feature name
>>>
>>> Non-finch justificationNone
>>>
>>>
>>> A Finch feature name is required for new features.
>>>
>>
>> Thank you for pointing this out, fixed.
>>
>> Anticipated spec changes
>>>
>>> Open questions about a feature may be a source of future web compat or
>>> interop issues. Please list open issues (e.g. links to known github issues
>>> in the project for the feature specification) whose resolution may
>>> introduce web compat/interop risk (e.g., changing to naming or structure of
>>> the API in a non-backward-compatible way).
>>>
>>>
>>> https://github.com/w3c/csswg-drafts/issues/11013 seems relevant, and
>>> resolved. Do you know if there is any blocker for incorporating the edits
>>> into the specification?
>>>
>>
>> Blink implements this resolution. The spec update is just due to not
>> anyone taking it, I'll work on it.
>>
>> https://github.com/w3c/csswg-drafts/issues/9857 also seems a bit
>>> worrying, about the stability of the text-spacing part of this intent.
>>>
>>
>> As noted above, `auto` is the value for platform-specific behavior, so
>> that browsers can ship the OS-compatible behavior, similar to `font-family:
>> system-ui
>> <https://developer.mozilla.org/en-US/docs/Web/CSS/font-family#system-ui>`.
>> Blink doesn't ship this value, so that authors can at least know the
>> behavior isn't available.
>>
>> https://github.com/w3c/csswg-drafts/issues/9471 also seems potentially
>>> like an issue that might affect this, but I cannot tell for certain.
>>>
>>
>> Sorry this is left over. There were many discussions on each character
>> like this. This led us to think that we need a standard at the
>> Unicode-level, and hence the UTR#59 <https://unicode.org/reports/tr59/> was
>> born. I commented and closed.
>>
>> --
> 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 visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-o-GDWgjPbXHH0J6MAA-%2BLb6c9Hp40Wt9%2BknVFei9w4Q%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-o-GDWgjPbXHH0J6MAA-%2BLb6c9Hp40Wt9%2BknVFei9w4Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> --
> 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 visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b097f26d-ff2e-4e39-8e79-28e37de60918%40gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b097f26d-ff2e-4e39-8e79-28e37de60918%40gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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 visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYezUUt7QCwFAg25K1Exo0NZ1rZ5KQjkL2yUzF5_7qLoYg%40mail.gmail.com.

Reply via email to