【テクニカル・上級編】双方向テキスト(BiDi)とインライン要素の配置 – HTML実践ガイド

思考実験：BiDiの競合を回避するマークアップ

最も危険なのは、方向性の指示をCSSの`direction`プロパティだけに頼ることだ。これでは、DOM構造が非同期で動的に更新された際、ブラウザの再計算コストが跳ね上がる。

/

• 双方向テキストを安全にラップするためのコンポーネント設計
• 重要なのは、dir属性を明示的に付与し、かつUnicode制御文字を
• 最小限の責務で管理することである。

/
interface BidiContainerProps {
text: string;
langDirection: ‘ltr’ | ‘rtl’ | ‘auto’;
className?: string;
}

const BidiSafeText: React.FC = ({ text, langDirection, className }) => {
// 意図しないリフローを防ぐため、contain属性でレイアウトの隔離を試みる
// これにより、この要素内の変化がルートドキュメント全体の再配置を抑止する
return (

{text}

);
};

2. パフォーマンスの最適化：リフローとレイアウト・シフトの回避

インライン要素内で複雑なBiDi制御を行う際、最も避けるべきは「DOMの深さ」だ。RTL/LTRの境界が入れ子になった構造は、ブラウザのレイアウトエンジンにとって非常に高コストな再帰計算を要求する。

特に、`time`要素や`code`要素に動的な値を流し込む際、`display: inline-block`を安易に使うのは禁物だ。これはインラインのフローから独立した新しいBlock Formatting Context（BFC）を作成するため、周辺のテキストレイアウトを破壊する引き金となる。可能な限り `display: inline` を維持し、必要であれば `unicode-bidi: isolate` を適用せよ。

技術的なチェックポイント

• `unicode-bidi: isolate` の活用: 特定のインライン要素を、周囲のBiDi計算から論理的に隔離する。これにより、要素内のテキストの方向性が周囲に干渉することを防げる。
• 非同期レンダリングの競合: サーバーサイドで生成されたHTMLと、クライアントでハイドレーションされた結果のテキスト方向が不一致を起こすと、ブラウザはレイアウトを再計算する。SSR環境では必ずサーバー側で`dir`属性を正確に注入すること。

3. 型安全とエッジケース：TypeScriptによる防御

BiDiの管理をUIロジックに散らばらせてはならない。方向性の制御を一箇所に集約し、型安全を担保することで、将来的な多言語追加の際にも破壊的変更を防ぐことができる。

type Direction = ‘ltr’ | ‘rtl’;

/

• 厳格な型定義により、方向性の不整合をコンパイル時に検知する

/
class BidiManager {
static getImplicitDirection(text: string): Direction {
// 簡易的なアルゴリズムだが、実際にはUnicodeのプロパティを走査する
// 重い処理になるため、コンポーネントのレンダリング内ではなく、
// データの加工段階(Data Transformer)で実行すべきである
const rtlChars = /[\u0591-\u07FF\uFB1D-\uFDFD\uFE70-\uFEFC]/;
return rtlChars.test(text) ? ‘rtl’ : ‘ltr’;
}
}

結びに：ブラウザエンジンを信じすぎないこと

Webアプリケーションの品質は、こうした「目に見えない境界線の制御」に宿る。インライン要素は単なる装飾の容器ではなく、Unicodeという壮大な規格が交差する戦場だ。