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.