Intent to Implement and Ship: Line-breakable ruby

135 views
Skip to first unread message

TAMURA, Kent

unread,
May 31, 2024, 4:49:16 AMMay 31
to blink-dev

Specification

https://drafts.csswg.org/css-ruby/#break-within

Design docs


https://docs.google.com/document/d/1hzvrwoE_0aw08X_CaU40zV5bXbMQjY2SHQHj3Np4sDo/edit?usp=sharing

Summary

Line-breaks are possible within elements with `display: ruby`. A single pair of a ruby-base and a ruby-text has never been line-breakable, and it has been pushed to the next line if the current line had no enough space for the entire pair. Now each of the ruby-base and the ruby-text can be split into multiple lines.



Blink component

Blink>Layout>Ruby

Search tags

ruby

TAG review

None; This is a small behavior change, and there is no API to cover this behavior.

TAG review status

Not applicable

Risks



Interoperability and Compatibility

Compatibility risk: * Web authors might expect rubies are not line-breakable. They need to specify `text-wrap: nowrap` or something to disable line-breaking if they don't want line-breaking. Interoperability risk: * This would be the first implementation of the behavior.


<ruby> appears in about 0.14% of page views [1].  Rubies with long content are very rare, and this change will affect much less than 0.14% page views.

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?

None



Debuggability

Existing DevTools functionalities are enough.



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

https://wpt.fyi/results/css/css-ruby/break-within-bases



Flag name on chrome://flags

enable-experimental-web-platform-features

Finch feature name

RubyLineBreakable

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/324111880

Estimated milestones

Shipping on desktop128
DevTrial on desktop127
Shipping on Android128
DevTrial on Android127
Shipping on WebView128


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

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5077282711666688

This intent message was generated by Chrome Platform Status.


--
TAMURA Kent
Software Engineer, Google


Philip Jägenstedt

unread,
Jun 3, 2024, 4:57:13 AMJun 3
to TAMURA, Kent, blink-dev
LGTM1

This is a change of default behavior, but the previous behavior is likely very rare and it can be achieved using `text-wrap: nowrap`.

Since the text-wrap part is important for adoption of this, can you check if text-wrap.tentative.html still needs to be tentative? The test has a comment about Chrome support, but no link to open spec issues.

--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqGSv71qaDAHEmo-%3D_kbx6ywT7bBW8MyJR-YyZX4Xp42yA%40mail.gmail.com.

Aaron Leventhal

unread,
Jun 3, 2024, 10:00:12 AMJun 3
to TAMURA, Kent, blink-dev
We do some interesting reorganization of ruby content in the a11y tree.
Can we create some DumpAccessibilityTreeTest tests for this and I'll take a look at the a11y tree and make sure it's sensible.

TAMURA, Kent

unread,
Jun 3, 2024, 10:16:49 PMJun 3
to Philip Jägenstedt, blink-dev
The test "text-wrap.tentative.html" is tentative because of text-wrap:balance and text-wrap:pretty.  I'll do:
- File a spec issue for them, and
- Make a non-tetative test for text-wrap:nowrap.

TAMURA, Kent

unread,
Jun 3, 2024, 10:18:19 PMJun 3
to Aaron Leventhal, blink-dev
Sure.  I'll make a DumpAccessibilityTreeTest with a line-broken <ruby>.

Daniel Bratell

unread,
Jun 4, 2024, 2:53:10 AMJun 4
to TAMURA, Kent, Philip Jägenstedt, blink-dev

LGTM2

/Daniel

Domenic Denicola

unread,
Jun 4, 2024, 2:56:32 AMJun 4
to Daniel Bratell, TAMURA, Kent, Philip Jägenstedt, blink-dev
LGTM3.

It might be worth manually testing popular Japanese sites that use ruby to make sure this doesn't cause issues. But, I think it would be hard for sites to depend on specific line breaking behavior in a way that could cause breakage.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/50c1386d-9b8f-44ca-9536-5e03cb9af613%40sarasas.se.

Philip Jägenstedt

unread,
Jun 4, 2024, 2:55:47 PMJun 4
to TAMURA, Kent, blink-dev
I see, is it because the exact behavior of text-wrap:balance and text-wrap:pretty are up to implementations? Since this is likely to remain the case indefinitely I think calling the test tentative isn't quite right, I'm not sure if the spec say "may" or "optional", but in spirit I think optional works here.

Thank you for adding a non-tentative test too!
Reply all
Reply to author
Forward
0 new messages