[44] CSS の auto-hiding は、 ルビ文字列と親文字列が一致するとき、 ルビ文字列を非表示にする機能です。

[45] つまり対応Webブラウザーで表示したときだけ、 特定条件でルビが消えてしまいます。

仕様書

処理

[10] CSS Ruby は、 親文字列とルビ文字列が同じとき、 ルビ文字列を非表示にすると定めています。 >>1

[2] Firefox は実装しています。 Chrome は実装していません。

[67] Firefox ではこの記事の一部が正しく表示されません。ご注意ください。

[68] 以下に示すとおり、 CSS Ruby の規定と Firefox の実装は違う点が多いです。

[5] 仕様書は、 要素を無視した textContent の比較で、 white-space や text-transform の適用前を使って同じかどうか判断するとしています。 >>1

[4] Firefox で試してみると、 子孫のテキストだけを見ていて、 子孫の要素構造は無視するようです。

テキストは U+0020 を1文字入れるだけでも違いが生じれば隠されません。

しかし script 要素の子孫は無視されます。

img 要素は alt 属性値に置き換えられて評価されます。

::after 疑似要素で content'content' を設定すると、それも評価に反映されるようです(!)。

display:none の子孫は無視されるようです(!)。 display:block など他の値は影響しないようです。

(innerText と同じ変換でしょうか。 仕様書の規定とはぜんぜん違う挙動です。)

[11] Firefox: text-transform は結果に影響しません (仕様書 >>1 通り)。 https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cruby%3EA%3Crt%3Ea%3C%2Fruby%3E%3Cruby%3EA%3Crt%20style%3D%22text-transform%3Auppercase%22%3Ea%3C%2Fruby%3E%3Cruby%3E%3Cb%20style%3D%22text-transform%3Alowercase%22%3EA%3C%2Fb%3E%3Crt%3Ea%3C%2Fruby%3E

[12] Firefox: white-space は結果に影響しません (仕様書 >>1 通り)。

[13] Firefox: visibility:hidden は結果に影響しません。

[14] Firefox: 入れ子の auto-hiding は結果に影響しません。 https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cruby%3EAB%3Crt%3EA%3Cruby%3EB%3Crt%3EB%3C%2Fruby%3E%3C%2Fruby%3E

[15] Firefox: br は特別扱いされません。

[20] Firefox: ol > li の marker は評価に影響しません。

[16] Firefox: 影木が評価に影響します (!!!)。

影木のテキストが評価に反映され、光木の子孫が無視される: https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cruby%3EAB%3Ca-b%3EC%3C%2Fa-b%3E%3Crt%3EABC%3C%2Fruby%3E%3Cscript%3Edocument.querySelector(%27a-b%27).attachShadow(%7Bmode%3A%22open%22%7D).appendChild(document.createTextNode(%27x%27))%3C%2Fscript%3E

影木の slot の順序に合わせて入れ替わって評価される: https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cruby%3EAB%3Ca-b%3E%3Cb%20slot%3D1%3EC%3C%2Fb%3E%3Cb%20slot%3D2%3ED%3C%2Fb%3E%3C%2Fa-b%3E%3Crt%3EABDC%3C%2Fruby%3E%3Cscript%3Evar%20f%3Ddocument.querySelector(%27a-b%27).attachShadow(%7Bmode%3A%22open%22%7D)%3B%0Af.appendChild(document.createElement(%27slot%27)).name%3D2%3B%0Af.appendChild(document.createElement(%27slot%27)).name%3D1%3B%0A%3C%2Fscript%3E

[17] Firefox:

details + summary は、 表示中か隠れているかによって違って評価されます。 summary の左にレンダリングされる「▶」は評価に影響しません。 https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cruby%3EA%3Cdetails%20open%3E%3Csummary%3E%3C%2Fsummary%3EB%3C%2Fdetails%3E%3Crt%3EAB%3C%2Fruby%3E%0A

