Attempt to make the motivation more persuasive

Review the draft's current motivation alongside the HTML Standard ruby model and the paired ruby examples in this issue. Examine the listed visual, aural, searching, braille, and authoring scenarios, including the SSML case; done means the motivation clearly demonstrates fundamental flaws and explains how the proposed elements address them.

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.