Html: 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]

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