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.
