HTML Ruby Markup Extensions

W3C Working Draft,

More details about this document
This version:
https://www.w3.org/TR/2024/WD-html-ruby-extensions-20240507/
Latest published version:
https://www.w3.org/TR/html-ruby-extensions/
Editor's Draft:
https://w3c.github.io/html-ruby/
Previous Versions:
History:
https://www.w3.org/standards/history/html-ruby-extensions/
Feedback:
GitHub
Editor:
Florian Rivoal (Invited Expert)

Abstract

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.

Status of this document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document was published by the HTML Working Group as a Working Draft using the Recommendation track.

Publication as a Working Draft does not imply endorsement by W3C and its Members.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document is governed by the 03 November 2023 W3C Process Document.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is developed under the terms of the Agreement on HTML Ruby Markup between W3C and the WHATWG.

1. Introduction

This section is non-normative

Ruby is a name for small annotations that are rendered alongside base text. This is especially useful for Japanese and other East Asian content (ruby may be called furigana in Japanese). It is most often used to provide a reading (pronunciation guide).

Ruby text is usually presented alongside the base text, using a smaller typeface. The name ruby originated from a named font size (about half the size of the normal 10 point font) used by British typesetters.

Typically ruby is used in East Asian scripts to provide phonetic transcriptions of obscure and little known characters, characters that the reader is not expected to be familiar with (such as children or foreigners learning to write), or characters that have multiple readings which can’t be determined by the context (eg. some Japanese names). For example it is widely used in educational materials and children’s texts. It is also occasionally used to convey information about the meaning of ideographic characters.

An example of annotating text with ruby:
				the Japanese word for bullet-train is written with 3 kanji characters,
				written horizontally, left to right.
				Their pronunciation is indicated by 6 hiragana characters
				placed immediately above.
				The annotation is half the font size of the base it annotates.

Specialized markup, as defined in this document, is necessary to describe the semantic associations between the base text and its annotations, to enable its various visual layouts as well as correct non-visual presentation and processing.

Note: CSS Ruby Annotation Layout Module Level 1 defines the ruby layout model in CSS, enabling the ruby presentation described above and frequently desired variations.

1.1. Background and Relation to the HTML Standard

A set of HTML elements to markup ruby has evolved over the years in multiple specifications, starting from the 2001 Ruby Annotation specification all the way to the current HTML Standard, with different incarnations varying in flexibility, complexity, or verbosity.

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.

This specification is written to promote—​and guide implementations of—​an revised and extended model for ruby, in order to more completely address the needs of ruby on the Web platform. This effort is undertaken with the agreement of W3C and the WHATWG.

Appendix B: Comparison With The HTML Standard summarizes the main differences, and provides a brief overview of why these differences are desirable.

Note that the semantics of the subset of the HTML Standard that is interoperably implemented remain unchanged in this extension specification, making the ruby model described here backwards compatible with any ruby content supported by existing user agents.

In this document, advisement blocks like this one indicate how normative parts of the document relate to and replace various part of the HTML Standard.

It is hoped that the changes described here will in time be adopted by the WHATWG and integrated into the HTML Standard, reducing the delta between the two documents.

2. HTML Elements for Ruby

This section and it subsections replace and extendent sections HTML § 4.5.10 The ruby element through HTML § 4.5.12 The rp element of the HTML Standard.

2.1. The ruby element

Categories:
Flow content.
Phrasing content.
Palpable content.
Contexts in which this element can be used:
Where phrasing content is expected.
Content model:
See prose.
Content attributes:
Global attributes
Accessibility considerations:
For authors.
For implementers.
DOM interface:
Uses HTMLElement.

The ruby element represents one or more ranges of phrasing content paired with associated ruby annotations. Ruby annotations are short runs of annotation text presented alongside base text. Although primarily used in East Asian typography as a guide for pronunciation, they can also be used for other associated information. Ruby is most commonly presented as interlinear annotations, although other presentations are also used. A more complete introduction to ruby and its rendering can be found in W3C’s What is ruby? article and in CSS Ruby Annotation Layout Module Level 1.

