HTML ルビマークアップ拡張

1. はじめに

この節は非規範的です

ルビとは、基底テキストに沿って レンダリングされる小さな注釈の総称です。 これは、特に日本語およびその他の東アジアのコンテンツで有用です （日本語ではルビを振り仮名と呼ぶことがあります）。 最も多く用いられるのは、読み方（発音の案内）を示す場合です。

ルビテキストは通常、基底テキストに沿って、 より小さな書体を使用して表示されます。 ルビという名称は、英国の植字工が使用していた 名称付きのフォントサイズ （通常の10ポイントフォントのおよそ半分のサイズ）に由来します。

通常、ルビは東アジアの文字体系で、 難解であまり知られていない文字、 読者がよく知っているとは想定されない文字 （文字を学習中の子供や外国人など）、 または文脈から判別できない複数の読み方を持つ文字 （例: 一部の日本人名） の発音表記を提供するために使用されます。 たとえば、教材や児童向けの文章で広く使用されていますが、 多くの種類の文学作品や標識でも容易に見られます。 また、表意文字の意味に関する情報を伝えるために使用されることもあります。

この文書で定義される専用のマークアップは、 基底テキストとその注釈との意味的な関連付けを記述し、 さまざまな視覚的レイアウトに加えて、 正しい非視覚的な提示および処理を可能にするために必要です。

注: CSSルビ注釈レイアウトモジュール レベル1はCSSにおけるルビレイアウトモデルを定義し、 前述のルビ表示および 頻繁に求められるそのバリエーションを可能にします。

1.1. 背景およびHTML標準との関係

ルビをマークアップするためのHTML要素群は、長年にわたり複数の仕様で発展してきました。 2001年のルビ注釈仕様から始まり、 現在のHTML標準に至るまで、 その各形態は柔軟性、複雑さ、または冗長性の点で異なっています。

簡単な場合には簡潔で効果的ですが、 HTML標準 （この文書の執筆時点）で説明されているルビモデルは、 すべてのユースケースを適切に処理するには表現力が不十分です。 さらに、その一部の側面は相互運用可能な形で実装されておらず、 それらを実装しても、残るユースケースに完全には対応できません。 また、これらの側面はCSSのレイアウトモデルとも矛盾します。

この仕様は、Webプラットフォーム上のルビのニーズに より完全に対応するため、 改訂および拡張されたルビモデルの普及と実装の指針を提供することを目的として 作成されています。 この取り組みは、W3Cと WHATWGの合意に基づいて行われています。

付録B: HTML標準との比較では、主な相違点を要約し、 それらの相違点が望ましい理由を簡単に概説しています。

相互運用可能な形で実装されているHTML標準の サブセットの意味論は、 この拡張仕様でも変更されないことに注意してください。 これにより、ここで説明するルビモデルは、 既存のユーザーエージェントが対応する あらゆるルビコンテンツとの 後方互換性を維持します。

ここで説明する変更が、将来的に WHATWGによって採用され、 HTML標準へ統合され、 2つの文書間の差異が縮小されることが期待されています。

2. ルビのためのHTML要素

2.1. ruby要素

カテゴリー:

フローコンテンツ。

フレージングコンテンツ。

知覚可能コンテンツ。

この要素を使用できるコンテキスト:

フレージングコンテンツが期待される場所。

コンテンツモデル:

本文を参照。

コンテンツ属性:

グローバル属性

アクセシビリティに関する考慮事項:

作者向け。

実装者向け。

DOMインターフェイス:

HTMLElementを使用します。

ruby 要素は、関連するルビ注釈と対になった1つ以上のフレージングコンテンツ範囲を 表します。 ルビ注釈は、基底テキストに沿って表示される短い注釈テキストです。 主に東アジアの組版で発音の案内として使用されますが、 その他の関連情報にも使用できます。 ルビは最も一般的には行間注釈として表示されますが、 その他の表示方法も使用されます。 ルビおよびそのレンダリングに関するより完全な紹介は、 W3Cのルビとは何か？という記事、 およびCSSルビ注釈レイアウトモジュール レベル 1にあります。

この例では、日本語のテキストについて、 表意文字に発音を付けるためにルビマークアップを使用しています。

<ruby><rb>霧</rb><rt>きり</rt></ruby>とも<ruby><rb>霞</rb><rt>かすみ</rt></ruby>とも

一般的なレンダリングは、次の画像のようになります:

注: 構文のバリエーションおよび簡略化については、 次の例を 参照してください。

ruby 要素のコンテンツモデルは、 次に示す1つ以上のルビ セグメントのシーケンスから構成されます:

