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/
See also: bug 47596.
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.
Also, one of your ruby tests is buggy and is testing for a display value of hidden rather than none for the rp element.
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.
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.
https://github.com/NielsLeenheer/html5test/issues/51 was the original bug filed against the test suite.
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
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!
(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.
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".
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`.
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
Bug 261468 implements some of this.
*** This bug has been marked as a duplicate of bug 261468 ***