Repository navigation
Attempt to make the motivation more persuasive #44
Description
While concise and effective in simple cases, the ruby model described in the HTML Standard (at the time of writing this document) is insufficiently expressive to handle all use cases well. Moreover, some aspects of it are also not interoperably implemented; yet implementing them would not completely address the remaining use cases. Additionally, these aspects are at odds with the CSS layout model.
I am not convinced that this motivation is persuasive. Many people will likely think that if simple cases are covered in a concise and effective manner, the HTML Standard is already good enough. After all, no standard in the world covers all use cases perfectly.
Does the ruby model in the HTML Standard have any fundamental flaws even when used for simple cases? Only when such flaws are clearly demonstrated will the community reconsider the current model — however reluctantly.
In my humble opinion, this draft should begin by describing such fundamental flaws and then introduce annotation pairing as a remedy. In other words, why is
<ruby><rb>京<rb>都<rb>市<rt>きょう<rt>と<rt>し</ruby>
(or its variations)
far superior to
<ruby>京<rt>きょう</rt>都<rt>と</rt>市<rt>し</rt></ruby>
(or its variations)
?
We should enumerate flaws in different scenarios such as:
- Visual rendering -- Typical
- Visual rendering -- low-vision
- Visual rendering -- Learning disabilities including dyslexia
- Aural rendering or TTS
- Searching
- Conversion to braille
- Authoring
The editor is already aware of many such flaws. However, while drafting this comment, I noticed another.
Suppose that both the ruby base and the ruby annotation must be read aloud — for example, when the annotation represents GIKUN (義訓) rather than simple furigana. Further suppose that SSML is required for correct TTS of the base and/or annotation. Where would such SSML be specified?
I would prefer to use rbc and rtc for this purpose. However, the current HTML Standard provides no appropriate elements for embedding such SSML in a structured and interoperable manner.
Activity
frivoal commentedon Feb 27, 2026
Thanks for the feedback. I find it to be a delicate balance. The specification is mainly trying to explain how this works and how to use it, but it also attempt to justify why this is needed at all. It may be helpful to increase the emphasis / clarity of this later point, but we need to be careful that this does not come at the expense of the spec's main message. "Why other solutions are inappropriate" is rarely the focus of specs.
That said, suggestions of well scoped edits that make things clearer, including on that point, are welcome.
Interesting. I guess you're referring to something like the approaches covered in https://www.w3.org/TR/spoken-html/ ?
murata2makoto commentedon Feb 27, 2026
Or, https://www.w3.org/TR/epub-tts-10/
murata2makoto commentedon Mar 20, 2026
EPUB navigation documents can include HTML ruby markup. However, few major EPUB Reading Systems render ruby annotations correctly in the navigation pane. At least one EPUB reader, Thorium Reader from DAISY Consortium and EDRLab, displays ruby annotations as plain text when they appear in the navigation pane.
Using consecutive rb elements followed by consecutive rt elements may make such fallback rendering easier.
frivoal commentedon Jun 2, 2026
I think this is already discussed in https://www.w3.org/TR/2026/CR-html-ruby-extensions-20260604/#ruby-inlining
Similar to the example I just linked to above, I think many of the above, maybe all, are discussed in the spec. However, they are discussed piece by piece, as we explain various aspect of the feature, showing how to do it right. We don't have a single section listing in one place everything that's wrong with only using interleaved markup.
This is a question that arises often, so it is probably worth spending time on, but I wonder if an explainer/FAQ would be a better place to do that than the spec itself.
xfq commentedon Jun 3, 2026
Note that we also have https://www.w3.org/International/articles/ruby/markup.en.html and feedback is welcome.