rb and rtc element should be removed from the list of obsolete features

[upsuper]

W3C i18n wg has resolved to request W3C HTML spec to remove them from the obsolete feature list, and this request has been fulfilled there.

WHATWG's HTML spec should do the same thing, because those elements are useful for writing certain types of furigana. Also, there is at least one implementation (Gecko) which has support of them.

Also see discussion in #121.

cc @kojiishi @annevk

[annevk]

In order to remove them there they need a section on their semantics and processing model.

[kojiishi]

@annevk am I correct to understand that the issue is primarily editor resources, and if someone can try a PR to add the section, would you be fine to review/accept?

[annevk]

@kojiishi I suspect so, coupled with some examples as to why rb and rtc elements are necessary. It probably also requires a revamp of the current section on ruby as it recommends using nested ruby elements for the case where you could also use rtc elements.

[zcorpan]

https://lists.w3.org/Archives/Public/www-international/2016JulSep/0171.html @r12a said

richard: snuck in since html5 published
... due maybe to syncing with whatwg document
... says rb and rtc are non-conforming
... added in 5.1
... odd that it's non-conforming
... CSS folks plan to implement jukugo using table model
... and that needs rtc

It's not clear to me what needs rtc. Is it to support overhang in jukugo (https://www.w3.org/TR/jlreq/#principles_of_jukugoruby_distribution_2)?

cc @fantasai

[fantasai]

It is needed in double-sided ruby cases to support annotations that span multiple bases, and also to support cases where the breakdown is preferred to be per-word rather than per-syllable.
See http://fantasai.inkedblade.net/weblog/2011/ruby/#double

[domenic]

And my understanding of https://www.w3.org/Bugs/Public/show_bug.cgi?id=10830 is that rb is not necessary, but it's nicer than span since it auto-closes? Or does the double-sided ruby case necessitate both rb and rtc?

@fantasai, could you help me understand what an ideal rendering for double-sided ruby would be? Your link only gives two versions that it calls a hack ("Alternate styles of presenting both kana and romaji phonetics for 上手, “skill”."), but what would the rtc (and rb?) version render as instead?

We also need to be sure that whatever we encourage is actually supported by at least two engines and that other engines don't have objections going forward. That I guess is connected to #121. If no engines support rendering double-sided ruby then we should wait to add elements to support it until there are patches in flight.

[upsuper]

<rtc> is only necessary for double-sided ruby, but <rb> has its semantic uses.

For example, the word "振り仮名" (furigana) should be

<ruby>
  <rb>振<rb>り<rb>仮<rb>名
  <rt>ふ<rt>り<rt>が<rt>な
</ruby>

not

<ruby>
  振<rt>ふ</rt>
  り<rt></rt>
  仮<rt>が</rt>
  名<rt>な</rt>
</ruby>

so that it keeps the semantic of "振り仮名（ふりがな）" rather than "振（ふ）り仮（が）名（な）".

[domenic]

My understanding is that the semantics of

<ruby>
  振<rt>ふ</rt>
  り<rt></rt>
  仮<rt>が</rt>
  名<rt>な</rt>
</ruby>

are defined to be "振り仮名（ふりがな）". Why do you think they are "振（ふ）り仮（が）名（な）"?

[upsuper]

Really? Then where should <rp> be put?

Also making the document order different from its semantic order potentially adds complexity to browsers for supporting things like copy/paste, screen readers, as they may need to do some reordering internally. It also makes it harder for authors to style them.

For example, if you want to put ruby inline, with the <rb><rt> structure, you just need to specify display: inline to rb and rt. However, with the <rt>-only structure, you cannot do so without changing the document.

[fantasai]

<rb> is necessary for proper handling of inlined ruby display as well as for these double-sided cases (as @upsuper explains above).

It seems from your question that you're just skimming, since “Your link only gives two versions that calls it a hack” isn't, afaict, a sensical observation of the text in that section... I think you might want to actually read that through article from the top. It explains why the model in the W3C HTML and CSS specs differs from Hixie's WHATWG version, and so probably answers many of your questions here and in any related issues.

