On Thursday, June 12, 2025 at 5:55:11 PM UTC+9 Koji Ishii wrote:
Contact emailsko...@chromium.org, lin...@chromium.org ExplainerNone Specificationhttps://drafts.csswg.org/css-text-4/#text-autospace-property Design docs https://docs.google.com/document/d/10G1uasooKpKjNeyr1wtLV85wFMlc_ TK4-vb9LG_3Fzw/edit#bookmark=id.t5tzxbvnz8gg 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? Blink componentBlink>Layout>Inline <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ELayout%3EInline%22> TAG reviewNone TAG review statusNot applicable Risks Interoperability and Compatibility The initial value of the property `normal` inserts the spacing, and therefore shipping this feature changes the CJK text layout slightly. This has happened when iOS shipped the feature a few years ago for their native apps. Safari 18.4 shipped this property, but with a different initial value from the spec. This is being tracked at https://bugs.webkit.org/show_ bug.cgi?id=287355. *Gecko*: Positive (https://github.com/mozilla/standards-positions/issues/903 ) *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. *Web developers*: Positive (https://groups.google.com/a/ chromium.org/g/blink-dev/c/my9MyWxa2ns/m/0zIX-8R8AQAJ) *Other signals*: WebView application risks Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? Debuggability Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?Yes 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? Also, you state that shipping this feature will include shipping the text-spacing shorthand. Are there tests available for that property? Flag name on about://flags Finch feature name Non-finch justificationNone A Finch feature name is required for new features. Rollout planWill ship enabled for all users Requires code in //chrome?False Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1463890 Sample links https://jsbin.com/radatet/edit?html,output Estimated milestonesShipping on desktop139Shipping on Android139Shipping on WebView139 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? https://github.com/w3c/csswg-drafts/issues/9857 also seems a bit worrying, about the stability of the text-spacing part of this intent. https://github.com/w3c/csswg-drafts/issues/9471 also seems potentially like an issue that might affect this, but I cannot tell for certain. Link to entry on the Chrome Platform Statushttps://chromestatus.com/ feature/5202578236768256?gate=5117712266690560 Links to previous Intent discussionsIntent to Prototype: https://groups. google.com/a/chromium.org/d/msgid/blink-dev/CAHe_ 1dLULX9bM8FqXiTRg47GmvC5-cQTZ_s6yvB7OMuQe8ZAxg%40mail.gmail.com This intent message was generated by Chrome Platform Status <https://chromestatus.com/>. -- 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/56e090f5-3a70-4ff4-9afa-91dde0daddb2n%40chromium.org.
