Hello.

I have updated the ruby-overhang-spaces-vertical-003.html test. As you can 
see on wpt.fyi <https://wpt.fyi/results/css/css-ruby>, all ruby-overhang 
tests are now passing.

I appreciate everyone's valuable feedback and reviews throughout this 
process.

Best regards,

2026년 6월 10일 수요일 오후 9시 51분 3초 UTC+9에 [email protected]님이 작성:

> LGTM3
>
> On Tue, Jun 9, 2026 at 12:22 PM Daniel Bratell <[email protected]> wrote:
>
>> LGTM2 (note the test requirement)
>>
>> /Daniel
>> On 2026-06-08 20:40, Alex Russell wrote:
>>
>> Thanks for following up on these details. Assuming that we get the tests 
>> fixed (either by rebasing, or updating the implementation), LGTM1 
>>
>> Best,
>>
>> Alex
>>
>> On Saturday, June 6, 2026 at 6:52:31 PM UTC-7 [email protected] wrote:
>>
>>> Hello. 
>>>
>>> *Some ruby WPTs seem to be failing, is that expected? (including one 
>>> overhang-spaces).*
>>> ruby-overhang-spaces-vertical-003.html 
>>> <https://wpt.fyi/results/css/css-ruby/ruby-overhang-spaces-vertical-003.html?label=master&label=experimental&product=chrome&product=edge&aligned&q=ruby-overhang-*>
>>>  seems 
>>> to be failing in WPT environment, and it passed in Chromium LUCI 
>>> <https://ci.chromium.org/ui/p/chromium/builders/try/linux-rel/2685976> 
>>> and my local.
>>> Here is the test result image of WPT: 
>>> https://wpt.fyi/analyzer?screenshot=sha1%3A3fad62423ed1bbf8d08f84840a83d6d3d26332a5&screenshot=sha1%3Ac50e853a8303915e1e6da5dd13351aba6a2ee92d
>>> The result seems orange and blue lines are aligned as expected, but あ 
>>> character 
>>> in the ruby base has 1px difference. I'm not sure why this difference 
>>> occurs..
>>> Is it okay to add <meta name="fuzzy" content="maxDifference=0-255; 
>>> totalPixels=0-160"> for this test?
>>>
>>> *is it still the case that WebKit is shipping an implementation of this, 
>>> or is it shipping a different set of keywords?*
>>> It's shipping a different set of keywords. WebKit shipped for "auto" and 
>>> "none". And the updated set of keywords contain "auto", "spaces" and "none" 
>>> (alias of "spaces" for legacy support).
>>> I think the standard position is needed, so I've created 
>>> https://github.com/WebKit/standards-positions/issues/681.
>>>
>>> Thank you.
>>>
>>> 2026년 6월 4일 목요일 오전 12시 6분 58초 UTC+9에 [email protected]님이 작성:
>>>
>>>> Hey, 
>>>>
>>>> Thanks for the update! Some ruby WPTs seem to be failing, is that 
>>>> expected? (including one overhang-spaces). 
>>>>
>>>> Also a question about the WebKit status: since the CSSWG changed the 
>>>> syntax a little bit, is it still the case that WebKit is shipping an 
>>>> implementation of this, or is it shipping a different set of keywords?
>>>>
>>>> Thanks,
>>>> Vlad
>>>>
>>>> On Wednesday, May 27, 2026 at 6:32:07 PM UTC-4 [email protected] wrote:
>>>>
>>>>> 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/5dc3190b-6ba3-4aff-9a4d-c27298304ef4n%40chromium.org
>>  
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5dc3190b-6ba3-4aff-9a4d-c27298304ef4n%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/b61394ec-01d6-4456-b1fa-8f84be8344c5n%40chromium.org.

Reply via email to