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/CAHe_1d%2BM0xAz0_G_7i-yK70AM9mGEShyKN2cnEhpa01wLMMW9Q%40mail.gmail.com.