summary なしの details は、 summary 相当の部分に (日本語の場合) 「詳細」と表示されますが、これも評価に影響します (インスペクターに出てきませんが、疑似要素か影木と同じ扱いなのでしょう)。 (「詳細」は lang 属性によっては変化しません。 利用者設定の言語によって変化するのでしょうか。) https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cruby%3EA%3Cdetails%20open%3EB%3C%2Fdetails%3E%3Crt%3EA%E8%A9%B3%E7%B4%B0B%3C%2Fruby%3E

[18] Firefox: object 要素はどう処理されるかによって評価方法が変化します。

<object data> に名前解決できないドメインの URL を指定すると、 読込中は何も表示されないので、子孫が無視されて評価されます。 fetch が失敗に終わると子孫が表示されるので、 子孫を考慮して再評価されます。 一瞬なので注意して観察: https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cruby%3EA%3Cobject%20data%3Dhttps%3A%2F%2Fbaddomain.test%2F%3EB%3C%2Fobject%3E%3Crt%3EAB%3C%2Fruby%3E (standby 属性には未対応。)

[19] Firefox: svg 要素内のレンダリングされる、されないが評価に影響します。

[21] Firefox: position:absolute や position:fixed の部分木は無視して評価されます(!)。 https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cruby%3EA%3Cb%20style%3D%22position%3Aabsolute%22%3EB%3C%2Fb%3E%3Crt%3EAB%3C%2Fruby%3E

[25] Firefox: contenteditable 内でも、 通常時と同じように表示されます。 カーソル位置は、 表示されていてもいなくても同じように変化します。 つまり表示されていないルビ文字列中のカーソル位置も保持されているので、 次へ次へとカーソル移動していると親文字列の次に見えないルビ文字列にうつり、 見えないまま次へ次へと進めていればいつかルビ付き文字列の次に進む、 という挙動になります。 ルビ文字列中のどこかわからない位置で何か入力すれば、 親文字列とルビ文字列が一致しなくなるので、 突如ルビ文字列が表示されます。 ルビ文字列内でかな漢字変換すると、 候補が変わるたびに一致したりしなかったりで、 表示されたりされなかったり変わります。

仕組みを知ってる人にとっては当然の挙動ですが、 こんなエディターは使い物になるのでしょうか? HTML も CSS も知らない一般人が使う CMS にルビ対応しました!と提供できる状態とは思えません。

[32] 「非表示」とはどういう状態か? https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%E2%96%A0%3Cbr%3E%5B%3Cruby%3EA%3Crt%3E%3Cspan%20style%3D%22display%3Ainline-block%3Bwidth%3A10em%3Bbackground%3Aurl(404)%22%3EA%3C%2Fspan%3E%3C%2Fruby%3E%5D%3Cscript%3E%0Avar%20e%3Ddocument.querySelector(%27rt%27)%3B%0Avar%20s%3DgetComputedStyle(e)%3B%0Adocument.write(s.display%2C%27%2C%27%2Cs.visibility)%3B%0A%3C%2Fscript%3E

Firefox は親文字列に対する圏点のレンダリングにおいて、 非表示の rt も存在するものとして圏点を配置します。

[50] Re: [css-text-decor] Emphasis marks and auto-hiding ruby annotation, Xidorn Quan, , , https://lists.w3.org/Archives/Public/www-style/2015Nov/0278.html

Firefox がそう実装した事情。

[55] 仕様書には auto-hiding であろうが空のルビ注釈 (ルビ文字列部分のこと) だろうが、 ルビと圏点があるときルビの外側に圏点を置く、 と定めて、親文字列の直上に圏点を置いた例図があります。 >>53 (例はレンダリング例だけなので、ルビ文字列が存在しないのか、 auto-hiding の結果なのか空のルビ注釈があるのか、 区別がつきません。)

この図を見せられると auto-hiding も含めて親文字列の直上に圏点が接するのが意図したレンダリングに思えますが、 よく読むと「外側」とだけ定められていて接することは求められておらず、 そう解釈する意図で書かれたもの >>54 のようです。 しかもその例は auto-hiding であるとも空のルビ注釈であるとも言っていないので、 auto-hiding の挙動例であるとも断言できない (auto-hiding も想定に含めて書かれているらしい >>54 のですが)。

