Hello. Yes, I updated both in these patches, per the CSSWG resolution. - 7805625: [ruby-overhang] Support for parsing and serialization for 'spaces' | https://chromium-review.googlesource.com/c/chromium/src/+/7805625 - 7809406: [ruby-overhang] Support overhang for space, NBSP, other space separator | https://chromium-review.googlesource.com/c/chromium/src/+/7809406 - 7839338: [ruby-overhang] Fix ruby-overhang-spaces-011-ref.html WPT | https://chromium-review.googlesource.com/c/chromium/src/+/7839338 - 7809475: [ruby-overhang] Support overhang for full-width open/close/middle dot | https://chromium-review.googlesource.com/c/chromium/src/+/7809475
Added WPTs: "ruby-overhang-spaces-*" files in https://wpt.fyi/results/css/css-ruby Thank you. Minseong Kim 2026년 5월 28일 목요일 오전 12시 6분 56초 UTC+9에 [email protected]님이 작성: > Hi, > > I saw the API Owners chip was changed to "review_requested", but without > any additional context. Are the WPTs and implementation updated per the > CSSWG resolution? > > thanks, > Mike > On 4/8/26 10:31 p.m., Minseong Kim wrote: > > Hello. > > I missed to share the issue link of mozilla position I created. > https://github.com/mozilla/standards-positions/issues/1372 > > Thank you! > > 2026년 4월 9일 목요일 AM 12시 7분 24초 UTC+9에 [email protected]님이 작성: > >> Hey, >> >> Thank you for following up. Please let us know when the WPT and >> implementation are updated and we will review. >> >> Also, just as a reminder, I think the mozilla position is still >> outstanding (from Mike's comment above). Could you please file one at >> https://github.com/mozilla/standards-positions and reference it here? >> >> Thank you >> Vlad >> >> On Monday, April 6, 2026 at 10:15:15 AM UTC-4 [email protected] wrote: >> >>> Following the recent CSSWG resolution >>> <https://github.com/w3c/csswg-drafts/issues/5912#issuecomment-4180375625>, >>> I'm updating this to include the new `spaces` value and designate `none` as >>> its alias. This change allows ruby to overhang whitespace and CJK >>> punctuation even when none is specified, preventing unnecessary layout >>> gaps. I'll update the implementation and WPT to align with this behavior. >>> >>> Thank you for all! >>> >>> 2026년 3월 19일 목요일 AM 12시 22분 24초 UTC+9에 Chris Harrelson님이 작성: >>> >>>> I see that CSSWG issue 5912 has been added to an agenda. Let's wait to >>>> see what the CSSWG decides. >>>> >>>> On Tue, Mar 17, 2026 at 5:07 AM Mike Taylor <[email protected]> >>>> wrote: >>>> >>>>> On 3/17/26 5:48 a.m., Minseong Kim wrote: >>>>> >>>>> Thank you all for the reviews. >>>>> >>>>> *Can we request a signal?* >>>>> I've found the opened issue in bugzilla >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1611410. I updated >>>>> Firefox's signal field to "positive, with bugzilla link" in the >>>>> chromestatus.com entry. >>>>> >>>>> Thank you for finding that! >>>>> >>>>> Per >>>>> https://www.chromium.org/blink/launching-features/wide-review/#signal-process, >>>>> >>>>> an open bugs doesn't qualify as Positive. Mind filing an issue at >>>>> https://github.com/mozilla/standards-positions to request an official >>>>> position? Apologies for not being more clear in my original request. >>>>> >>>>> >>>>> *1) Has the W3C i18n WG reviewed this, and what do they think?* >>>>> Yes, they reviewed this on >>>>> https://github.com/w3c/csswg-drafts/issues/4492 discussion. They >>>>> supported this addition to address specific cultural and accessibility >>>>> requirements. But, after that, frivoal@ proposed "ruby-overhang:none is >>>>> too >>>>> aggressive" on https://github.com/w3c/csswg-drafts/issues/5912. >>>>> >>>>> 2) Can the browser just do a better job of applying the 'auto' value, >>>>> so that authors don't have to manually fix errors with 'none'? >>>>> While browsers strive to improve auto behavior, none is a specific >>>>> requirement for educational and accessibility contexts. For example, in >>>>> children's books or textbooks for low-vision readers, authors need to >>>>> ensure none overhang to prevent any reading confusion, even if the UA >>>>> thinks the overhang is safe. So, I updated the motivation field in >>>>> chromestatus entry. >>>>> 2026년 3월 17일 화요일 AM 10시 43분 12초 UTC+9에 [email protected]님이 작성: >>>>> >>>>>> On Mon, Mar 16, 2026 at 5:47 PM 'Jeffrey Yasskin' via blink-dev < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> 1) Has the W3C i18n WG reviewed this, and what do they think? >>>>>>> >>>>>> >>>>>> It might also be worth asking about the state of review from the >>>>>> Japanese >>>>>> Language Enablement <https://github.com/w3c/jlreq/> and Chinese >>>>>> Language Enablement <https://w3c.github.io/clreq/home> task forces. >>>>>> >>>>>> -David >>>>>> >>>>> -- >>>>> >>>> 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 [email protected]. >>>>> >>>> To view this discussion visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/944936c7-5490-49b7-9a22-32cbb76fc3ea%40chromium.org >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/944936c7-5490-49b7-9a22-32cbb76fc3ea%40chromium.org?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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5d35c49e-5c85-4527-a1a5-a2defa1b5f50n%40chromium.org.