[domenic]

Hmm, I did read through the article from the top. That section says "HTML5 option 1" and "HTML5 option 2" are both "just a hack". It provides renderings for both of them.

Later in the article you propose (as part of a "Grand Unified Theory of Ruby Markup") a "Level 3: Double Ruby" solution. However, you don't show how the markup you propose there would be rendered differently from the two hacks. That is what I was asking about.

[fantasai]

It's just a hack because, while WHATWG markup can be provided to provide one or the other rendering, each option sacrifices structural information that should be there, providing one or the other arbitrarily based on the desired rendering. HTML is not a presentational markup language, it is a semantic one. It should provide the structural relationships that are necessary for the different styling options so that (among other things) the styling language can switch between them. In this case, it should be able to switch among mono ruby presentation, jukugo ruby presentation, and inline presentation. These are all stylistic variants whose appropriateness varies by the presentation context and does not depend on the content.

[domenic]

I see, I understand your opinion better now. Thanks.

[scottaohara]

Since the rb and rtc elements are presently obsolete in HTML, the current mappings should be removed from HTML AAM to be consistent with HTML AAM not specifying mappings for other obsolete elements or attributes.

That said, I do not want to remove these elements if there is a plan to add them back into the HTML specification in the not to distant future. If there is no plan in place right now, they could be always be re-inserted if these elements were to make their way back into the HTML spec.

I would appreciate any feedback on this. Thanks.

[r12a]

We are working on a plan to add them back to the spec.

[domenic]

The editors are not aware of the plan @r12a refers to. Our current stance (arrived at during discussions at last year's TPAC, which unfortunately don't seem to be recorded here) is that these elements will not be added until there is multi-implementer interest; currently they are only in Firefox with no signs of movement in other browsers. So I think it would be most appropriate to remove them from HTML AAM, at least until such movement appears.

[upsuper]

@kojiishi Does Chrome have interest in adding such support?

[domenic]

And to be clear, given the long history of non-support, what is needed is the strongly recommended parts of the working mode, notably

• The support from implementers should be of the form “we would like to implement this soon” and not just “this seems like a reasonable idea”.

• There should already be a prototype implementation or one being worked on side-by-side with the change to the standard.

[r12a]

The editors are not aware of the plan @r12a refers to. Our current stance (arrived at during discussions at last year's TPAC, which unfortunately don't seem to be recorded here) is that these elements will not be added until there is multi-implementer interest;

That's the plan i'm talking about.

Resource constraints have delayed the work, but we have recently been discussing how to overcome that problem and move forward, both for HTML and CSS.

• There should already be a prototype implementation or one being worked on side-by-side with the change to the standard.

That would be covered by the Firefox implementation, wouldn't it?

Btw, i have looked around but been unable to find minutes of the meeting at the previous TPAC. If anyone has a link to those, i'd be grateful if they could let me know where they are.

[domenic]

That's the plan i'm talking about.

Ah great!

That would be covered by the Firefox implementation, wouldn't it?

In this case we'd want to see a second one that meets this criteria, since there's been such a long state of only one implementation.

[kojiishi]

We're planning to work on ruby sometime next year. /cc @yosinch

[fantasai]

@domenic Why does Firefox's implementation not qualify as fulfilling “There should already be a prototype implementation or one being worked on side-by-side with the change to the standard.”?

[domenic]

I explained that in #1771 (comment)

[tabatkins]

Domenic isn't objecting to that; Firefox's impl clearly qualifies. He's saying that the currently referenced statements of Chrome's support don't meet the bar for support right now, so there's not a second implementor support. (Getting Chrome to re-up their commitment would qualify, it's just that a several-year-old comment that doesn't have further impl movement has expired.)

[domenic]

To be clear, what we're trying to avoid here is putting features in the spec that only have a single implementation for a long period of time. This has been a nightmare with <dialog> (which we should have removed long ago, but keep getting strung along with "a second implementation will ship any day now"). Given the history of this feature as often saying "we're interested" or even "we plan to work on this", but that not panning out, we need a higher bar.