[56] なんにせよ、仕様書だけからではそう読み取るのは至難の業とはいえ、 auto-hiding の場合とそうでない場合とで圏点のレンダリング位置が異なる実装は当然に認められる (がそうしなければならないともいえない) >>54 ようです。そして著者にそれを制御する手段は与えられておらず、 完全にWebブラウザー依存となります。

[57] あるいは、現状唯一の実装である Firefox の挙動を前提に、 圏点の位置を制御したい著者は auto-hiding を使うかルビにしないかを選択できる、 ともいえます。 (濫用でしかありませんが、他に手段がなければそうすることになるでしょう。)

[51] 世間一般でのルビと圏点の処理の具合はルビ参照。

[48] [css-ruby-1] Should auto-hide match use NFKC and/or strip white space? · Issue #5995 · w3c/csswg-drafts · GitHub, https://github.com/w3c/csswg-drafts/issues/5995

[46] 現時点で主要 Webブラウザーのうち唯一実装している Firefox が仕様書と全然違うこんな無茶苦茶な実装状況なのは困ったものです。 果たして仕様書通りの挙動は実装可能なのでしょうか?

[69] CSS Ruby の規定は現実的に実装可能とは思えないですし、 Firefox の実装も一般の著者に理解可能とは思えない奇怪さです。 そして Firefox 以外の Webブラウザーが実装する動きもありません。 仮に将来実装するとしても、 CSS Ruby と Firefox のどちらかと完全に一致するとは思えません。 どう転んでも相互運用性の確保は絶望的です。 これだけ難のある仕様がなぜいつまでも撤回されずにいるのか不可解です。

抑制

[7] CSS Ruby はこれをデフォルトの挙動としていて、 無効にする手段を提供していません。

[8] 一応 ruby-merge という特性があって (他の挙動と抱合せで) 制御できないこともないのですが、 Firefox は ruby-merge に未対応です。

[70] 難のある仕様がデフォルト挙動というだけでも迷惑な話なのに、 それを実装しているブラウザーが無効化の手段を提供していないというのは、 迷惑この上ありません。 auto-hiding 実装前は「何もしない」挙動だったはずなので、 無効化手段の提供はそこまで難しいものではなかったはずです。 なぜこんなことになったのでしょうか。

需要

[3] 仕様書 >>1 は 「振り仮名(ふりがな)」 と 「振ふり仮名がな」 が同じ HTML で記述できる機能だと説明していますが、 そんなことできて嬉しい人はどれだけいるのでしょうか? 「振り仮名(ふりがな)」 なんて書きたい人ってそんなにいなくないですか。 (敢えて括弧書きにするなら、 「振(ふ)り仮名(がな)」 ないし 「振(ふ)り仮(が)名(な)」 の場合の方が多いのでは。そうしないと読む人も括弧がどこにかかっているのか判断できません。) しかもそれをわざわざ ruby 要素で記述したい人はそのうちの更に一部でしょう。

[38] 括弧書きしたいだけならわざわざマーク付けする必要性はまったくありません。 ルビでないものを ruby 要素にしようと発想する人もそれほどいないでしょうし。 強いて言えば 「振り仮名(ふりがな)」 と 「振ふり仮名がな」 を動的に切り替えられるような表示モードを設けたいときに便利ですが、 そんなことありますか?

[39] 極めて稀に、日本語学習者向けのサイトで似たような例が無いことも無いのですが、 そういうところは他に「小学○年生までの教育漢字以外は仮名書きにする」 のようなオプションも合わせて提供しています。 「振り仮名(ふりがな)」 と 「振ふり仮名がな」 の切り替えだけ HTML と CSS でネイティブに対応できたとしても、 限定的な需要の一部分しかカバーできていないのです。 (しかも「振(ふ)り仮名(がな)」でなく「振り仮名(ふりがな)」にした方が嬉しいかどうかは謎。 後者だと日本語学習者は混乱するのでは。)

