Support rb and rtc elements in the parser (ruby)

[annevk]

Apart from the specific error messages for end-of-file and “body” &
“html” end tags, this matches what WebKit and Blink have implemented.
Only Blink implements these as HTMLUnknownElement.

[annevk]

Light background reading:

• https://bugzilla.mozilla.org/show_bug.cgi?id=33339#c106 (onwards)
• https://codereview.chromium.org/482373002
• http://trac.webkit.org/changeset/167437

[domenic]

Can we get a bit more detail on the compatibility? I'm specifically wondering:

• What do Edge and Gecko implement?
• What interfaces do they use?

Happy to run e.g. live-dom-viewer test cases.

[annevk]

Possible article problems:
103720:   <code>p</code> element, an <code>rb</code> element, an <code>rp</code> element, an <code>rt</code>
103721:   element, or an <code>rtc</code> element, the UA must pop the <span>current node</span> off the
103732:   <code>p</code> element, an <code>rb</code> element, an <code>rp</code> element, an <code>rt</code>
103733:   element, an <code>rtc</code> element, a <code>tbody</code> element, a <code>td</code> element, a

Not sure why this is suddenly a problem.

[domenic]

Maybe it only checks changed lines?

[annevk]

No, build.sh actually whitelists rt and rp. So for this change we need to add rb and rtc to the script. Wonderful.

[annevk]

Firefox uses HTMLElement using <rtc><script>w(document.querySelector("rtc"))</script> as input to Live DOM Viewer. I don't have Edge.

[annevk]

Apart from the class question, there's also:

• Should these elements be conforming? Based on @Hixie's comments in that bug, I think they probably shouldn't. Although clearly there's also folks that think they should be. Also, I'm not sure I'm equipped to write the text for this and the text in HTML51 does not seem good enough.
• Should these elements have rendering rules? They do in HTML51 (strangely enough rbc does too, which otherwise goes unmentioned). Presumably Firefox and Safari implement those. Not sure about Edge.

[Hixie]

IMHO keeping ruby sane is a lost cause. We should just spec whatever the implementations implement and not bother trying to fight it. This includes letting authors do whatever the heck it is that the ruby community wants to let them do. I was going to spec what they implemented many months ago, I just never got around to it because of not having editing bandwidth in general.

[sideshowbarker]

@Hixie I’d personally prefer that we at least figure out if/how to include language saying something like:

Documents should not use the rb and rtc elements unnecessarily; if a passage of text in a document can be marked up effectively without rb and rtc, it should be.

(Replace “Documents“ above with “Authors” if we want.)

My rationale is around that is the fact that generally, if authors read the spec and see particular elements in the spec, the authors assume those elements are the “right” thing to use, and they tend to automatically think they should use those elements, and they want to use them.

And in the case of Ruby, they’ll see rb and rtc and say, “I guess because these are here in the spec, I should try to use [the more complex] way of marking up my text with these, rather the [much simpler] way that that doesn’t use them—because otherwise why would the editors put these elements in the spec for me to use?”

So a “Documents should not use the rb and rtc elements unnecessarily” requirement in the spec would help to prevent that—help to prevent authors from wasting their time, and being confused, and asking unnecessary questions in various fora, and giving other authors bad info in various fora, etc.

[annevk]

I emailed folks from Apple https://lists.w3.org/Archives/Public/www-archive/2015Sep/0006.html and Microsoft https://lists.w3.org/Archives/Public/www-archive/2015Sep/0007.html since only Mozilla appears to have anything implemented beyond the parser changes: http://mxr.mozilla.org/mozilla-central/source/layout/style/html.css#791.

[myakura]

cc. @kojiishi

[annevk]