1. 1つ以上のフレージングコンテンツノード、 またはrb 要素 （またはその組み合わせ）であり、 注釈対象となる基底レベルのコンテンツ （ルビ基底範囲）を 表します。
2. 1つ以上の rt要素または rtc 要素 （またはその組み合わせ）であり、 直前の基底コンテンツに関連する注釈を 表します。 各 rtc 要素または一連の rt 要素は、 1つの独立した注釈レベル （ルビ注釈範囲）を 表します。 各注釈 範囲、 および各範囲内の注釈 単位の前後または間には、任意で個別の rp 要素を配置できます。 （任意の rp 要素は、 丸括弧などの表示用コンテンツを追加するために使用できます。 これは、ルビレイアウトがサポートされていない場合のフォールバックを含め、 注釈を行内でレンダリングする際に有用です。）

注: 記述上の利便性のため、 内部ルビ要素 rb、 rt、 rtc、および rpには 省略可能な終了タグがあります。

台湾では、 中国語テキストの発音注釈は通常、 注音文字（ボポモフォとも呼ばれます）を使用して提供されます。 中国本土では、 発音注釈は通常、 ピンイン表記によるラテン文字を使用して提供されます。 この例では、その両方を提供しています:

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

HTMLルビの特定の機能を使用すると、マークアップを簡略化できます:

• 終了タグを省略できます。
• ruby 要素に直接含まれるテキストは、 暗黙的にルビ基底単位を表します （ rb 要素に含まれている場合と同様です）。
• ruby 要素の連続する rt 子要素は、 暗黙的にルビ注釈範囲としてグループ化されます （ rtc 要素に含まれている場合と同様です）。
• rtc 要素に直接含まれるテキストは、 暗黙的にルビ注釈単位を表します。

実質的に、 上記の例は （生成されるDOMは異なりますが、意味としては） 次の例と同等です:

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

注: CSSルビ注釈レイアウトモジュール レベル1により、作者はHTMLの ruby 要素およびその内容のレンダリングを制御でき、 同一のマークアップに基づくさまざまなレイアウトをサポートできます。

注音（ボポモフォ）文字では、一般的に3種類のレンダリング形式が使用されます。 （ここでは明確にするため注釈を青色で示していますが、 実際の使用では色の区別はありません。）

テキストを縦書きにする場合、 発音注釈は基底テキストに沿って 右側にレンダリングされます:

横書きの場合も通常は右側に組まれ、 この場合は個々の基底文字の間に挟まれます:

ただし、注音注釈が 横書きの基底テキストの上に組まれることもあります:

これらの相違は意味的なものではなく スタイル上のものであるため、 同じマークアップを共有します:

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

2.1.1. ルビの分割と対応付け

ルビ要素内では、 コンテンツは一連のルビセグメントに分割されます。 要素間空白および rp要素を 無視すると、 各ルビセグメントは 次のものから構成されます:

• 1つのルビ基底範囲: 0個以上のルビ基底単位。 各単位は、単一の子 rb 要素を含むDOM範囲、 または子 rb 要素を含まない子コンテンツの 最大DOM範囲のいずれかです。
• 0個以上のルビ注釈範囲。 各範囲は、単一の rtc 要素、または連続する rt 要素の最大シーケンスに対応するDOM範囲です。 ルビ 注釈範囲は、さらに 一連のルビ注釈単位へ分割されます: その範囲が一連の rt 要素から構成される場合、 各要素は個別のルビ注釈単位になります。 その範囲が rtc 要素から構成される場合、 その子 rt 要素のそれぞれと、 rtではない 子コンテンツの各最大DOM範囲が、 ルビ 注釈単位になります。

中国語では、テキストを1文字ずつ注釈することも一般的です。 この例では、 各文字に個別の ruby 要素で注釈を付けています:

<ruby>千<rt>qiān</ruby><ruby>里<rt>lǐ</ruby><ruby>之<rt>zhī</ruby><ruby>行<rt>xíng</ruby>﹐<ruby>始<rt>shǐ</ruby><ruby>於<rt>yú</ruby><ruby>足<rt>zú</ruby><ruby>下<rt>xià</ruby>

隣接する複数のルビセグメントを同じ ruby 親要素にまとめることもできます:

<ruby>千<rt>qiān</rt>里<rt>lǐ</rt>之<rt>zhī</rt>行<rt>xíng</ruby>﹐<ruby>始<rt>shǐ</rt>於<rt>yú</rt>足<rt>zú</rt>下<rt>xià</ruby>

