#959: Requesting review of HTML Ruby Markup Extensions
Discussions
2024-08-26
I suspect we have nothing useful to say about https://github.com/w3ctag/design-reviews/issues/959, the Ruby extensions. I'm uncomfortable with this group of elements that is only useful for east-Asian text and isn't designed to represent any other kind of explanation of how to read confusing text (e.g. https://github.com/w3c/tpac2023-breakouts/issues/71), but I think saying that as the TAG is just going to frustrate people. So I suggest we decline the review.
we agree to fast track close it as decline
.
OpenedMay 31, 2024
こんにちは TAG-さん!
I'm requesting a TAG review of HTML Ruby Markup Extensions.
Ruby, a form of interlinear annotation, are short runs of text alongside the base text. They are typically used in East Asian documents to indicate pronunciation or to provide a short annotation.
This specification revises and extends the markup model established by HTML to express ruby.
Explainer: The spec is intended to contain its own explainer. Specifically:
Also, The i18n group has produced a variety of articles about ruby and its needs over the years, in line with what this spec is defining. https://www.w3.org/International/articles/ruby/markup.en is particularly relevant, but there are more if desired.
Further, this somewhat old but still relevant blog post covers the why and the what of this design quite extensively: https://fantasai.inkedblade.net/weblog/2011/ruby/
Specification URL: https://www.w3.org/TR/html-ruby-extensions/
Tests:
User research: (or rather, conclusions based on it)
Security and Privacy self-review: https://github.com/w3c/html-ruby/issues/12 See also the a11y self review: https://github.com/w3c/html-ruby/issues/13 and the i18n self review: https://github.com/w3c/html-ruby/issues/14
GitHub repo: https://github.com/w3c/html-ruby
Primary contacts (and their relationship to the specification):
Organization(s)/project(s) driving the specification: the i18n Working Group and Interest Group and their language enablement project, Japanese Electronic Publishing association, me (as an individual)
Key pieces of existing multi-stakeholder (e.g. developers, implementers, civil society) support, review or discussion of this specification: The ideas behind this spec have been extensively socialized and discussed over many years with the Japanese community, and to a lesser extent, with the Chinese comunity, partly through the i18n WG and IG and their taskforces, partly through various independent venues. Much of the discussion is not in English though. Can spend some time documenting it if necessary.
Key pieces of multi-implementer support:
<rb>
and the corresponding CSS display value in https://groups.google.com/a/chromium.org/g/blink-dev/c/UpHRuge9SfQ, but postponed. A lack of spec was a factor in deciding not to ship it at the moment, which this project aims to fix.<rb>
and<rtc>
in the way described by this specification for many years.<rb>
as defined in this specification (See https://github.com/whatwg/html/issues/1771#issuecomment-797769743)<rb>
(though the implementation does not appear very robust about dealing with implied<rb>
(as described in https://w3c.github.io/html-ruby/#rb-ex)External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
Further details:
You should also know that since this spec un-obsoletes
<rb>
and<rtc>
, https://github.com/w3c/html-aam/pull/253, which removed them from HTML accessibility mappings when they were obsoleted, would need to be reverted.