Intent to Ship: Ruby-specific display values

[TAMURA, Kent]

Contact emails

tk...@chromium.org

Explainer

None

Specification

https://drafts.csswg.org/css-ruby-1/#ruby-display

Summary

New CSS display property values, "ruby", "ruby-base", and "ruby-text", are added. The default display values of <ruby>, <rb> and <rt> are changed to them, and ruby layout respects these display values. Web authors can use any elements such as <div> to render ruby by setting the new display values.

Blink component

Blink>Layout>Ruby

Search tags

css, ruby

TAG review

None; Firefox already shipped this.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This feature does not affect most <ruby> usages on existing pages. However, the rendering results may change if the `display` property value of <ruby> or <rt> is set to a non-default value because ruby rendering is triggered by the new `display` value, not the tag name. https://chromestatus.com/metrics/feature/timeline/popularity/3282 At most 0.07% page views might be affected. However, <ruby>s in 9 of the top 10 sites have no <rt>, and their rendering won't be changed. The remaining 1 site will be broken, and it's same as Firefox's rendering result. We have a plan to show a console message about this incompatibility before enabling the feature.

Gecko: Shipped/Shipping

WebKit: Positive (https://github.com/WebKit/standards-positions/issues/232)

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?

None

Debuggability

Rolling css_properties.json5 into devtools-frontend should be enough.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

Some of https://wpt.fyi/results/css/css-ruby and https://wpt.fyi/results/css/css-display/parsing

Flag name on chrome://flags

None

Finch feature name

CssDisplayRuby

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=880802

Estimated milestones

Shipping on desktop

121

Shipping on Android

121

Shipping on WebView

121

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/6416726833233920

This intent message was generated by Chrome Platform Status.

--

TAMURA Kent
Software Engineer, Google

[Domenic Denicola]

On Thu, Oct 19, 2023 at 4:41 PM TAMURA, Kent <tk...@chromium.org> wrote:

Contact emails

tk...@chromium.org

Explainer

None

Specification

https://drafts.csswg.org/css-ruby-1/#ruby-display

Summary

New CSS display property values, "ruby", "ruby-base", and "ruby-text", are added. The default display values of <ruby>, <rb> and <rt> are changed to them, and ruby layout respects these display values. Web authors can use any elements such as <div> to render ruby by setting the new display values.

<rb> is not a standard HTML element, and is marked as obsolete: https://html.spec.whatwg.org/#rb

This is a historically contentious topic; see e.g. https://github.com/whatwg/html/issues/7587 and https://github.com/whatwg/html/issues/1771 . I think if Chromium is interested in reintroducing the rb element to the standard, it'd be good to discuss that with the standards community, and work on a proper change to the HTML Standard.

In the meantime, I'd suggest not introducing any default CSS changes that only work with elements marked as obsolete in the HTML Standard.

 

--
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/CAGH7WqEN8XsgSTymzAnpK7yXfWvYNF7Y1jqpcQ%2BXhTiMh22-cQ%40mail.gmail.com.

[Jeffrey Yasskin]

My reading of #1771 is that the only thing keeping <rb> out of HTML is the lack of a Blink or WebKit implementation. It looks like https://github.com/whatwg/html/pull/6478 is already written to improve the text, so the only thing for Kent to do is to make sure that this change implements that PR and then say so on the PR?

Jeffrey

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9XjE_aOHBBdy%3DNebWZHOKDMtUiNJ3b1fYbv%3Dh-fcqw9g%40mail.gmail.com.

[fantasai]

On 10/19/23 03:41, TAMURA, Kent wrote:
>
> Specification
>
> https://drafts.csswg.org/css-ruby-1/#ruby-display
>
> Summary
>

> New CSS displayproperty values, "ruby", "ruby-base", and "ruby-text", are

> added. The default display values of <ruby>, <rb> and <rt> are changed to
> them, and ruby layout respects these display values. Web authors can use any
> elements such as <div> to render ruby by setting the new display values.

It seems you're listing a subset of values, which makes me wonder what
differences you would be introducing between Blink's behavior and the behavior
described in the specs (if any)?

> TAG review
>
> None; Firefox already shipped this.

Firefox shipped a complete implementation of the ruby box model, so it's a bit
different from what you're proposing.
> /Gecko/: Shipped/Shipping
>
> /WebKit/: Positive (https://github.com/WebKit/standards-positions/issues/232)

WebKit's position is also against the whole spec...

I think it would be important to understand how Blink's proposed
implementation might differ from the spec and from Firefox's implementation,
particularly in terms of the box model and layout structures it generates for
various ruby markup patterns.

Also, CSS Ruby Layout is quite complicated, do you have a prototype already? I
didn't see an Intent to Prototype come through earlier. I think it would be a
good idea to evaluate the quality of the implementation and any differences
with Firefox before approving an intent to ship. At least, if I were in
charge, I would want to...

~fantasai

[Domenic Denicola]

On Thu, Oct 19, 2023 at 11:33 PM Jeffrey Yasskin <jyas...@google.com> wrote:

My reading of #1771 is that the only thing keeping <rb> out of HTML is the lack of a Blink or WebKit implementation. It looks like https://github.com/whatwg/html/pull/6478 is already written to improve the text, so the only thing for Kent to do is to make sure that this change implements that PR and then say so on the PR?

Sort of, but as Elika's email alludes to, the situation is a bit more complicated. That PR includes both rb and rtc, as part of a whole new ruby model, of which Kent is proposing to ship only a part. It seems we would need a cut-down version of that PR which extends the current ruby + rt model to a new intermediate ruby + rb + rt model.

My main constraint is that we don't ship something that relies on rb, without rb becoming part of the HTML spec. There are multiple ways to satisfy this constraint, but the technically simplest is probably to remove the UA stylesheet update to rb that Kent proposes, and continue shipping the rest of the CSS features (including the HTML stylesheet updates to ruby and rt).

Other possibilities include shipping a ruby + rb + rt model (including HTML spec changes), or shipping a ruby + rb + rtc model (which I think is what Firefox is shipping, according to Elika. And would also require HTML spec changes, albeit ones that are partially done, but unreviewed, in PR 6478.)

Note that while the ordering I've given above is for technical simplicity, there may be other concerns about reaching cross-browser consensus. As you noted, it seems there is conditional consensus on the most-technically-complex ruby + rb + rtc model, if we do go that route.

[TAMURA, Kent]

Oh, I made a mistake! This intent should drop the part of <rb> and 'ruby-base'.  I don't intend to introduce the "ruby + rb + rt" model.  I'd like to change the current "ruby + rt" model to "display:ruby + display:ruby-text".  Sorry for the confusion!

Anyway I should make a PR for the HTML specification.

[TAMURA, Kent]

On Fri, Oct 20, 2023 at 4:42 AM fantasai <fantasa...@inkedblade.net> wrote:

On 10/19/23 03:41, TAMURA, Kent wrote:
>
>         Specification
>
> https://drafts.csswg.org/css-ruby-1/#ruby-display
>
>         Summary
>
> New CSS displayproperty values, "ruby", "ruby-base", and "ruby-text", are
> added. The default display values of <ruby>, <rb> and <rt> are changed to
> them, and ruby layout respects these display values. Web authors can use any
> elements such as <div> to render ruby by setting the new display values.

It seems you're listing a subset of values, which makes me wonder what
differences you would be introducing between Blink's behavior and the behavior
described in the specs (if any)?

I think the new behavior will be a subset of CSS ruby.  Blink will be compatible with CSS ruby box generation, but web authors won't have a way to specify ruby-base-container and ruby-text-container to elements.

 

>         TAG review
>
> None; Firefox already shipped this.

Firefox shipped a complete implementation of the ruby box model, so it's a bit
different from what you're proposing.
> /Gecko/: Shipped/Shipping
>
> /WebKit/: Positive (https://github.com/WebKit/standards-positions/issues/232)

WebKit's position is also against the whole spec...

I don't think WebKit is against the specification though their ruby development is not active.

 

I think it would be important to understand how Blink's proposed
implementation might differ from the spec and from Firefox's implementation,
particularly in terms of the box model and layout structures it generates for
various ruby markup patterns.

Also, CSS Ruby Layout is quite complicated, do you have a prototype already? I
didn't see an Intent to Prototype come through earlier. I think it would be a
good idea to evaluate the quality of the implementation and any differences
with Firefox before approving an intent to ship. At least, if I were in
charge, I would want to...

We don't have an implementation of this change yet.

 

~fantasai

--
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/9d2c0ed1-478f-4f30-976a-eaff5d2c3ea6%40inkedblade.net.

[TAMURA, Kent]

I found the HTML specification already had the following:

https://html.spec.whatwg.org/C/#phrasing-content-3

ruby { display: ruby; }

rt { display: ruby-text; }

I think what we should do is to remove algorithms at https://html.spec.whatwg.org/C/#the-ruby-element:the-ruby-element-19 .

[TAMURA, Kent]

On Fri, Oct 20, 2023 at 11:39 AM TAMURA, Kent <tk...@chromium.org> wrote:

On Fri, Oct 20, 2023 at 4:42 AM fantasai <fantasa...@inkedblade.net> wrote:

On 10/19/23 03:41, TAMURA, Kent wrote:
>
>         Specification
>
> https://drafts.csswg.org/css-ruby-1/#ruby-display
>
>         Summary
>
> New CSS displayproperty values, "ruby", "ruby-base", and "ruby-text", are
> added. The default display values of <ruby>, <rb> and <rt> are changed to
> them, and ruby layout respects these display values. Web authors can use any
> elements such as <div> to render ruby by setting the new display values.

It seems you're listing a subset of values, which makes me wonder what
differences you would be introducing between Blink's behavior and the behavior
described in the specs (if any)?

I think the new behavior will be a subset of CSS ruby.  Blink will be compatible with CSS ruby box generation, but web authors won't have a way to specify ruby-base-container and ruby-text-container to elements.

 

>         TAG review
>
> None; Firefox already shipped this.

Firefox shipped a complete implementation of the ruby box model, so it's a bit
different from what you're proposing.
> /Gecko/: Shipped/Shipping
>
> /WebKit/: Positive (https://github.com/WebKit/standards-positions/issues/232)

WebKit's position is also against the whole spec...

I don't think WebKit is against the specification though their ruby development is not active.

I found that WebKit started to implement CSS Ruby last month.  https://commits.webkit.org/267937@main

WebKit has 'display: ruby' and 'display: ruby-text' though they're not enabled yet.

 

 

I think it would be important to understand how Blink's proposed
implementation might differ from the spec and from Firefox's implementation,
particularly in terms of the box model and layout structures it generates for
various ruby markup patterns.

Also, CSS Ruby Layout is quite complicated, do you have a prototype already? I
didn't see an Intent to Prototype come through earlier. I think it would be a
good idea to evaluate the quality of the implementation and any differences
with Firefox before approving an intent to ship. At least, if I were in
charge, I would want to...

We don't have an implementation of this change yet.

 

~fantasai

--
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/9d2c0ed1-478f-4f30-976a-eaff5d2c3ea6%40inkedblade.net.

--

TAMURA Kent
Software Engineer, Google

[TAMURA, Kent]

API owners,

I think this intent is ready for API owner approvals.

* Domenic's concern was resolved by dropping '<rb>' from the scope of the intent.
* We found we didn't need to update the HTML specification.

  ** It already asks "display:ruby" and "display:ruby-text" for <ruby> and <rt>
  ** I wrote "what we should do is to remove algorithms at https://html.spec.whatwg.org/C/#the-ruby-element:the-ruby-element-19". But we don't need to remove them because they are not for rendering purposes.

* WebKit is developing this feature. Firefox already shipped.

On Thu, Oct 19, 2023 at 4:41 PM TAMURA, Kent <tk...@chromium.org> wrote:

[Domenic Denicola]

Yes, I confirm that I have no more concerns at this point!

--
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/CAGH7WqFTDZiUd980%3DOHb3OsQ8-279kXb9dSQu2JYprOX%2Bx8JGA%40mail.gmail.com.

[Mike Taylor]

Thank you very much for the summary - I was trying to parse the thread on Friday and meant to ask follow-up questions. :)

LGTM1

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-J66ckraNAKjs1Ps6wsv%2BQnPKPuBX4RUA4y3315W1Cmg%40mail.gmail.com.

[Mike Taylor]

Also, please request approval for the rest of the review gates (right now I only see Debuggability); you'll be blocked on getting the rest of the LGTMs until those are in progress.

[fantasai]

On 10/19/23 22:39, TAMURA, Kent wrote:

> fantasai wrote:
> > It seems you're listing a subset of values, which makes me wonder what
> > differences you would be introducing between Blink's behavior and the
> > behavior described in the specs (if any)?
>
> I think the new behavior will be a subset of CSS ruby.  Blink will be
> compatible with CSS ruby box generation, but web authors won't have a way to
> specify ruby-base-container and ruby-text-container to elements.

OK, that seems reasonable. So therefore if the author writes in their stylesheet:

ruby { display: ruby; }
rt { display: ruby-text; }

rb { display: ruby-base; }

They will get the exact same rendering as in Firefox for all markup
permutations of <ruby>, <rb>, and <rt>, correct?

If that's true, then I agree with setting those values on <ruby>, <rt>, and
<rb> and shipping such an implementation.

> > WebKit's position is also against the whole spec...
>
> I don't think WebKit is against the specification though their ruby
> development is not active.

Sorry, I wrote that confusingly. WebKit's position is *regarding* the whole
spec. :) They are obviously in support.

> > I think it would be important to understand how Blink's proposed
> > implementation might differ from the spec and from Firefox's implementation,
> > particularly in terms of the box model and layout structures it generates for
> > various ruby markup patterns.
> >
> > Also, CSS Ruby Layout is quite complicated, do you have a prototype already? I
> > didn't see an Intent to Prototype come through earlier. I think it would be a
> > good idea to evaluate the quality of the implementation and any differences
> > with Firefox before approving an intent to ship. At least, if I were in
> > charge, I would want to...
>
> We don't have an implementation of this change yet.

I think it would be good to evaluate the change before deciding whether it's
ready to ship. If you don't have an implementation, you can't evaluate which
bugs need to be fixed before you ship vs which you are willing to fix afterwards.

~fantasai

[Rick Byers]

Hey Kent,

To Fantasai's point, can you point to the specific WPT test cases for this intent? Are Chrome or Firefox failing any, and if so can you explain why?

Tentative LGTM2 assuming WPT coverage shows we're matching Firefox behavior. Also happy to discuss the nuance here first if it's not completely the case that we match Firefox.

Rick

--
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/973e0592-b537-4c14-b3b0-87953bad890c%40inkedblade.net.

[Daniel Bratell]

LGTM3 but attend to Rick's comment below before shipping.

(Fantasia/Kent: It should be possible to test the implementation using the flags the WPT bots use to test so I assume Fantasia can test it with an appropriate flag and new enough build? chrome://flags/#enable-experimental-web-platform-features ? )

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_xCX0L%2Bf0HDj2Uy%2B%2BkXNMRKmRbuaaFvuUHZGXdk7mymg%40mail.gmail.com.

[TAMURA, Kent]

On Thu, Nov 2, 2023 at 12:53 AM Rick Byers <rby...@chromium.org> wrote:

Hey Kent,

To Fantasai's point, can you point to the specific WPT test cases for this intent? Are Chrome or Firefox failing any, and if so can you explain why?

Tentative LGTM2 assuming WPT coverage shows we're matching Firefox behavior. Also happy to discuss the nuance here first if it's not completely the case that we match Firefox.

Rick

On Mon, Oct 30, 2023 at 3:12 PM fantasai <fantasa...@inkedblade.net> wrote:

On 10/19/23 22:39, TAMURA, Kent wrote:
> fantasai wrote:
> >  It seems you're listing a subset of values, which makes me wonder what
> > differences you would be introducing between Blink's behavior and the
> > behavior described in the specs (if any)?
>
> I think the new behavior will be a subset of CSS ruby.  Blink will be
> compatible with CSS ruby box generation, but web authors won't have a way to
> specify ruby-base-container and ruby-text-container to elements.

OK, that seems reasonable. So therefore if the author writes in their stylesheet:

   ruby { display: ruby; }
   rt { display: ruby-text; }
   rb { display: ruby-base; }

They will get the exact same rendering as in Firefox for all markup
permutations of <ruby>, <rb>, and <rt>, correct?

That's right.

The following markup will construct pairs different from the current Chrome and WebKit, but it's same with Firefox.

    <style>.rb { display:ruby-base; }</style>

    <ruby><span class="rb">base1</span><span class="rb">base2</span><rt>rt1</rt><rt>rt2</rt></ruby>

I think this affects css/css-ruby/ruby-box-generation-00*.html in WPT. But the test won't pass because Chrome won't have <rtc> and <rbc>.  I'm going to add a test without <rtc> and <rbc>.

[TAMURA, Kent]

We decided not to ship `ruby-base` at this time due to an interoperability concern.

We'll reconsider it while looking at the status of WebKit.