注釈の 対応付けという処理は、ルビ注釈単位を ルビ基底単位と関連付けます。 各ルビセグメント内で、 各ルビ基底単位は、 各ルビ 注釈範囲のルビ注釈単位と 対応付けられます。 ルビ 注釈範囲が、 rtc要素から 構成され、その中に rt要素が 1つもない場合、 その内容が表す単一のルビ注釈単位は、 ルビセグメント内の すべてのルビ基底単位に またがります （対応付けられます）。 それ以外の場合、 ルビ注釈範囲内の各 ルビ注釈単位は、 順番に、 セグメントのルビ基底範囲内の対応する ルビ基底単位と 対応付けられます。 ルビ基底単位が不足している場合、 残りのルビ注釈単位は、 ルビ基底範囲の末尾に挿入された 空の仮想的な基底に関連付けられるものとみなされます。 ルビ 注釈範囲内のルビ注釈単位が不足している場合、 残りのルビ基底 単位は、 その注釈レベルからの注釈を持たないものとみなされます。

<ruby><rb>京<rb>都<rb>市<rt>きょう<rt>と<rt>し</ruby>

<ruby><rb>京<rb>都<rb>市<rp>（<rt>きょう<rt>と<rt>し<rp>）</ruby>

2.1.2. 複数文字ルビのマークアップパターン

この節は非規範的です

最も単純な例では、 各ルビ基底単位は 1文字だけを含みます。 これは、文字ごとの発音注釈でよく使用されるパターンです。 ただし、ルビ基底単位は、 1文字だけを含むように制限されていません。 場合によっては、 注釈を個々の基底文字へ対応付けることが不可能であり、 注釈を複数文字のグループへまとめて適用する必要があります。

たとえば、 日本語の「today」に相当する単語は「今日」という文字で書かれ、 文字どおりには「this」+「day」を意味します。 しかし、発音は「きょう」（kyō）であり、 「this」に対応する部分と 「day」に対応する部分へ 分解することはできません。

したがって、「今日」の読み方を示す発音ルビは 次のようにマークアップします:

<ruby>今日<rt>きょう</ruby>

ルビは、発音の代わりに （または発音に加えて） 基底テキストの意味を説明するためにも使用できます。 このような場合、 基底テキストと注釈は通常どちらも複数文字で構成され、 意味のある細分化はできません。

ここでは、複合表意文字の単語に、 英語由来の同義語 （カタカナで表記） を注釈として付けています:

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

ここでは、複合表意文字の単語に、 対応する英語を 直接注釈として付けています:

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

複合語では、 発音注釈が個々の文字に対応している場合でも、 複数文字の基底に対する注釈と同様に、 基底テキストの上の空間を共有するように組まれることがあります。 ただし、レンダリングには微妙な違いがあり、 複合語内の対応関係と、 それが1つの単語であることの両方を符号化する必要があります。 さらに、このように空間を共有するか、 各組を個別の視覚的な「列」にレンダリングするかはスタイル上の設定です。 マークアップは、両方のレンダリング （および正しい行内化） を可能にする十分な情報を提供する必要があります。

この例では、 日本の伝統的な語り物音楽の一種である、 日本語の名詞「浄瑠璃」（jōruri）を使用します。 各文字の発音は、それぞれ「じょう」、「る」、「り」です。 （明確にするため、この例では異なる色を使用しています。 実際の使用では色の区別はありません。）

このような複合語は、 各文字の上に発音注釈を1つずつ配置して レンダリングできます。 この形式では、 注釈が対象文字より視覚的に長い場合、 各文字とその注釈との対応関係を明確にするため、 周囲のテキストが押し広げられます。

ただし、 さまざまな組版の伝統では、 基底テキストが分離されることを避け、 1つの単語であることを保つため、 このような単語の注釈をまとめて空間を共有させることが一般的です。 この形式は「熟語ルビ」 （「熟語」は「compound word」を意味します） と呼ばれます。

ただし、「熟語ルビ」として表示する場合でも、 注釈が常に結合されるわけではありません。 単語の途中で改行が発生した場合、 注釈は正しい基底文字との関連付けを維持することが期待されます。

注釈を結合するかどうか、およびどの程度結合するかは異なる場合があり、 フォントサイズに依存することもあります。 次の図は、複数ある可能性のうち2つを示しています。 1つは、「熟語ルビ」が基底より幅広い注釈だけを 隣接する注釈と結合し、 必ずしもすべてを結合しない場合です。 もう1つは、「熟語ルビ」が、いずれかの注釈が基底より幅広くなった時点で すべての注釈を結合する場合です。 この仕様は特定のレイアウトを義務付けません。 これはCSSなどのスタイル技術の管轄です。