This example shows Japanese text, with ruby markup used to annotate the ideographs with their pronunciation.
<ruby><rt>きり</rt></ruby>とも<ruby><rt>かすみ</rt></ruby>とも

A typical rendering would be something akin to the following image:

A short piece of horizontal Japanese text,
					with the reading of each kanji character
					indicated by small hiragana characters above it.
					Each group of hiragana is horizontally centered
					relative to the kanji it annotates.

The content model of ruby elements consists of one or more of the following ruby segment sequences:

  1. One or more phrasing content nodes or rb elements (or a combination) representing the base-level content being annotated (the ruby base range).
  2. One or more rt or rtc elements (or a combination) representing any annotations associated with the preceding base content, where each rtc element or sequence of rt elements represents one independent level of annotation (a ruby annotation range). Each annotation range, and annotation units within each range, and can optionally be preceded by / followed by / interleaved with individual rp elements. (The optional rp element can be used to add presentational content such as parentheses, which can be useful when rendering annotations inline, including as a fallback when ruby layout is not supported.)

Note: For authoring convenience, the internal ruby elements rb, rt, rtc, and rp have optional end tags.

In Taiwan, phonetic annotations for Chinese text are typically provided using Zhuyin characters (also known as Bopomofo). In mainland China, phonetic annotations are typically provided using Latin characters using Pinyin transcription. In this example, both are provided:
“Beautiful” in Chinese,
					with both pinyin and bopomofo annotations.
<ruby lang=zh-TW>
  <rb></rb><rtc><rt>ㄇㄟˇ</rt></rtc><rtc lang=zh-Latn><rt>měi</rt></rtc>
</ruby>

Certain features of HTML ruby allow for simpler markup:

In effect, the above example is equivalent (in meaning, though not in the DOM it produces) to the following:

<ruby lang=zh-TW><rt>ㄇㄟˇ<rtc lang=zh-Latn>měi
</ruby>

Note: The CSS Ruby Annotation Layout Module Level 1 enables authors to control the rendering of the HTML ruby element and its contents, supporting a variety of layouts based on the same markup.

Three rendering styles are commonly used with Zhuyin (Bopomofo) characters. (Annotations here are shown in blue for clarity, though in actual uses there would be no color distinction.)

When the text is written vertically, the phonetic annotations are rendered to the right, along the base text:

A Chinese word composed of two characters, written vertically.
					To the right of each character,
					phonetic annotations appear,
					written vertically.

In horizontal writing, they are frequently also typeset to the right, in this case sandwiched between individual base characters:

A Chinese word composed of two characters,
					written horizontally.
					To the right of each character,
					phonetic annotations appear,
					written vertically.

However, sometimes Zhuyin annotations are instead typeset above horizontal base text:

A Chinese word composed of two characters,
					written horizontally.
					Above each character,
					phonetic annotations appear,
					written horizontally.

These differences are stylistic, not semantic, and therefore share the same markup:

<ruby lang=zh-TW>
  <rb><rb><rt>ㄉㄧㄢˋ<rt>ㄋㄠˇ
</ruby>

2.1.1. Ruby Segmentation and Pairing

Within a ruby element, content is parcelled into a series of ruby segments. Ignoring inter-element whitespace and rp elements, each ruby segment consists of:

Annotating text character by character is also typical in Chinese. In this example, each character is individually annotated in its own ruby element:

<ruby><rt>qiān</ruby><ruby><rt></ruby><ruby><rt>zhī</ruby><ruby><rt>xíng</ruby><ruby><rt>shǐ</ruby><ruby><rt></ruby><ruby><rt></ruby><ruby><rt>xià</ruby>

A Chinese phrase,
				with each character phonetically annotated with a pinyin syllable

Multiple adjacent ruby segments can also be combined into the same ruby parent:

