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.