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 bughttps://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> >> . >> > -- 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/CAM0wra-OEgSydSXoRu2inZuVPu2f9iPeZ5uS1VHxip7u2BSmyA%40mail.gmail.com.