スタイル技術がどのレンダリングバリエーションを提供するかにかかわらず、 同じマークアップはあらゆる形式をサポートするのに十分な情報を含む必要があります。 「熟語ルビ」およびそのバリエーションとしてレンダリングするかどうかは、 スタイル上の選択だからです。 マークアップは、単語内の対応情報と、 それらの組が1つの単語としてグループ化されることの両方を符号化する必要があります:

<ruby><rb>浄<rb>瑠<rb>璃<rt>じょう<rt>る<rt>り</ruby>

すべての基底文字が単一の rb 要素に含まれ、 すべての注釈テキストが単一の rt 要素に含まれている場合、 個々の対応関係が失われるため、 正しい「熟語ルビ」は実現できません。

注: 日本語および中国語のルビの使用法と レンダリングについて詳しくは、 日本語組版処理の要件 日本語組版処理の要件(日本語版) （特に ルビと圏点 および付録F）、 日本語ルビの簡易配置規則、 および中国語組版処理の要件 - 中文排版需求の 行内注記および注釈の節を参照してください。

2.2. rb要素

カテゴリー:

なし。

この要素を使用できるコンテキスト:

ruby 要素の子として。

コンテンツモデル:

フレージングコンテンツ。

コンテンツ属性:

グローバル属性

DOMインターフェイス:

HTMLElementを使用します。

rb （「ルビ基底」）要素は、 ruby 要素の子である場合、 対応付けられたルビ注釈によって注釈される 基底レベルテキストの単一の構成要素である ルビ基底単位を 表します。

rb要素が ruby 要素の子でない場合、 その子と同じものを 表します。

<ruby>基底<rt>注釈</ruby>

<ruby><rb>基底<rt>注釈</ruby>

2.3. rt要素

カテゴリー:

なし。

この要素を使用できるコンテキスト:

ruby 要素または rtc 要素の子として。

コンテンツモデル:

フレージングコンテンツ。

コンテンツ属性:

グローバル属性

アクセシビリティに関する考慮事項:

作者向け。

実装者向け。

DOMインターフェイス:

HTMLElementを使用します。

rt（「ルビ テキスト」）要素は、 ruby 要素の子である場合、または それ自体が ruby 要素の子である rtc 要素の子である場合、 対応付けられたルビ基底単位に対する単一の注釈である ルビ注釈単位を 表します。

rt 要素が ruby 要素の子でも、 それ自体がruby要素の子である rtc 要素の子でもない場合、 その子と同じものを 表します。

2.4. rtc要素

カテゴリー:

なし。

この要素を使用できるコンテキスト:

ruby 要素の子として。

コンテンツモデル:

フレージングコンテンツ、または一連の rt 要素のいずれか。 任意で、その前、間、または後に個別の rp 要素を配置できます。

コンテンツ属性:

グローバル属性

DOMインターフェイス:

HTMLElementを使用します。

rtc （「ルビテキストコンテナー」）要素は、 ruby 要素の子である場合、 直前の一連のルビ基底単位 （そのルビ基底範囲）に対する 1つの注釈レベル （ルビ注釈 範囲）を 表します。

注: 単純な場合、 連続する rt要素によって ルビ 注釈範囲が暗黙的に示されるため、 rtc 要素を省略できます。 ただし、単一のルビ基底範囲へ 複数レベルの注釈を関連付けるためには必要です。 たとえば、発音情報と意味情報の両方、 異なる文字体系での発音情報、 または異なる言語での意味情報を提供する場合です。

この例では、 日本語の複合語「上手」（「skillful」）に、 かなとローマ字の両方による発音注釈を付けながら、 基底との対応関係および 注釈のグループ化情報を維持しています。

これは次のマークアップによって実現されます:

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

注: rtc 要素の直接の子であるテキストは、 rt要素に 含まれている場合と同様に、 暗黙的にルビ注釈単位を表します。 ただし、この注釈はセグメント内のすべての基底にまたがります。

この例では、サンフランシスコを表す中国語 （旧金山、すなわち「古い金の山」）に、 発音を示すピンインと、 元の英語の両方で注釈を付けています。

次のようにマークアップします:

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

ここでは、3文字からなる単一の基底の並びに、 最初の（暗黙的な）コンテナー内の 3つのピンインルビテキストセグメントで注釈を付け、 さらに都市の英語名である 2番目の単一ルビ注釈を提供するために、 rtc 要素を導入しています。

rtc 要素が ruby 要素の子でない場合、 その子と同じものを 表します。

2.5. rp要素

カテゴリー:

なし。

この要素を使用できるコンテキスト:

ruby 要素またはrtc 要素の子として、 rtc 要素またはルビ注釈単位の 直前または直後に配置できます。

コンテンツモデル:

テキスト。

コンテンツ属性:

グローバル属性

アクセシビリティに関する考慮事項:

作者向け。

実装者向け。

DOMインターフェイス:

HTMLElementを使用します。

rp （「ルビ括弧」）要素は何も 表しません。 これは、ルビ固有のレイアウトを使用せずに ルビコンテンツを行内で表示するときに示す、 ルビ 注釈単位の周囲の 表示用コンテンツ （丸括弧など） を提供するために使用されます。 これは、ルビレイアウトをサポートしていないユーザーエージェントを使用する場合や、 スタイル上の理由で発生することがあります。 通常のルビレイアウトでは、 表示されません。

...<ruby>漢<rb>字<rp>（<rt>かん<rt>じ<rp>）</ruby>...

...漢字（かんじ）...

<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>

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

3. 省略可能なタグ

rb 要素の終了タグは、 rb 要素の直後に rb、 rt、 rtc、または rp要素が 続く場合、あるいは親要素内にそれ以上のコンテンツがない場合に省略できます。

rt 要素の終了タグは、 rt 要素の直後に rb、 rt、 rtc、または rp要素が 続く場合、あるいは親要素内にそれ以上のコンテンツがない場合に省略できます。

rtc 要素の終了タグは、 rtc 要素の直後に rbまたは rtc 要素が続く場合、あるいは親要素内にそれ以上のコンテンツがない場合に省略できます。

rp 要素の終了タグは、 rp 要素の直後に rb、 rt、 rtc、または rp要素が 続く場合、あるいは親要素内にそれ以上のコンテンツがない場合に省略できます。

4. レンダリング

次の規則が HTML ユーザーエージェントスタイルシートへ追加されます:

ruby { display: ruby; }
rb { display: ruby-base; white-space: nowrap; }
rbc { display: ruby-base-container; } /* XHTMLに着想を得たマークアップとの互換性のため */
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. 適合機能

6. 操作

6.1. テキスト検索

この節は非規範的です

[HTML]は、 ページ内検索操作およびその一般的な仕組みを定義していますが、 クエリーから 一致を 判定する正確な方法は定義していません。 window.find() APIもさまざまなHTMLユーザーエージェントでサポートされていますが、 執筆時点では規範的な仕様がなく、 特定の検索文字列が文書内で一致するかどうかを 判定する具体的な方法も定義されていません。

したがって、この仕様は テキスト検索とルビとの相互作用について 規範的な動作を定義しようとはしません。 ただし、一般的なユーザーの期待をいくつか示すことができ、 ユーザーエージェントには、 このような機能を実装する際にそれらを考慮することが推奨されます。

• ユーザーは通常、ルビ注釈が存在することで 検索が妨げられるとは想定しません。 単語または句にルビ注釈が付いているかどうか、 またその注釈を挿入するためにどのマークアップパターンが使用されているかにかかわらず、 ユーザーは基底テキストを検索できることを期待します。 ユーザーは通常、使用されている具体的なマークアップパターンを認識していないため、 注釈が基底テキストのノード間に挟まれ、 クエリーテキストが文書内で連続して現れない場合にも同様です。
• 同様に、ルビ注釈がマークアップ内で 注釈対象の単語の後、別の単語の前に現れる場合、 ユーザーは通常、2つの単語の間に何かがあるとは認識せず、 その2つの単語から構成されるクエリー文字列で 一致を検索できることを期待します。
• 基底テキストに加えて、 ユーザーはルビ注釈内のテキストを検索することもあります。 この場合も、マークアップパターンはユーザーには不明であり、関係ありません。 ユーザーは通常、自分が単語または句と考えるものを、 テキストがマークアップ内で連続して現れるか、 ルビ基底と注釈がマークアップ内で交互に配置されているかにかかわらず、 検索できることを期待します。
• rp 要素は通常表示されないため、 ユーザーは、その存在が検索に影響しないことも期待します。

<ruby><rb>東<rb>京<rt>とう<rt>きょう</ruby>に行く。

<ruby><rb>東<rt>とう<rb>京<rt>きょう</ruby>に行く。

<ruby><rb>東<rb>京<rp>（<rt>とう<rt>きょう<rp>）</ruby>に行く。

注: テキスト検索の複雑さに関する 追加の考慮事項については、 [string-search]も参照してください。

6.2. コピー&ペースト

この節は非規範的です