<ruby><rt>qiān</rt><rt></rt><rt>zhī</rt><rt>xíng</ruby><ruby><rt>shǐ</rt><rt></rt><rt></rt><rt>xià</ruby>

The process of annotation pairing associates ruby annotation units with ruby base units. Within each ruby segment, each ruby base unit is paired with a ruby annotation unit from each ruby annotation range. If a ruby annotation range consists of an rtc element that contains no rt elements, the single ruby annotation unit represented by its contents spans (is paired with) every ruby base unit in the ruby segment. Otherwise, each ruby annotation unit in the ruby annotation range is paired, in order, with the corresponding ruby base unit in the segment’s ruby base range. If there are not enough ruby base units, any remaining ruby annotation units are assumed to be associated with empty, hypothetical bases inserted at the end of the ruby base range. If there are not enough ruby annotation units in a ruby annotation range, the remaining ruby base units are assumed to not have an annotation from that annotation level.

In some contexts, for example when the font size or line height are too small for interlinear ruby to be readable, it is desirable to inline the ruby annotation such that it appears in parentheses after the text it annotates. This also provides an appropriate fallback rendering for user agents that do not support ruby layout.

However, for compound words in Japanese particularly, per-character inlined phonetics are awkward. Instead, the more natural rendering is to place the annotation of an entire word together after its base text. For example, when typeset inline, 京都市 (“Kyoto City”) is expected to be rendered as “京都市(きょうとし)”, not “京(きょう)都(と)市(し)”. This can be marked up using consecutive rb elements followed by consecutive rt elements:

<ruby><rb><rb><rb><rt>きょう<rt><rt></ruby>

If each base character was immediately followed by its annotation in the markup (each base-annotation pair forming its own segment), inlining would result in the undesirable and awkward “京(きょう)都(と)市(し)”.

Note that the markup above does not automatically provide the parentheses. Parentheses can be inserted using CSS generated content when intentionally typesetting inline, however they would be missing when a UA that does not support ruby falls back to inline layout automatically from interlinear layout. The rp element can be inserted to provide the appropriate punctuation for when ruby is not supported:

<ruby><rb><rb><rb><rp><rt>きょう<rt><rt><rp></ruby>

2.1.2. Markup Patterns for Multi-Character Ruby

This section is non-normative

In the simplest examples, each ruby base unit contains only a single character, a pattern often used for character-per-character phonetic annotations. However, ruby base units are not restricted to containing a single character. In some cases it may be impossible to map an annotation to the base characters individually, and the annotation may need to jointly apply to a group of characters.

For example, the Japanese word for “today” is written with the characters 今日, literally “this”+“day”. But it’s pronounced きょう (kyō), which can’t be broken down into a “this” part and a “day” part.

Therefore phonetic ruby indicating the reading of 今日 would be marked up as follows:

<ruby>今日<rt>きょう</ruby>
“きょう” annotating “今日”
Ruby can also be used to describe the meaning of the base text, rather than (or in addition to) the pronunciation. In such cases, both the base text and the annotation are typically made of multiple characters, with no meaningful subdivision possible.

Here a compound ideographic word has an English-derived synonym (written in katakana) given as an annotation:

<ruby>境界面<rt>インターフェース</ruby>
“インターフェース” annotating “境界面”

Here a compound ideographic word has its English equivalent directly provided as an annotation:

<ruby lang="ja">編集者<rt lang="en">editor</ruby>
“editor” annotating “編集者”

In compound words, although phonetic annotations might correspond to individual characters, they are sometimes nonetheless typeset to share space above the base text, rendering similar to annotations on multi-character bases. However, there are subtle distinctions in their rendering that require encoding the pairing relationships within the compound word as well as its identification as a word. Furthermore, sharing space in this way versus rendering each pair in its own visual “column” is a stylistic preference: the markup needs to provide enough information to allow for both renderings (as well as correct inlining).

