WYSIWYG ルビ入力の概要と Chromium のバグを修正した話

#rich_text_editor_study
https://web-study.connpass.com/event/391357/

1. WYSIWYG ルビ入力の概要と Chromium のバグを修正した話 2026.05.26 (火) #rich_text_editor_study 1
2. 所属：サイボウズ株式会社 (26卒) 出身：札幌 最近の興味：家系・ポーカー 悩み：健康診断の結果が悪かったので、娯楽の 食事が奪われた 2 自己紹介 コサキン @karintou74073
3. • 文字にふりがなや補足情報を付ける仕組み • 日本では漫画・小説・教科書・新聞などで広く使用 • 難読漢字や固有名詞の読みを示し、読者の理解を助ける • 縦書きと併用されることが多い ルビとは何か 3
4. • 中国: 拼音（ピンイン）で発音を示す例あり • ただし漢字と発音がほぼ 1:1 対応のため、主に教育用途 専門家が少なく、開発者コミュニティでも優先度が低い • WYSIWYG ライブラリでも「知識がないので利用者側で対応してほしい」という反応 • 例: Lexical / Tiptap の issue でも実装は後回し 他の国でのルビ 4 Web やライブラリでの実装は後回しにされがち
5. ルビの HTML 表現 5 • ruby タグの中にテキスト + rt タグを順に並べる • rp タグはルビ非対応環境向けのフォールバック • 「明日（Ashita）」のようにカッコ付きで表示
6. 静的ページは HTML を直接書けばよいが、CMS などでユーザー入力を受ける場合は入力方法が必要 Web でのルビ入力 3 パターン 6
7. • マークダウンで専用記法を用意 • note の例: |note太郎《ノートたろう》→ プレビュー時に変換 パターン 1: マークダウン記法 7 • note は本来 WYSIWYG ベースのエディタ • それでも記法を採用 = WYSIWYG の難しさ / Web の技術的制約がある？と推測 • 記法はサービスごとに様々なバリエーションが存在
8. • ルビを独立した要素 (アトム) として扱う / 入力はモーダルなどの専用画面から行う パターン 2: アトム + 専用入力画面 8 • 「単語 + ルビ」は 1 つの埋め込み要素として扱われる • キャレットで直接文字を編集することはできない • ネイティブアプリの Word がこの方式
9. • contenteditable を使った、純粋な WYSIWYG（一番直感的に思いつく形） 編集イメージ • 単語にもルビにもキャレットを合わせて編集できる • 矢印キーで単語とルビの間を移動できる • 「やさしい日本語エディタ WordPress プラグイン」など パターン 3: 単語とルビを直接編集 9
10. • ルビが増えてくると、純粋に読みづらい • WYSIWYG なのに、最終成果物と異なる表示で編集することになる 「パターン 1: マークダウン記法」の問題点 10
11. 現状では実用的ではない • キャレット操作が十分に実装されていない • 致命的な変な挙動も大量にある（ここら辺誰も触ってなさそう） • ブラウザ依存の実装になっている • editing の内部動作は W3C の仕様が存在しない • ルビ + contenteditable 周りは WPT (共通テスト) にもない 「パターン３：単語とルビを直接編集」の問題点 11 https://codesandbox.io/p/sandbox/zxrrw8 Chrome で起きる変な動作 (contenteditable=true) - ルビの右にキャレット → 左矢印で行頭に移動 - そのまま Backspace すると行頭までごっそり削除 - ルビの先頭で入力 → 単語の末尾に追加される - 通常テキストで縦移動 → ルビに吸い込まれて抜け出せない - `rt` タグが空だと、ルビを入力できない
12. • Chrome で縦方向に移動すると、なぜか文頭や文末に飛ぶ • ProseMirror は移動処理を基本ブラウザに委ねているため、ライブラリでも問題が起きる WYSIWYG だと、アトムルビで十分では？ 12 「アトム + 専用入力画面」で十分だと考える理由 • ルビは表示領域が小さく、直接入力しづらい • 多くの変な動作を乗り越えてまで直接編集する価値はそこまで高くない アトムルビの問題点
13. ©️ Cybozu, Inc. 13 ここまでは記事の内容
14. ©️ Cybozu, Inc. 14 社内の方がリツイートしてくれたおかげで、Chromium 開発者の方に届いた
15. とりあえず ISSUE 立てるか 15
16. • IssueTracker というサービスに報告する • 再現方法や詳細、バージョンなどを入力する。他の OSS とあまり変わらない Chromium に ISSUE 報告をする 16
17. 数日経っても誰も取り組んでなさそう。。 17
18. ブラウザへのコントリビュート 興味あるし、やるか！ 18
19. ©️ Cybozu, Inc. 1. まずは手元に Clone して、ビルドする（僕の環境だと７時間ぐらいかかった気がする） 2. 原因の調査 3. main からブランチを切って、コード修正とテストコードを追加する 4. Gerrit というサービスに PR を送る（若干特殊） 5. レビューでやり取り後、権限を持つ２人に Approve をもらってマージしてもらう コントリビュートの流れ 19 • Jxck さんの「Chromium にコントリビュートするための周辺知識」を目がとれるほど読みました • 日本語でコントリビュートガイドがあることに感謝です • https://blog.jxck.io/entries/2024-03-26/chromium-contribution.html
20. ©️ Cybozu, Inc. 20 PRのイメージ
21. ©️ Cybozu, Inc. • Blink は Chromium のレンダリングエンジン • HTML / CSS の解析、レイアウト構築、描画や Web API の実装を担っている • Firefox は Gecko, Safari は WebKit • 今回関わるのは layout と editing の２つ • third_party/blink/renderer/core/editing/ • third_party/blink/renderer/core/layout/ 変更するコンポーネント：Blink 21
22. ©️ Cybozu, Inc. • Claude Code にディレクトリ構造・ファイル内容を聞きながら、理解を深めていく • ある程度バグありそうな場所を見つけたら、伝家の宝刀 print デバッグ • LOG(ERROR) << "Foo"; 簡単な原因説明 • ArrowDown を押すと、レイアウト層で「次行 and 横方向ピクセルが一番近い位置」に移動したい • レイアウトは DOM を描画するための構造に変換されたもの • <rt /> は内部的に行と同じタイプで管理されており、これを次行と誤認 • contenteditable=false の中に移動しようとして、フォールバックが起動して末尾に移動 原因の調査方法 22
23. ©️ Cybozu, Inc. • PR をレビューしていただいた田村さんにおんぶに抱っこだった • 最初に提案した contenteditable=false に移動する場合にスキップする方法は、contenteditable=true でも同 じ問題が起きているため却下 • 別案で、レイアウトの層で <rt /> ならスキップする処理にしたい • IsRubyAnnotationLine の判定用メソッドを別PRで追加していただき、私がそれを使うという流れを提案して いただいた。（神？？） レビューでの会話 23
24. ©️ Cybozu, Inc. 24 マージされて AUTHORS にのった！嬉しい！
25. • アトムルビの WYSIWYG 編集が主要ブラウザである程度まともに動くようになる！ • 別のバグっぽいものを見つけているので、その修正も必要になるかも。。。 • 主要ブラウザで詳しくバグ調査をせねば。。。 • 今主流のマークダウン形式が、WYSIWYG の選択肢が生まれる！ • Web で実用的な縦書きエディタを実装する上の、第一歩でもある • Web で縦書きエディターを各々のサービス導入できる世界線、いいね この修正で何が嬉しい？ 25
26. ©️ Cybozu, Inc. • 今はマークダウン記法でルビを入力していることが多いが見づらく、WYSIWYG の選択肢が欲しい • contenteditable=false のルビバグを修正したので、PC の主要ブラウザは動きそう • 他にもバグあるのかも（あった記憶がある） • editing はブラウザへのコントリビュートしたい方の一つの選択肢になる！ • 縦書き周りでレイアウト・editing 周りのバグっぽいものはいくつか見つけた • Web でルビが普及していけばいいね！ まとめ 26
27. ©️ Cybozu, Inc. 27