LGTM3 On Wednesday, July 2, 2025 at 8:24:18 AM UTC-7 Philip Jägenstedt wrote:
> 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/bf65cca9-f931-478a-9d58-3ab7d77382f6n%40chromium.org.