In this example, we will use the Japanese noun “京都市”, meaning “Kyoto City”. Its characters are pronounced “きょう”, “と”, and “し”, respectively. (Distinct colors shown in these examples for clarity: in actual usage there would be no color distinction.)

Such compound words could be rendered with phonetic annotations placed over each character one by one. In this style, when an annotation is visually longer than the character it annotates, surrounding text is pushed apart, to make the correspondance between each character and its annotation clear.

“Kyoto City” written in horizontal Japanese,
					with phonetic annotations over each of the three characters.
					The first and second character are pushed apart from each other,
					as the annotation over the first one is too long to fit.

However, it is common to present such a word with its annotations sharing space together when they would otherwise create a separation in the base text, to preserve the implication that it is a single word. This style is called “jukugo ruby” (“jukugo” meaning “compound word”).

“Kyoto City” written in horizontal Japanese,
					with phonetic annotations over the word.
					The characters of each annotation are not alligned
					to their corresponding base,
					instead they are collectively aligned to the whole word.

Even when presenting as “jukugo ruby“ though, the annotation are not always merged. If a line break occurs in the middle of the word, the annotations are expected to remain associated with the correct base character.

“Kyoto City” written in horizontal Japanese,
					broken across two lines.
					The phonetic annotations displayed over the word
					are paired with each base character,
					and line break together.

Whether—and how much—the annotations are merged can vary, and can depend on the font size, as “jukugo ruby“ only merges annotations when at least one of them is longer than its base.

“Kyoto City” written in horizontal Japanese,
					with phonetic annotations over each of the three characters.
					At 33% of the base font size,
					annotations are small enough to fit their base character,
					and are aligned to it.
Ruby sized at 33%
“Kyoto City” written in horizontal Japanese,
					with phonetic annotations over each of the three characters.
					At 50% of the base font size,
					the first annotation doesn't fit over its base character,
					so it merges with the second one.
					The third remains separate.
Ruby sized at 50%
“Kyoto City” written in horizontal Japanese,
					with phonetic annotations over each of the three characters.
					At 60% of the base font size,
					the first annotation doesn't fit over the first character,
					nor do the first and second together fit over the first two characters.
					All three are merged and aligned together.
Ruby sized at 60%

Since choosing to render as “jukugo ruby” or not is a stylistic choice, the same markup needs to enable both—​and it needs to encode both the pairing information within the word as well as the grouping of these pairs as a single word:

<ruby><rb><rb><rb><rt>きょう<rt><rt></ruby>

Correct “jukugo ruby” is not be possible if all the base characters are part of a single rb element and all the annotation text in a single rt element, as their individual pairings would be lost.

Note: For more details on Japanese and Chinese ruby usage and rendering, see Requirements for Japanese Text Layout 日本語組版処理の要件(日本語版) (particularly Ruby and Emphasis Dots and Appendix F), Rules for Simple Placement of Japanese Ruby, and the section on Interlinear annotations of Requirements for Chinese Text Layout - 中文排版需求.

2.2. The rb element

Categories:
None.
Contexts in which this element can be used:
As a child of a ruby element.
Content model:
Phrasing content.
Content attributes:
Global attributes
DOM interface:
Uses HTMLElement.

An rb (“ruby base”) element that is the child of a ruby element represents a ruby base unit: a unitary component of base-level text annotated by any ruby annotation(s) to which it is paired.

An rb element that is not a child of a ruby element represents the same thing as its children.

When no rb element is used, the base is implied:
<ruby>base<rt>annotation</ruby>

The element can also be made explicit:

<ruby><rb>base<rt>annotation</ruby>

Both markup patterns have identical semantics. Explicit rb elements can be useful for styling, and are necessary when marking up consecutive bases to pair with consecutive annotations (for example, when representing a compound word; see 京都市 inlining and jukugo ruby examples above).

2.3. The rt element

Categories:
None.
Contexts in which this element can be used:
As a child of a ruby or of an rtc element.
Content model:
Phrasing content.
Content attributes:
Global attributes
Accessibility considerations:
For authors.
For implementers.
DOM interface:
Uses HTMLElement.