A second implementation that is approved for shipping by the relevant project leads is the bar we're applying here, not "commitment" of the type that we've already seen 4.5 years ago and 1.5 years ago but has not panned out in practice.

[kojiishi]

@kojiishi still planning on updating ruby support in Chromium?

Sorry for slow reply. We did update ruby support in Chromium to LayoutNG last year, but unfortunately this one did not make it. At this moment, we do not have a plan to update ruby support in Chromium more.

[rniwa]

We do implement rb and rtc in WebKit. What is missing from WebKit to count as a second implementation?

[kojiishi]

We do implement rb and rtc in WebKit. What is missing from WebKit to count as a second implementation?

IIUC this is talking about supporting the first example of #1771 (comment).

Chromium does parse rb too.

[rniwa]

We do implement rb and rtc in WebKit. What is missing from WebKit to count as a second implementation?

IIUC this is talking about supporting the first example of #1771 (comment).

Chromium does parse rb too.

Ah, ok. That does sound like just a bug to me. Having said that, it's probably not necessarily critical to keep that behavior of rb given WebKit hasn't supported this for years, and as a result, there is probably very little epub/html content that depends upon it.

[r12a]

@rniwa What specifically sounds like a bug to you?

WebKit hasn't supported this for years, and as a result, there is probably very little epub/html content that depends upon it

If we're thinking about the same thing (?), the fact is that there is little epub/html content out there because Webkit and Blink have not gotten around to implementing this for years. (I hear plenty of people regularly expressing dissatisfaction about that situation.)

[rniwa]

@rniwa What specifically sounds like a bug to you?

I mean the fact we don't support multiple rt getting displayed atop the corresponding rb.

WebKit hasn't supported this for years, and as a result, there is probably very little epub/html content that depends upon it

If we're thinking about the same thing (?), the fact is that there is little epub/html content out there because Webkit and Blink have not gotten around to implementing this for years.

Sure, I get that. At the same time, I don't think there is much traction / appetite to fix that situation in WebKit / Blink at the moment. I don't think anyone will be opposed if anyone is interested in fixing this bug / behavior in WebKit to rectify that situation if any but the reality is that I don't think there is any active effort to improve the ruby support in WebKit at the moment, or I'm at least not aware of it even if we're interested in improving our support in the long term.

[r12a]

Thanks for clarifying @rniwa .

[stantonma]

Kindle's ePub implementation supports RB in both patterns below:

<ruby>東<rb>京<rt>とう<rt>きょう</ruby>
<ruby>東<rt>とう<rb>京<rt>きょう</ruby>

It does not support RTC.

[dhouck]

Even if Kindle and Firefox donʼt collectively count as multiple implementations for rb (which my understanding is they should, even if not for rtc I found something saying WHATWG does not consider Kindle relevant for this because itʼs not a browser), the current comment in the list of obsolete features is bad. It currently says

Providing the ruby base directly inside the ruby element or using nested ruby elements is sufficient.

This is patently untrue; if the spec isnʼt going to provide sufficient elements for marking up more complicated ruby, it should at least admit this. For example, it could say

Providing the ruby base directly inside the ruby element or using nested ruby elements is sufficient for some use cases, and the others are poorly supported by browsers so should be avoided.

This conveys the same information, without leaving anyone wondering “wait, then how do I handle this?” when left with a case that needs rb elements to work correctly.

[dhouck]

Sorry to double-post, but looking into this more I also found w3c/whatwg-coord#14, where the W3C and WHATWG spent a couple months deciding that W3C could publish a document based on #6478; has W3C written anything publicly about that yet? I canʼt find it but I could easily have missed something.

[frivoal]

has W3C written anything publicly about that yet? I canʼt find it but I could easily have missed something.

This work has been chartered into a W3C working group: https://www.w3.org/2022/06/html-wg-charter.html

Concrete work has not yet taken place because the person most likely to do it (me) has been temporarily swamped with other work. I hope to get to it soon.