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:
The spec has numerous examples. In particular, https://www.w3.org/TR/html-ruby-extensions/#ruby-compound is an author-centric non-normative section focused on illustrating both how you're supposed to use the markup patterns the spec defines and enables, and why you'd want to.
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.
Elika Etemad (@fantasai), Apple (long time contributor/driver of all things ruby in W3C)
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:
Chromium comments: No formal standards position requested yet. Chrome has considered implementing / shipping support for <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.
Mozilla comments: Firefox has supported both <rb> and <rtc> in the way described by this specification for many years.
WebKit comments: No formal standards position requested yet. Informally, support for working on this area has been expressed in principle, without commitment to prioritize. For example: https://github.com/whatwg/html/pull/6478#issuecomment-936955195. Additionally, there is explicit support (see https://github.com/WebKit/standards-positions/issues/232) for the corresponding css spec, which has many assumptions that match this extended model better than the one defined in the current HTML standard.
Relevant time constraints or deadlines: Reasonably fast response is of course appreciated, but there's no specific deadline. Significant changes are not anticipated before CR, and there exist some implementations, so absent new problematic feedback, we may be in a good shape for moving to and beyond CR before long.
The group where the work on this specification is currently being done: HTLMWG
The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): HTLMWG
Major unresolved issues with or opposition to this specification: None as such. It's worth noting that the WHATWG does not want themselves to work on this prior to there being 2 browsers on board, but has explicitly entered an agreement with W3C about this being worked on in this W3C Spec https://www.w3.org/2022/02/ruby-agreement
This work is being funded by: research into the problem and solution spaces have been done (and funded) by a variety of organizations over the years, many in the Japanese publishing community, with contributions from other industries as well, and numerous individual contributors. Contributions from the Chinese speaking world are significant too. Implementations or ruby markup in existing engines (notably Firefox and Amazon kindle, which support features covered in this spec) are not known to the editor to have funding external to these organizations. Recent spec work has been sponsored by the Japanese Electronic Publishing Association, but some of the work is self funded.
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.
こんにちは 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:
The spec has numerous examples. In particular, https://www.w3.org/TR/html-ruby-extensions/#ruby-compound is an author-centric non-normative section focused on illustrating both how you're supposed to use the markup patterns the spec defines and enables, and why you'd want to.
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.