An rt (“ruby text”) element that is the child of a ruby element or of an rtc element that is itself the child of a ruby element represents a ruby annotation unit: a unitary annotation of the ruby base unit to which it is paired.

An rt element that is not a child of a ruby element nor of an rtc element that is itself the child of a ruby element represents the same thing as its children.

2.4. The rtc element

Categories:
None.
Contexts in which this element can be used:
As a child of a ruby element.
Content model:
Either phrasing content or a sequence of rt elements; optionally preceded, interleaved with, or followed by individual rp elements.
Content attributes:
Global attributes
DOM interface:
Uses HTMLElement.

An rtc (“ruby text container”) element that is the child of a ruby element represents one level of annotation (a ruby annotation range) for the preceding sequence of ruby base units (its ruby base range).

Note: In simple cases, rtc elements can be omitted as a ruby annotation range is implied by consecutive rt elements. However, they are necessary in order to associate multiple levels of annotation with a single ruby base range, for example to provide both phonetic and semantic information, phonetic information in different scripts, or semantic information in different languages.

In this example, the Japanese compound word 上手 ("skillful") has phonetic annotations in both kana and romaji phonetics while at the same time maintaining the pairing to bases and annotation grouping information.
上手 (skill) annotated in both kana and romaji

This enabled by the following markup:

<ruby>
  <rb><rb><rt>じよう<rt><rtc><rt>jou<rt>zu
</ruby>

Note: Text that is a direct child of the rtc element implicitly represents a ruby annotation unit as if it were contained in an rt element, except that this annotation spans all the bases in the segment.

In this example, the Chinese word for San Francisco (旧金山, i.e. “old gold mountain”) is annotated both using pinyin to give the pronunciation, and with the original English.
San Francisco in Chinese,
					with both pinyin and the original English as annotations.

Which is marked up as follows:

<ruby>
  <rb><rb><rb><rt>jiù<rt>jīn<rt>shān
  <rtc>San Francisco
</ruby>

Here, a single base run of three base characters is annotated with three pinyin ruby text segments in a first (implicit) container, and an rtc element is introduced in order to provide a second single ruby annotation being the city’s English name.

An rtc element that is not a child of a ruby element represents the same thing as its children.

2.5. The rp element

Categories:
None.
Contexts in which this element can be used:
As a child of a ruby or rtc element, either immediately before or immediately after an rtc element or a ruby annotation unit.
Content model:
Text.
Content attributes:
Global attributes
Accessibility considerations:
For authors.
For implementers.
DOM interface:
Uses HTMLElement.

The rp (“ruby parenthetical”) element represents nothing. It is used to provide presentational content (such as parentheses) around ruby annotation units, to be shown when presenting ruby content inline, without using ruby-specific layout. This may happen when using a user agent that does not support ruby layout, or for stylistic reasons. In typical ruby layout, it is not displayed.

In this example, each ideograph in the text 漢字 is annotated with its phonetic reading. Furthermore, it uses rp so that in legacy user agents the readings are in parentheses:
...<ruby><rb><rp><rt>かん<rt><rp></ruby>...

In user agents that support ruby layout, the rendering ommit the parentheses, but in user agents that do not, the rendering would be:

...漢字(かんじ)...
Here a contrived example showing some symbols with names given in English and French using double-sided annotations, with rp elements as well:
<ruby>
  <rb><rp>: <rt>Heart<rp>, <rtc lang=fr>Cœur</rtc><rp>.</rp>
  <rb><rp>: <rt>Shamrock<rp>, <rtc lang=fr>Trèfle</rtc><rp>.</rp>
  <rb><rp>: <rt>Star<rp>, <rtc lang=fr>Étoile</rtc><rp>.</rp>
</ruby>

This would make the example render as follows in non-ruby-capable user agents:

♥: Heart, Cœur. ☘: Shamrock, Trèfle. ✶: Star, Étoile.

