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.

Reply via email to