Intent to Ship: CSS ruby-overhang property

[Chromestatus]

Contact emails

jja0...@gmail.com

Specification

https://drafts.csswg.org/css-ruby/#ruby-overhang

Summary

Support of new CSS property `ruby-overhang` is added. The property accepts one of `auto` and `none` keywords, and controls overhang of ruby annotation text.

Blink component

Blink>Layout>Ruby

Web Feature ID

ruby-overhang

Motivation

A ruby annotation can sometimes obscure adjacent content when it overhangs. The ruby-overhang property gives authors a way to disable this behavior and prevent unwanted overlap.

Initial public proposal

No information provided

Search tags

css, ruby

TAG review

No information provided

TAG review status

Not applicable

Goals for experimentation

None

Risks

Interoperability and Compatibility

Risks are low. This is a support for new value of CSS properties. So sites not using properties won't be affected. Safari has supported this feature for years.

Gecko: No signal

WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=114678)

Web developers: No signals

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?

No

Debuggability

No information provided

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?

Yes
"ruby-overhang*" files in https://wpt.fyi/results/css/css-ruby

Flag name on about://flags

enable-experimental-web-platform-features

Finch feature name

CSSRubyOverhang

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/366873207

Estimated milestones

Shipping on desktop	148
Shipping on Android	148
Shipping on WebView	148

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).

No information provided

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6560118298771456?gate=6494196590575616

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ffa95dff-f582-41cb-b0a5-d80159656284n%40chromium.org

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

Minor nit: based on the linked WebKit bug, this landed in a Tech Preview about 6 months ago (or maybe some parts of support landed - a bit unclear). But it does seem to be supported in Safari 26.3 stable.

Gecko: No signal

Can we request a signal?

--
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+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69b7479a.050a0220.87ff1.0cd9.GAE%40google.com.

[Alex Russell]

+Jeff for advice on TAG review/FYI.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Jeffrey Yasskin]

This is likely to be outside the TAG's expertise, but it would be useful to see answers to two questions:

1) Has the W3C i18n WG reviewed this, and what do they think?

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'? I see the motivations is "A ruby annotation can sometimes obscure adjacent content when it overhangs.", but the spec already says "Overhang is only allowed to the extent that it does not cause collisions between the neighboring content and the ruby container’s annotation boxes or its overlapped base’s contents.", and it refers to https://w3c.github.io/jlreq/, which includes a note that "ruby characters on either side of a base hiragana (cl-15) that are overhanging it may end up touching, as seen in Figure 137. Setting ruby text like this is not recommended because of the possibility of misreading them. It is recommended to insert one em spacing between the first run of ruby characters and the next run of ruby characters." 

We've also occasionally objected to using 'auto' as a property value, but I think this use fits with the rough guidelines in https://github.com/w3ctag/design-principles/issues/568.

Jeffrey

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[David Baron]

On Mon, Mar 16, 2026 at 5:47 PM 'Jeffrey Yasskin' via blink-dev <blin...@chromium.org> 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 and Chinese Language Enablement task forces.

-David

[Minseong Kim]

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.

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에 dba...@chromium.org님이 작성:

[Mike Taylor]

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.