Level 2 features should be strongly recommended and levels 3 and 4 features should be marked as "at risk"

[murata2makoto]

Fantasai's blog article about ruby markup design is still very useful. In particular, it shows four possible levels: Level 1 (Simple Ruby), Level 2 (Multi-pair Word Ruby), Level 3 (Double Ruby) and Level 4 (Full Complex Ruby).

I think that level 2 features should be strongly recommended and levels 3 and 4 features should be marked as "at risk". Such a change make this extension work more relevant. In its current form, I am not sure if developers think this draft really relevant.

[frivoal]

"Level 1" is already supported by the HTML specification, without needing an extension.

"Level 2" is the most important addition of this extension specification.

"Level 4" with rbspan is not covered at all by this extension specification.

With regards to "Level 3" (i.e. support for the <rtc> element), this was discussed during TPAC with the i18n working group, and though I suggested marking it at risk, the i18n WG prefered not doing that, at least for the moment.

Based on the Process, at risk means that the specification may advance to REC even if this feature is not implemented, simply by dropping this feature without needing to republish a new CR. It is supposed to be a judgement about the maturity of implementations, not about whether the feature is a good idea. However, despite that definition, readers often think "at risk" means "we're not sure this is a good idea", and discourages implementers from looking taking it seriously. In particular, <rtc> fits into the same design, and Implementing Level 2+3 is likely not much different from implementing Level 2 alone.

Even though the i18n WG understands that multi-level ruby has a lower priority due to less usage, the group prefers avoiding sending a message that there is anything wrong with the design of the feature. Moreover, the existing HTML specification also covers two different approach to "Level 3", but one of them is incompatible with the model covered in this specification, and unlike the approach covered in this specification (which is supported in 1 browser), neither of those covered in the HTML specification are not supported in any browser. So it seems important to show the full picture, including this part of the design, so that any interested implementer sees how all parts fit together.

As implementations mature, and when we try to push this specification to Recommendation, we can always revisit this question, and possibly separate parts of this specification into different levels. But for now, the preference is too keep it all together, without any "scary" markings.

I hope this makes sense and is OK with you.