@nox discovered that the patch for WebKit (see #101 (comment)) is different from HTML51 and from what Chromium and Gecko implemented. In WebKit <rtc><rp> results in <rp> being a sibling rather than a child. Good times.

So based on Microsoft's reply and these findings about WebKit it seems ruby parsing is now three-way forked. Styling is two-way forked with only Mozilla making changes (though not matching the HTML51 rendering section, so three-way forked technically I suppose if you count the specification).

Based on that I'm not entirely sure what to recommend. Everyone resetting to the pre-HTML51-inspired mess seems ideal, but perhaps a good middle ground would be to accept the parsing changes per Chromium and Gecko, and not adopt the styling changes per non-Gecko.

[nox]

This looks like an unintended bug in the WebKit commit:

(WebCore::hasImpliedEndTag): the spec says rb and rtc have implied end tags.
(WebCore::HTMLTreeBuilder::processStartTagForInBody): rb and rtc added. rt excludes rtc from its implied end tags.

Nowhere the message indicates that rp should change behaviour. Never mind, that's why rp did not change behaviour.

[domenic]

I managed to get my hands on an Edge-having computer and confirmed they do not have any special parsing behavior. So regarding the parser, we have four separate behaviors for the four separate rendering engines:

1. Edge, HTML Standard: no special treatment. rb and rtc map to HTMLUnknownElement.
2. WebKit, Gecko, W3C HTML 5.1: rb and rtc get implied end tags and map to HTMLElement
3. WebKit, W3C HTML 5.0: like (2) except rp causes an implied end tag for rtc
4. Blink: like (2) except rb and rtc map to HTMLUnknownElement

@annevk has been trying to find the reasoning for the change between 5.0 and 5.1 (i.e. between (2) and (3)), without success.

Regarding styling, only Gecko has UA style rules for rb and rtc. So we will probably remove those regardless.

How are we going to achieve compatibility? What should we specify?

To me the front-runners seem to be (1) and (2).

(1) would require Gecko, WebKit and Blink to remove their parser changes. It is attractive in its simplicity.

(2) would require Edge to implement the parser changes, and WebKit to change their parser, and Blink to update their mapping to use HTMLElement.

Can implementers comment? Do either of those two options sound good to you? Tagging in some possibilities: @travisleithead from Edge, @rniwa from WebKit, @kojiishi from Blink, and @hsivonen from Gecko.

[travisleithead]

I know Robin Berjon spent some time designing the W3C HTML5.1 model, and since he has better insight into the Ruby community than I, I figured it must be "better". So, I endorse that model ((2) above). The Edge browser has not updated our parser to reflect the W3C HTML5.1 model yet, but we are not opposed to doing so if it helps interoperability.

[rniwa]

I don't have a strong opinion for rtc since it's a new element but supporting rb in the parser is very important for compatibility reasons since a lot of Japanese websites do use them.

[kojiishi]

@nox:

This looks like an unintended bug in the WebKit commit:

Sorry slow to catch up, but yes. Actually, we found the spec issue after WebKit patch landed, so Gecko/Blink did in one patch, while WebKit needed two patches.

[kojiishi]

Blink to update their mapping to use HTMLElement.

Elliot already mentioned this is just a bug, I can fix it for Blink.

WebKit, W3C HTML 5.0: like (2) except rp causes an implied end tag for rtc

As @nox indicated in the following comments, my understanding is that WebKit is now interoperable with Gecko.

[nox]

@kojiishi I don't know where I said that they are interoperable. :)

[kojiishi]

@nox:

I don't know where I said that they are interoperable. :)

Sorry, I re-read your comment and, yes, you only said "unintended bug" but didn't say it was fixed later.

The mentioned unintended bug was fixed in this WebKit commit.

[domenic]

I did just test on my iPad and <rtc><rp> results in a child. So WebKit is in (2) already, good.

It sounds like there is a pretty clear trend toward (2). Edge and Blink are willing to change. So yay, let's do that.

We can deal with styling separately (#121). Assigning back to @annevk to update this PR to use HTMLElement instead of HTMLUnknownElement and remove the styling changes for now.

[domenic]

nooope, I forgot to test <ruby><rtc><rp>; I just tested <rtc><rp>. Awesome. WebKit does differ and is in a separate (3) category.

[rniwa]

We can fix our behavior to match (2) for rtc. Like I said earlier, rtc isn't that important for compatibility as long as rb is supported.

[domenic]

So this LGTM. However, we do need to add definitions of rb and rtc to the elements section. At the very least we need to say that they use HTMLElement. I will leave it up to you @annevk to decide whether it is OK to merge the parser changes without that. I am not so sure it is though.

[annevk]

They are defined as obsolete elements. See line 111990. And from line 113398 you can see I made sure rb no longer maps to HTMLUnknownElement.

[domenic]

Ah OK, I wasn't sure that obsolete elements didn't get their own element definition sections, but upon checking now I see that. Cool. Merging!

[domenic]

Due to some local git snafus the commit got un-associated with this PR. For posterity, it landed as 8d1c8af.

[kojiishi]

PR to fix interfaces for rb/rtc in web-platform-tests.