Bug 44515 - Implement ruby CSS display values
Summary: Implement ruby CSS display values
Status: RESOLVED DUPLICATE of bug 261468
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL: http://beta.html5test.com/testcases/r...
Keywords: BrowserCompat
Depends on: 261468
Blocks: html5test
  Show dependency treegraph
 
Reported: 2010-08-24 05:01 PDT by Niels Leenheer (HTML5test)
Modified: 2023-10-08 11:17 PDT (History)
14 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Niels Leenheer (HTML5test) 2010-08-24 05:01:56 PDT
When HTML5 ruby elements are rendered their display property values are inline or block. The HTML5 specification *1 suggest the use of 'ruby' for <ruby> elements, 'ruby-text' for <rt> elements and 'none' for <rp> elements. Additionally 'ruby-base' is suggested for children of <ruby> elements that are not <rt> or <rp> elements.

These display property values correspond to the values defined in the CSS3 Ruby Module *2. Even though full support for this CSS module is not present at the moment, the HTML5 ruby support should use the suggested display property values.

This change is worth 3 points on the HTML5test *3 which currently does not award any points to Webkit for ruby support.

---
*1 http://www.w3.org/TR/html5/rendering.html#display-types
*2 http://www.w3.org/TR/css3-ruby/
*3 http://html5test.com/
Comment 1 Alexey Proskuryakov 2010-11-09 19:59:40 PST
See also: bug 47596.
Comment 2 Dave Hyatt 2010-11-20 19:55:55 PST
The problem here is that ruby can work as both an inline or block construct (or even as an inline-block construct).  A single display type, "ruby", is insufficient to model this.  The CSS3 Ruby draft has huge flaws, and if you're basing your HTML5 test suite off it, then you need to fix your test suite.

I think the HTML5 spec should be amended to drop all mention of unique Ruby display types until problems like this can be addressed.

The ruby-base and ruby-text display types are fine, but the Ruby display type needs to be broken into two display types.  We'd be willing to break the inline-block version of Ruby since it would rarely be desired, but I don't think we want positioning or floating a ruby to suddenly turn off its ruby behavior. Therefore block-level ruby has to be specifiable.
Comment 3 Dave Hyatt 2010-11-20 20:19:50 PST
Also, one of your ruby tests is buggy and is testing for a display value of hidden rather than none for the rp element.
Comment 4 Dave Hyatt 2010-11-20 20:33:00 PST
Note that even if we did add these display types, we would have to add them as -webkit-ruby-text, etc., so we wouldn't pass your test anyway.
Comment 5 Eric Seidel (no email) 2012-01-20 18:13:07 PST
http://www.w3.org/TR/css3-ruby/#display also seems relevant.

I agree with Dave, the test should be fixed to not depend on these display types until the specs settle down.
Comment 6 Eric Seidel (no email) 2012-01-20 18:55:57 PST
https://github.com/NielsLeenheer/html5test/issues/51 was the original bug filed against the test suite.
Comment 7 Simon Pieters (:zcorpan) 2021-03-30 15:51:53 PDT
See https://github.com/whatwg/html/issues/2134 for 'display' of <rp> (outside ruby). Chromium and Gecko and the spec have

rp { display: none }

but WebKit uses display: inline here

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/9130
Comment 8 Ahmad Saleem 2022-06-14 15:11:35 PDT
This seems to be clarified in Spec discussion and now Blink and Gecko aligns with each other based on Comment 07 (refer to Spec discussion link).

Is this need to be updated within Webkit?

https://github.com/WebKit/WebKit/blob/8afe31a018b11741abdf9b4d5bb973d7c1d9ff05/Source/WebCore/html/RubyElement.cpp#L56

Thanks!
Comment 9 Tim Nguyen (:ntim) 2022-08-02 05:03:23 PDT
(In reply to Dave Hyatt from comment #2)
> The problem here is that ruby can work as both an inline or block construct
> (or even as an inline-block construct).  A single display type, "ruby", is
> insufficient to model this.  The CSS3 Ruby draft has huge flaws, and if
> you're basing your HTML5 test suite off it, then you need to fix your test
> suite.
> 
> I think the HTML5 spec should be amended to drop all mention of unique Ruby
> display types until problems like this can be addressed.
> 
> The ruby-base and ruby-text display types are fine, but the Ruby display
> type needs to be broken into two display types.  We'd be willing to break
> the inline-block version of Ruby since it would rarely be desired, but I
> don't think we want positioning or floating a ruby to suddenly turn off its
> ruby behavior. Therefore block-level ruby has to be specifiable.

CSS display module level 3 addresses this by separating display into outer display and inner display.
Comment 10 Ahmad Saleem 2022-10-05 14:21:31 PDT
Fixed in Safari Technology Preview 155 due to updating UA Stylesheet to make "rp" as display:none aligned with Standard.

All browsers show "in body" in this test now - http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=9130 

Safari 16 show "rp in body".

Marking this as "RESOLVED CONFIGURATION CHANGED".
Comment 11 Tim Nguyen (:ntim) 2022-10-06 07:52:32 PDT
I do think we should implement display: ruby / inline ruby / block ruby like Firefox does, and use them in our UA stylesheet, instead of hacking it in `createElementRenderer`.
Comment 12 Karl Dubost 2022-10-16 20:40:11 PDT
Some status 
https://wpt.fyi/results/css?label=master&label=experimental&aligned&view=subtest&q=status%3Afail%20ruby


                chr       edge      fx         saf tp
                108       108.      107        155
css-break/      4 / 4     4 / 4     0 / 4      2 / 4
css-content/    0 / 1     0 / 1     0 / 1      0 / 1
css-ruby/       22 / 100  27 / 100  89 / 100   13 / 100
css-text-decor/	0 / 6     0 / 6     6 / 6      0 / 6
css-ui/         0 / 1     0 / 1     1 / 1      0 / 1
Subtest Total	26 / 112  31 / 112  96 / 112   15 / 112
Comment 13 Tim Nguyen (:ntim) 2023-10-08 11:17:34 PDT
Bug 261468 implements some of this.
Comment 14 Tim Nguyen (:ntim) 2023-10-08 11:17:58 PDT

*** This bug has been marked as a duplicate of bug 261468 ***