Webプラットフォームは、 コピー&ペーストのクリップボード操作の詳細を正確には規定していません。 特に、クリップボードは通常、構造化テキストとプレーンテキストの両方をサポートしますが、 一方から他方へどのように変換するか、 またコピー時に文書の内容をどのようにクリップボードへ抽出するかは、 一般には定義されていません。

したがって、この仕様は クリップボードとルビとの相互作用について 規範的な動作を定義しようとはしません。 ただし、一般的なユーザーの期待をいくつか示すことができ、 ユーザーエージェントには、 このような機能を実装する際にそれらを考慮することが推奨されます。

• 注釈付きルビテキストを コピー&ペーストによってプレーンテキストへ変換する場合、 ユーザーエージェントは基底テキストだけを維持するか、 基底テキストと注釈テキストの両方を含めるか、 ルビ注釈を含めるかどうかをユーザーに選択させることができます。

  ルビ基底と注釈の両方をプレーンテキストのレンダリングに含める場合、 それらを線形化する必要があります。 このコンテキストでは、 通常は非表示の rp 要素をレンダリングすることが適切です。 HTML § 15.3.4 フレージングコンテンツで示される、 正しいルビレンダリングをサポートしないユーザーエージェントは、 rp 要素が存在しない場合、 rt 要素のテキストを丸括弧で囲んでレンダリングするという期待も、 このコンテキストに関連します。

  ユーザーが次のいずれかのテキスト断片を選択してコピーし、 textareaへ ペーストする場合を考えます:

  私の名前は<ruby><rb>網<rb>本<rt>あみ<rt>もと</ruby>
  

  私の名前は<ruby><rb>網<rb>本<rp>(<rt>あみ<rt>もと<rp>)</ruby>
  

  私の名前は網本または私の名前は網本(あみもと)の いずれも予想される結果です。 しかし、私の名前は網本あみもとは注釈を維持しているものの、 それが注釈であることを示さずに基底テキストと結合するため、 読者を混乱させる可能性があります。

• ユーザーは通常、選択できるものをコピーできることを期待します。 基底テキストまたは注釈テキストのいずれかを明示的に選択した場合、 コピー操作後にそれがクリップボードに含まれることが通常期待されます。 つまり、すべてのプレーンテキストのコピー&ペースト操作で すべての注釈を無条件に破棄するだけでは、 ユーザーの期待を満たせない可能性があります。

付録A: HTMLに対する編集上の調整

この節は非規範的です

この仕様の本文にある規範的な記述を補完するものとして、 この節では、 ここで扱われる内容と HTML標準を 完全に整合させるために望まれる 追加の編集上の変更について詳しく説明します。

• HTML § 15.3.4 フレージングコンテンツの次の段落にある、 ルビ基底のためのCSS匿名ボックス生成に関する 古い参考説明を削除します:

  CSSルビモデルの目的上、 ruby 要素の子のうち、 rt 要素でも rp 要素でもない連続部分は、 displayプロパティの値がruby-baseである匿名ボックスで 包まれることが期待されます。 [CSS-RUBY-1]

  この問題は、すでにCSSルビ注釈レイアウト1 § 2.2 匿名ルビボックスの生成で詳細に扱われています。

• HTML § 15.3.4 フレージングコンテンツの次の注記を置き換えます:

  注: これが可能になった時点で、 前述の要件はCSSルビの用語で表現するよう更新されます。 （現在、CSSルビは、ネストされた ruby 要素や、連続する複数の rt 要素を処理しません。 この意味論はこれらによって表現されます。）

  注: CSSでは、これは既定で 実現されます: ruby-positionプロパティの初期値は alternateであり、 この効果を生成します。

• HTML § 4.5.29 使用法の概要にある表の ruby、 rt、 rp の行を、 次の内容に置き換えます:

  要素	目的	例
  ruby, rb, rt, rtc, rp	ルビ注釈	<ruby>​<rb>​旧<rb>​金<rb>​山<rp>​ (<rt>​jiù<rt>​jīn<rt>​shān<rtc>​<rp>​: </rp>​San Francisco</rtc>​<rp>​)</ruby>

• HTML § 要素の表を更新して、 rbおよび rtcの 行を追加し、 rp、 rt、および rubyの 行を次のように置き換えます:

  要素	説明	カテゴリー	親†	子	属性	インターフェイス
  rb	ルビ基底	なし	ruby	フレージング	グローバル	HTMLElement
  rp	ルビ注釈テキストの丸括弧	なし	ruby; rtc	テキスト	グローバル	HTMLElement
  rt	ルビ注釈テキスト	なし	ruby; rtc	フレージング	グローバル	HTMLElement
  rtc	ルビ注釈コンテナー	なし	ruby	フレージング; rt; rp	グローバル	HTMLElement
  ruby	ルビ注釈	フロー; フレージング; 知覚可能	フレージング	フレージング; rb; rt; rtc; rp*	グローバル	HTMLElement

