EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: I don't understand. Could you elaborate? What needs defining exactly?

The entire processing model.  What are UAs supposed to do with this stuff?  How are they supposed to handle <ruby> tags that have three <rp> kids and no <rt> kid?  That sort of thing.  Right now the normative UA requirements here seem to be close to nonexistent.

Or, put another way, as a UA implementor I have no idea how I'd implement this part of the spec.

The rendering rules are defined in the rendering section. Are you saying those are not sufficient? (Asking since this bug report is referencing the element definition.)

Ah, I hadn't seen those.  The full text of those, as far as I can see, is:

  Put these rules in the UA stylesheet:

    ruby { display: ruby; }
    rt { display: ruby-text; }
    rp { display: none; }

  For the purposes of the CSS ruby model, runs of children of ruby elements that
  are not rt or rp elements are expected to be wrapped in anonymous boxes whose
  'display' property has the value 'ruby-base'. [CSSRUBY]

  User agents that do not support correct ruby rendering are expected to render
  parentheses around the text of rt elements in the absence of rp elements.

That's not sufficient, no, given that the CSS ruby model does not describe the rendering of the box model that the HTML5 rules can produce in some cases.  For example, if <ruby> only has <rt> kids and nothing else.  Or if <ruby> has an <rt> kid, then some text, then an <rt> kid, then some more text, then another <rt> kid.

I think that would need to be fixed in the CSS Ruby Module.

Perhaps, but since you seemed to be drawing a distinction between "what HTML5 specifies" and "The CSS Ruby module" in https://bugzilla.mozilla.org/show_bug.cgi?id=256274#c86 you clearly think that there's a difference.

As far as I can tell, handling the invalid-markup cases involves some of those "concepts not present in HTML5".

And the point remains: as an implementor, I currently cannot implement HTML5's ruby stuff and have any hope of interop.  I'd have to make dozens of arbitrary decisions (and likely will); then expect "content will break" pushback if those decisions need to be changed after ruby has been in use in the wild for a while.

So I agree this is not an ideal situation. The distinction I meant to draw in the Mozilla bug was between what HTML5 requires of the CSS Ruby Module and what http://www.w3.org/TR/ruby/ requires of the CSS Ruby Module. Because if we really want the latter we will need changes to HTML5 -- for the other elements -- and we have to see whether everyone is on board with that. (I would prefer it if everyone had the simple version to start with and then we go from there.)

Now unrelated to whether of those two paths we pick, the CSS Ruby Module will need to be updated to handle unexpected situations. (Much like we have done to some extent with CSS tables.)

What do you think HTML5 requires from the CSS ruby module, exactly?

A proper definition of the display values mentioned in the references section. Probably roughly in line with how they have been implemented in Internet Explorer. (Except where we can do better and people are willing to change, etc.)

Beyond that there is no real dependency. I do not think it would make sense to add more display types than we have elements for, but some of the other properties probably still make sense. I have not looked at that in detail.

The HTML5 spec requires defining how the 'ruby', 'ruby-text', and 'ruby-base' display types interact, in arbitrary configurations.

CSS3 Ruby defines the behavior one the "one 'ruby-base' with multiple 'ruby-text's" case in terms of 'ruby-text-container' boxes.  And it defines that you can only use 'ruby-text-container' with 'ruby-base-container'.  So at that point handling the HTML5 stuff requires support for all the ruby display types in CSS3 Ruby, and then elements can be styled with those types in arbitrary combinations.  And then where is the difference, exactly?

Now maybe you're suggesting that CSS3 Ruby should be rewritten in such a way as to support the HTML5 stuff without pulling in the container box types?  Or that one should allow container boxes created to handle CSS Ruby but not allow specifying those display types in stylesheets?  I'd be fine with either of those approaches, if it's actually less work than full CSS3 Ruby support... is it?  Hard to tell, since we don't have a processing model defined for any of those options.

If by "processing model" you mean "pixel-level rendering model", then that's out of scope of the HTML spec. The CSS spec will have to define how the ruby display values work in all combinations and with any other display types; if it doesn't then that's a bug with that spec, not with HTML. (Any spec that introduces new display types has to define how they work in all combinations since it's not possible to prevent authors from constructing arbitrary combinations.)

I would transfer this bug to the CSSWG but they don't seem to use Bugzilla. Anne, is anyone working on that spec?

Then why are you giving examples of expected rendering, if expected rendering is not in fact defined in this specification?

Given the state of the CSS Ruby module, and the fact that it's not in fact being actively worked on, last I checked, it _may_ be better to not define ruby by reference to it.  We should see as we get closer to CR.  Right now, again, there's no sane way to interoperably implement the HTML5 text.

I give the examples of expected rendering because those are the expected renderings, regardless of what we end up defining for error handling.

I don't know what else to do than refer to CSS here. I'm certainly not going to write the CSS module as part of HTML.

Well, the other option is to pull the spec section entirely (might happen anyway if we try to exit CR, due to lack of interop).

Fair enough.

I'll mark this as closed for now, with the hope that CSS Ruby will get a usable definition before we get to exit CR. If it doesn't, as you say, we'll probably have to drop this feature.


EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: see discussion above