[30] 「振り仮名」が「振り仮名(ふりがな)」にせなあかんなら、 「振られた」は「振られた(ふられた)」、 「振り出しに戻る」は「振り出し(ふりだし)に戻る(もどる)」にするんやろな。 「振りかぶって」は「振りかぶって(ふりかぶって)」でええんやろか? 「振りハングル」 「振りローマ字」 「身振り手振り」 「ネタ振り」 「大盤振る舞い」 「お振り込み1件」 「全話振り返り一挙放送の実施決定!」 「恋ダンス振り付け動画」 「人の振り見て我が振り直せ」はどこに入れたらええんや??? これもはやルビとは違う何か別の概念ちゃうか?

[42] 「名誉き損」は「名誉き損(めいよきそん)」になるのですかね。 なら 「ら致」は「ら致(らち)」になるのでしょうか。 「私たち(わたしたち)にら致監禁(らちかんきん)の疑い(うたがい)を吹っ掛け(ふっかけ)た人物(じんぶつ)を名誉き損(めいよきそん)で訴えて(うったえて)やりたい。」 のように表示されても、判読不能ではありませんか?

[59] 「12月がつ21日にち」は「12月21日(12がつ21にち)」にするのですかね。。。 「12月がつ1日ついたち」 との辻褄をあわせないと。

[60] 「新しん型がたコロナウイルス感かん染せん症しょう」 は 「新型(しんがた)コロナウイルス感染症(かんせんしょう)」? それとも 「新型コロナウイルス感染症(しんがたころなういるすかんせんしょう)」? 「新型コロナウイルス感染症(しんがたコロナウイルスかんせんしょう)」? 読み仮名もカタカナにしないと auto-hiding が効かないけど、いいんかなあ? ひらがなで書いて 「新しん型がたコロナウイルスころなういるす感かん染せん症しょう」 になっても、普通の日本語だと困るよね (逆にやさしい日本語だと消えてしまう方が困るけど)。

[43] ルビは文字または文字の列に対して振られるもので、 単語に対して振られるものではない、 という基本的なところで理解を誤ったのではないでしょうか。 国語辞典が 「ふりがな【振り仮名】」 のように語に仮名表記を与えているのと混同してしまったのかもしれません。

[58] 関連記事: 仮名漢字混じり語の振り仮名

[6] ルビの処理はただでさえ複雑なはずなのに、 こんなレアケースのために複雑な処理は必要なのでしょうか。 (それで相互運用性を犠牲にしているのですから、...)

親文字列と同じルビ文字列

[9] この機能が必要になるレアケースよりも、 親文字と同じルビ文字列が必要になるレアケースの方が、 むしろあり得るのではないでしょうか。 こんな特殊な規則があるとは知らず、 なぜかルビが表示されないと困惑するWeb開発者が可哀想です。

[31] 例えば別の入力文書形式から HTML に変換して出力するようなソフトウェアを開発する人が、 auto-hiding のことをどれだけ知っているでしょうか (私は最近はじめて知って驚きました)。 こんなケースの動作確認が必要だとも思わんでしょう。 製品を出してみたら、 入力によってルビが表示されたり、されなかったりする不具合としか思えない挙動になってしまうなんて、 開発者を貶める罠としか思えません。

[65] 「親文字と同じルビ文字列が必要になるレアケース」 ← これ全然レアケースじゃないんだよなあ

[66] auto-hiding の設計者はこの程度の基本的な調査もしないで、 自分達の脳内の理屈だけで仕様を組み立ってているから、 使い物にならなくてしまっているわけで。

[40] 統一的な取り扱いを目的として、 仮名でもまったく同じ仮名の振り仮名を設定する場面は案外多いです。 仮名への仮名ルビ 例えば:

[23] 【難読漢字】「希う」の読み方。これはなんて読む? | ハルメク暮らし, https://halmek.co.jp/culture/c/hobby/1706