• HTML § 要素インターフェイスの表を更新して、 次の2行を追加します:

  要素	インターフェイス
  rb	HTMLElement
  rtc	HTMLElement

付録B: HTML標準との比較

この節は非規範的です

注: この比較は、 この文書の執筆時点における HTML標準の状態に基づいています。 HTML標準が ここで説明する変更の一部または全部を採用するか、 ルビの取り扱いを別の形で発展させた場合、 この節もそれに応じて更新されることが期待されますが、 更新までに遅延が生じる可能性があります。

この仕様は、以前に廃止された rbおよび rtc 要素を再導入しますが、 HTML § 13.2 HTML文書の 構文解析には変更を加えません。 これらの要素は、省略可能な終了タグを含め、 すでにそこで処理されています。

ただし、各種のルビ関連要素を使用する方法には相違があり、 主な相違点は次の2つです:

1. 匿名ルビ基底の間に rt 要素を挟み込む機能に加えて、 以前に廃止された rb 要素が復活し、 複数の連続する基底の後に それぞれに対応する注釈を配置する、 いわゆる表形式マークアップパターンが可能になります:

   <ruby>
     <rb>…<rb>…<rb>…
     <rt>…<rt>…<rt>…
   </ruby>
   

   rb および表形式マークアップが ない場合、 複合語におけるさまざまなルビ表示を正しく処理するために必要な 個々の基底と注釈の対応付けを実現するには、 基底テキストのセグメント間に rt 要素を挟み込む必要があります。 しかし、このようなマークアップでは正しいルビの行内化を 実現できません。

   さらに、注釈によって基底テキストが中断されるため、 交互配置のマークアップは、 コピー&ペースト、 文書内の検索、 または音声合成などの操作で問題の原因にもなります。 検索の場合、 ユーザーエージェントはこの問題を軽減できますが、 より単純なユーザーエージェントや 検索以外の操作では依然として問題になります。

2. この文書は、複数レベルの注釈を処理するための異なるモデルを定義します:
   • 明示的な注釈コンテナーを使用せずに、 連続する複数の rt 要素を直前の基底テキストセグメントへ関連付ける機能は削除されます。 このパターンには、HTML標準が意図する意味論で 相互運用可能な実装がなく、 表形式マークアップとも整合しません。

     代わりに、以前に廃止された rtc 要素が復活し、 交互配置または表形式マークアップのパターンを使用して、 同一の基底に複数の注釈範囲を示せるようになります。

   • ルビをネストする機能は維持されますが、 ネストされたルビに対する専用の意味論は削除されます。 このマークアップパターンは、 外側のルビ内の個々の注釈を 内側のルビ内の個々の基底と対応付けることができないため、 追加の注釈レベルに rtc を使用する場合より表現力が明確に低くなります。 したがって、「上手」に関する例は、 rtc を使用すれば実現できますが、 ネストされたルビでは実現できません。

     HTML標準で定義される ネストされたルビにも、 通常のネストの意味論を超える相互運用可能な実装はなく、 CSSルビ 注釈レイアウトモジュール レベル1のレイアウトモデルとも矛盾します。

fantasaiによる2011年のブログ投稿では、 これらの要件およびその結果となる設計上の選択について より詳しく説明しています。

付録C: セキュリティに関する考慮事項

この節は非規範的です

この仕様に既知のセキュリティ上の影響はありません。

付録D: プライバシーに関する考慮事項

この節は非規範的です

この仕様に既知のプライバシー上の影響はありません。

付録E: アクセシビリティに関する考慮事項

この節は非規範的です

ルビは主に発音の案内として使用されるため、 それ自体がアクセシビリティ指向の機能であり、 さまざまな読み書き能力を持つ読者が、 それ以外では読むことが困難または不可能な内容に アクセスできるようにします。 この用途では、ルビは、 読むことを学んでいる子供や非母語話者、 さまざまな学習障害またはその他の認知障害を持つ人、 恵まれない環境にあり教育機会が限られている人などに役立ちます…

この拡張仕様の主要な動機は、 ルビの用途の多様性、 ユーザーおよびそれに対応する期待の多様性を認識し、 利用可能なマークアップパターンが 多様な状況に対応するために必要な構造情報を 提供できるようにすることです。