3. Optional Tags

This section extends the HTML § 13.1.2.4 Optional tags section of the HTML Standard, replacing the paragraphs of that section about rt and rp, and adding two more for rb and rtc.

An rb element’s end tag may be omitted if the rb element is immediately followed by an rb, rt, rtc or rp element, or if there is no more content in the parent element.

An rt element’s end tag may be omitted if the rt element is immediately followed by an rb, rt, rtc or rp element, or if there is no more content in the parent element.

An rtc element’s end tag may be omitted if the rtc element is immediately followed by an rb or rtc element, or if there is no more content in the parent element.

An rp element’s end tag may be omitted if the rp element is immediately followed by an rb, rt, rtc or rp element, or if there is no more content in the parent element.

4. Rendering

This section completes the HTML § 15.3 Non-replaced elements section of the HTML Standard, and in partcicular its HTML § 15.3.4 Phrasing content subsection, with the exception of the rp { display: none; } rule which belongs in the HTML § 15.3.1 Hidden elements subsection.

The following rules are added to the HTML user agent style sheet:

ruby { display: ruby; }
rb { display: ruby-base; white-space: nowrap; }
rbc { display: ruby-base-container; } /* For compatibility with XHTML-inspired markup */
rp { display: none; }
rt { display: ruby-text; }
rtc { display: ruby-text-container; }
ruby, rb, rbc, rt, rtc { unicode-bidi: isolate; }
rtc, rt {
  font-variant-east-asian: ruby;
  text-emphasis: none;
  white-space: nowrap;
  line-height: 1;
}
rtc, :not(rtc) > rt {
  font-size: 50%;
}
rtc:lang(zh-TW), :not(rtc) > rt:lang(zh-TW) {
    font-size: 30%;
  }

5. Conforming Features

Even though rb and rtc are included in the list of “entirely obsolete” elements which “must not be used by authors” in HTML § 16.2 Non-conforming features, this specification revokes this obsolete status, and deems these two elements fully conforming.

Appendix A: Editorial Tweaks to HTML

This section is non-normative

In complement to the normative statements made in the main body of this specification, this section details additional editorial changes that would be desirable to make to the HTML Standard in order to make it fully align it with what is covered here.

Conformance

Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Conformant Algorithms

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Implementers are encouraged to optimize.

Index

Terms defined by this specification

Terms defined by reference

References

Normative References

[CSS-RUBY-1]
Elika Etemad; et al. CSS Ruby Annotation Layout Module Level 1. 31 December 2022. WD. URL: https://www.w3.org/TR/css-ruby-1/
[HTML]
Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119

Informative References

[CLREQ]
Bobby Tung; et al. Requirements for Chinese Text Layout - 中文排版需求. 1 November 2023. NOTE. URL: https://www.w3.org/TR/clreq/
[CSS-DISPLAY-3]
Elika Etemad; Tab Atkins Jr.. CSS Display Module Level 3. 30 March 2023. CR. URL: https://www.w3.org/TR/css-display-3/
[JLREQ]
Hiroyuki Chiba; et al. Requirements for Japanese Text Layout 日本語組版処理の要件(日本語版). 11 August 2020. NOTE. URL: https://www.w3.org/TR/jlreq/
[QA-RUBY]
Richard Ishida. What is ruby?. URL: https://www.w3.org/International/questions/qa-ruby
[RUBY]
Marcin Sawicki; et al. Ruby Annotation. 31 May 2001. REC. URL: https://www.w3.org/TR/ruby/
[SIMPLE-RUBY]
Florian Rivoal; Atsushi Shimono; Richard Ishida. Rules for Simple Placement of Japanese Ruby. 9 June 2020. WD. URL: https://www.w3.org/TR/simple-ruby/
[UNIFIED-RUBY]
Elika J. Etemad. Towards a Unified Ruby Model. URL: https://fantasai.inkedblade.net/weblog/2011/ruby/