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. On Fri, Oct 20, 2023 at 11:00 AM Domenic Denicola <dome...@chromium.org> wrote: > > > On Thu, Oct 19, 2023 at 11:33 PM Jeffrey Yasskin <jyass...@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. > > >> >> Jeffrey >> >> On Thu, Oct 19, 2023, 1:07 AM Domenic Denicola <dome...@chromium.org> >> wrote: >> >>> >>> >>> On Thu, Oct 19, 2023 at 4:41 PM TAMURA, Kent <tk...@chromium.org> wrote: >>> >>>> Contact emailstk...@chromium.org >>>> >>>> ExplainerNone >>>> >>>> Specificationhttps://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. >>> >>> >>>> >>>> >>>> Blink componentBlink>Layout>Ruby >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELayout%3ERuby> >>>> >>>> Search tagscss <https://chromestatus.com/features#tags:css>, ruby >>>> <https://chromestatus.com/features#tags:ruby> >>>> >>>> TAG reviewNone; Firefox already shipped this. >>>> >>>> TAG review statusNot 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 >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>> ?Yes >>>> >>>> Some of https://wpt.fyi/results/css/css-ruby and >>>> https://wpt.fyi/results/css/css-display/parsing >>>> >>>> >>>> Flag name on chrome://flagsNone >>>> >>>> Finch feature nameCssDisplayRuby >>>> >>>> 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 >>>> <https://chromestatus.com/>. >>>> >>>> -- >>>> TAMURA Kent >>>> Software Engineer, Google >>>> >>>> >>>> -- >>>> 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+unsubscr...@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 >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqEN8XsgSTymzAnpK7yXfWvYNF7Y1jqpcQ%2BXhTiMh22-cQ%40mail.gmail.com?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 blink-dev+unsubscr...@chromium.org. >>> 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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9XjE_aOHBBdy%3DNebWZHOKDMtUiNJ3b1fYbv%3Dh-fcqw9g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- TAMURA Kent Software Engineer, Google -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqHE8%3DpUF5NM25sk-Xx0wEie0yrzdZkCqaJCHNbeUFN5sQ%40mail.gmail.com.