This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It wasn't entirely clear to me from reading the spec whether the following was supposed to be valid: <!DOCTYPE html> <title>Ruby vs ins/del</title> <p><ruby>X<rt>x</rt>Y<ins><rt>y</rt></ins></ruby></p> I think so, given that it's semantically meaningful, <ins> is supposed to be transparent, and <ins> is occurring in a context where phrasing content is (one of the things) expected. On the other hand, this is going to be tough to validate and validator.nu says it's invalid. Either way, I think it's worth a note/example in the spec.
(In reply to comment #0) > It wasn't entirely clear to me from reading the spec whether the following was > supposed to be valid: > > <!DOCTYPE html> > <title>Ruby vs ins/del</title> > <p><ruby>X<rt>x</rt>Y<ins><rt>y</rt></ins></ruby></p> > > I think so, given that it's semantically meaningful, <ins> is supposed to be > transparent, and <ins> is occurring in a context where phrasing content is (one > of the things) expected. On the other hand, this is going to be tough to > validate and validator.nu says it's invalid. The messages that validator.nu emits for this markup instance are actually messages generated by the parser, prior to any validation taking place. It's indicating that there was a parse error -- the reason being that the HTML parsing algorithm in the spec defines that instance as such. See the case for 'A start tag whose tag name is one of: "rp", "rt"' in section 8.2.5.10 'The "in body" insertion mode' - http://dev.w3.org/html5/spec/tokenization.html#parsing-main-inbody "If the stack of open elements has a ruby element in scope, then generate implied end tags. If the current node is not then a ruby element, this is a parse error; pop all the nodes from the current node up to the node immediately before the bottommost ruby element on the stack of open elements." So when the parser hits the rt start tag after the ins start tag within the ruby element, it generates an ins end tag and emits an error message, and the ins and rt elements end up as siblings in the DOM. You can check this by looking at the DOM view for this markup in Live DOM Viewer running in either Firefox 4 or a recent Chrome version or WebKit nightly (which all now have parsers that conform to the parsing algorithm in the spec). http://software.hixie.ch/utilities/js/live-dom-viewer/ I'm not sure why the spec requires this behavior to begin with. I'm also not sure why it requires this behavior only when the rt start tag comes after a ruby element; so if you omit the ruby element, as in the following (which is invalid), the parsing behavior is different, and the rt element does end up as a child of the ins element in the DOM (instead of as sibling). > Either way, I think it's worth a note/example in the spec. It is documented in the section that specifies the parsing algorithm, but it really would be good to have it also noted at point of use in the authoring-conformance section that defines the content models for ruby and rt and rp element. There are other cases like this one -- where you can only understand the behavior if you also read the parsing algorithm. But since most authors are not going to read the parsing algorithm, it would be good to have all of these cases also noted in the corresponding authoring-conformance parts of the per-element sections of the spec.
(In reply to comment #1) > I'm not sure why the spec requires this behavior to begin with. I'm also not > sure why it requires this behavior only when the rt start tag comes after a > ruby element; so if you omit the ruby element, as in the following (which is > invalid), the parsing behavior is different, and the rt element does end up as > a child of the ins element in the DOM (instead of as sibling). I meant the following (but forgot to paste it in) <!DOCTYPE html> <title>Ruby vs ins/del</title> <p>X<rt>x</rt>Y<ins><rt>y</rt></ins></p>
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: Partially Accepted Change Description: see diff given below Rationale: The spec wasn't complete in its handling of transparent elements. I've tried to rewrite this part of the spec to make this clearer. I've also added more examples. Regarding the specific use case of <ruby>, the solution is simple: put the <ins> inside the <rt>. This is the same as when adding or removing an <li> (put the <ins> or <del> inside the <li>), which is an example in the spec. (As Mike mentions, <ruby> is additionally a bit more complicated due to the parsing implications.)
Checked in as WHATWG revision r5732. Check-in comment: Rewrite the rules for 'transparent' so that you can't put a <param> in an <ins> in an <object> (or similar things). http://html5.org/tools/web-apps-tracker?from=5731&to=5732
mass-move component to LC1