ディスレクシアのある人は、同じ内容の異なる視覚的表示を 読みやすい、または読みにくいと感じることがあります。 さまざまなバリエーションの中で、 ルビ注釈を異なる色で表示すること、 注釈対象の文字から間隔を空けること、 または行内の括弧書きとして表示することを好む人もいます。 これにより、注釈対象のテキストとの区別が容易になります。 同様に、教育のコンテキストでの使用では、 さまざまな表示バリエーションが求められることがあります。 この仕様は視覚的レイアウトを直接扱いませんが、 ここで定義するマークアップパターンは、 作者がルビ注釈に関する適切な構造情報を表現できるよう 意図的に設計されています。 この情報をCSSなどのスタイル言語で使用することで、 マークアップを変更したり損なったりすることなく、 ユーザーのニーズや設定に対応する多様な表示を提供できます。 [CSS-RUBY-1]を参照してください。

視力が限られている人または視覚を持たない人は、 文書の代替または補完的な音声レンダリングを提供するために、 スクリーンリーダーなどのツールを利用することがよくあります。 HTMLルビマークアップおよび対応するテキスト読み上げの問題は、 この仕様より前から存在しており、 この仕様はそれらを導入することも解決することもありません。 この拡張仕様は、 ルビの異なる使用法では 異なる音声レンダリングが有益となる可能性を認識していますが、 問題の別の側面の進展に焦点を当てているため、 このニーズに対応する新しい仕組みを導入しません。 この重要な考慮事項は、今後の作業で扱われることが期待されます。 それまでの間、HTMLユーザーエージェントおよびスクリーンリーダーには、 最も有用なテキスト読み上げレンダリングを決定するために ヒューリスティックな方法を検討することが推奨されます。 （日本語における一般的なパターンおよびテキスト読み上げへの期待については、 [RUBY-TTS-REQ] を参照してください。）

付録F: 謝辞

この節は非規範的です

この文書は、複数の資料に由来しています （それらの資料も、ある程度は互いに由来しています）。 特に、次の資料のすべての貢献者に感謝します:

• HTML標準の多数の 編集者および 貢献者

• 以前のバージョンのW3C HTMLルビマークアップ 拡張の編集者、Robin Berjon

• ルビ注釈の編集者および 貢献者

さらに、 国際化ワーキング グループの参加者による 専門的な意見、 長年にわたる研究、 および広範な文書化がなければ、 これは実現できませんでした。 特に次の方々に感謝します:

• 日本語組版処理の要件 日本語組版処理の要件(日本語版)への多数の貢献者

• 中国語組版処理の要件 - 中文排版需求への多数の貢献者

• Richard Ishida

• Elika J. Etemad（別名fantasai）

付録F: 変更点

この節は非規範的です

2024年5月7日付ワーキングドラフト以降の変更点

2024年5月7日付 ワーキングドラフト以降の主な変更点:

• 非規範的な付録E: アクセシビリティに関する考慮事項の節を追加。

• 非規範的な§ 6 操作の節を追加。

• 例、注記、および導入文を明確にするためのさまざまな編集上の調整。

2014年2月4日付W3C HTMLルビマークアップ拡張ワーキンググループノート以降の変更点

ここで説明するマークアップモデルは、 2014年ワーキンググループノートで 確立されたモデルと実質的に同じですが、 その説明文および例は 大幅に改訂されています。

2014年ワーキンググループノートで提案された 構文解析の 変更は、 その後HTML標準に採用されたため、 ここでは取り上げません。

付録G: CR終了基準

この仕様が勧告案へ進むためには、 各機能について、少なくとも2つの 独立した、 相互運用可能な 実装が存在しなければなりません。 各機能は、 異なる製品群によって実装されてもよく、 すべての機能を単一の製品が実装する必要はありません。 この基準の目的上、 次の用語を定義します:

独立した

各実装は異なる主体によって開発されなければならず、 適格となる別の実装で使用されているコードを 共有、再利用、または派生させることはできません。 この仕様の実装に関係しないコード部分は、 この要件の対象外です。

相互運用可能な

公式テストスイート内の対応するテストケースに合格すること。

実装

次の条件を満たすユーザーエージェント:

1. 仕様を実装していること。
2. 一般の人々が利用可能であること。 実装は出荷済み製品、 またはその他の一般公開バージョン （すなわち、ベータ版、プレビューリリース、または「ナイトリービルド」） でかまいません。 出荷されていない製品リリースは、安定性を示すため、 少なくとも1か月間その機能を実装していなければなりません。
3. 実験的でないこと （すなわち、テストスイートに合格するためだけに特別に設計され、 今後の通常使用を意図していないバージョンではないこと）。

この仕様は、少なくとも28日間 勧告候補の状態にとどまります。