画像化された文字列

希うこいねがう

(グループルビ)

画像化された文字列

希むのぞむ

(グループルビ)

[24] 行書体、草書体のフォントで親文字列を書いて、 楷書体でルビ文字列を書きたいケースもありそう。 (変体仮名に現行仮名で書いた例は仮名へのルビ参照。)

[27] 鬼滅の刃 シリーズのロゴ 「鬼滅の刃きめつのやいば」

デザインされた文字のロゴ。親文字列とルビ文字列の対応関係がつかないグループルビ。

[28] 夜桜さんちの大作戦公式さんはTwitterを使っています 「なななんと!JC7巻発売を記念して、#夜桜さんちの大作戦 オリジナル主題歌「DA・DA・DA・DA・I・SA・KU・SEN」を坂道グループなどへの楽曲提供でも知られる近藤圭一さんが描き下ろしてくださいました! 溢れ出るニチアサ感と中毒性!ぜひお聞き下さい! PVはこちら→ https://t.co/uFH0PoxfFn https://t.co/QDumNjdumS」 / Twitter, 午後8:12 · 2021年3月4日 +09:00, https://twitter.com/OfficialHitsuji/status/1367432756775374851/photo/1

近藤こんどう圭一けいいちさんに

主題歌しゅだいか作ってつくって

もらいました!!

[29] TVアニメ『BLUE REFLECTION RAY/澪』放送直前特番 - 2021/03/16(火) 20:00開始 - ニコニコ生放送 () https://live.nicovideo.jp/watch/lv330751607 13分頃

スケブ (高倉有加の手書き) 「悩なやみみ」

高倉有加「「み」要らなかったかな?」

[71] ひめ@女体化したい人生だったさんはTwitterを使っています: 「『明治初期長野縣町村字地名大鑑』に千本柳村の小字に「いもり」として載ってました>蜎リ https://t.co/ByUzBEHvGv 登記ねっと上は千本柳までしか候補がないので小字は廃止されているのかも(一方で農地ナビ上は「小玉川原」などが確認できる) https://t.co/pbCIE1ckqX」 / Twitter, , https://twitter.com/sarasvati635/status/1512963158658682880/photo/1

地名の一覧表 (明朝体) 「せんど道せんどみち」

[62] ピンインと漢字を併記した20世紀中期の中文の新聞の事例 上ルビ では、 すべての文字にそれぞれ上ルビが振られており、 欧州数字や句読点は同じ文字が置かれていました。

[41] だのさんはTwitterを使っています: 「にほへ碑 小笠原神社境内にある 文久2年にやってきた八丈島からの移民の子供らに幕府役人が読み書きを教えた その際使い終えた筆を供養するための筆塚としてこの碑を建てたとされている https://t.co/O6yvIPvX2P」 / Twitter, 午後11:34 · 2022年8月26日 +09:00, https://twitter.com/Dhanow/status/1563173129379540993/photo/2

文化財案内看板 見出し (楷書)

「ににほほへへ碑のひ」

仮名も含めて1文字ずつ振り仮名。助詞「の」は漢字にまとめて振られている。

[63] 5774.pdf, , https://www.town.onga.lg.jp/uploaded/attachment/5774.pdf#page=6

地名リスト 「山ヤマノノ神カミ」 (明朝体)

他多数。漢字・仮名の各文字ごとに読みが片仮名で振られている。ルビは親文字単位で左寄せ。

[64] Xユーザーの長谷川ミュウツーさん: 「なんで https://t.co/H7waYpgYWF」 / X, , https://x.com/hasegawa_mew2/status/2012889027142471728/photo/1

メモ

[47] いままであまり気にしないで Firefox で表示した文章をコピペしてましたけど (表示されてるルビ文字列がコピーされないので面倒くさいなーと思いつつw)、 実はそれ以外に Firefox でだけ表示されてないルビ文字列が隠れてるかもってことですか。はあ。 困ったなあ。

[61] 引用のときは Chrome 使うようにしたほうがいいのかなー