Chrome 76 でのリリースが予定されている LayoutNG は、数年にわたる取り組みを終了する新しいレイアウト エンジンです。すぐに大きな改善が行われ、さらにパフォーマンスの向上と高度なレイアウト機能が実装される予定です。
最新情報
- パフォーマンスの分離を改善します。
- ラテン文字以外の文字のサポートを強化。
- 浮動小数点数とマージンに関する多くの問題を修正しました。
- ウェブの互換性に関する多くの問題を修正しました。
LayoutNG は段階的にリリースされる予定です。Chrome 76 ではインラインとブロックの レイアウトに LayoutNG が使用されます他のレイアウト プリミティブ(テーブル、Flexbox、グリッド、ブロックの断片化など)は、今後のリリースで置き換えられる予定です。
デベロッパーから見える変更
ユーザーの目に見える影響は最小限に抑えられるはずですが、LayoutNG は、一部の動作を微妙な方法で変更し、何百ものテストを修正し、他のブラウザとの互換性を向上させています。このため、最善の努力を尽くしても、一部のサイトやアプリでレンダリングや動作が若干異なる場合があります。
パフォーマンス特性もかなり異なります。全体としてのパフォーマンスは以前とほぼ同じか、わずかに向上していますが、特定のユースケースではパフォーマンスが向上する可能性が高く、他のユースケースでは少なくとも短期的にやや低下することが予想されます。
浮動小数点
LayoutNG は、フローティング要素(float: left;
と float: right;
)のサポートを再実装し、他のコンテンツとの浮動小数点数の配置に関するいくつかの正確性の問題を修正しています。
多重画像のコンテンツ
従来の float の実装では、フローティング要素の周囲にコンテンツを配置する際にマージンが正しく考慮されていなかったため、コンテンツが float 自体と部分的または完全に重なっていました。このバグの最も一般的な症状は、回避ロジックが行の高さを考慮できない段落の隣に画像を配置した場合です。(Chromium バグ #861540 をご覧ください)。
同じ問題が 1 行内で発生することもあります。以下の例では、フローティング要素の後にマイナスのマージンが付いたブロック要素を示しています(#895962)。テキストは浮動小数点数と重なってはいけません。
コンテキストの位置付けの書式設定
ブロックの書式設定コンテキストを構成する要素のサイズが浮動小数点数と同じである場合、以前のレイアウト エンジンは、ブロックのサイズを一定回数変更してからあきらめようとしていました。このアプローチでは、予測不能で不安定な動作が発生し、他の実装と一致しませんでした。LayoutNG では、ブロックのサイズを設定するときにすべての浮動小数点数が考慮されます。(Chromium バグ #548033 をご覧ください)。
絶対位置と固定位置が W3C 仕様に準拠し、他のブラウザの動作と一致するようになりました。この 2 つの違いが特に顕著なのは、次の 2 つの場合です。
- ブロックを含む複数行のインライン
包含ブロックが絶対的に配置されて複数行にまたがる場合、以前のエンジンは、包含ブロック境界を計算するために行のサブセットのみを誤って使用することがあります。 - 縦書きモード
縦書きモードの場合、従来のエンジンでは、フロー外の要素をデフォルトの位置に配置する際に多くの問題がありました。文章作成モードのサポートの改善について詳しくは、次のセクションをご覧ください。
右から左に記述する(RTL)言語と縦書きモード
LayoutNG は、縦書きモードと、双方向コンテンツを含む RTL 言語をサポートするように一から設計されています。
双方向テキスト
LayoutNG は、Unicode 標準で定義されている最新の双方向アルゴリズムをサポートしています。このアップデートにより、さまざまなレンダリング エラーが修正されただけでなく、ペアのブラケットのサポート(Chromium バグ #302469 を参照)など、不足していた機能も修正されました。
直交流
LayoutNG を使用すると、垂直フロー レイアウトの精度が向上します。たとえば、絶対位置のオブジェクトの配置や、直交フローボックスのサイズ調整(特にパーセントを使用する場合)などが該当します。W3C テストスイートの 1,258 件のテストのうち、古いレイアウト エンジンで不合格だった 103 件のテストが LayoutNG で合格しました。
固有のサイズ設定
直交書き込みモードでブロックに子が含まれている場合、組み込みサイズが正しく計算されるようになりました。
テキストのレイアウトと改行
従来の Chromium レイアウト エンジンは、テキスト要素を要素ごとに 1 行ずつレイアウトしていました。 このアプローチはほとんどの場合でうまく機能しましたが、スクリプトをサポートし、優れたパフォーマンスを実現するには、非常に複雑な作業が必要でした。また、測定の不整合が発生しやすく、コンテンツに対するコンテナのサイズやそのコンテンツ、あるいは不要な改行にわずかな違いが生じていました。
LayoutNG では、テキストは段落レベルでレイアウトされてから複数の行に分割されます。これにより、パフォーマンスとテキスト レンダリングの品質が向上し、改行の一貫性が向上します。主な違いは次のとおりです。
要素の境界を越えて結合する
一部のスクリプトでは、特定の文字が隣接している場合に視覚的に結合できます。アラビア語の例をご覧ください。
LayoutNG では、キャラクターが異なる要素にある場合でも結合できるようになりました。異なるスタイルが適用されても、結合は保持されます。(Chromium バグ #6122 をご覧ください)。
書記文字は言語の書記体系の最小単位です。たとえば、ラテン アルファベットを使用する英語やその他の言語では、それぞれの文字が書記素です。
以下の画像は、以前のレイアウト エンジンと LayoutNG での次の HTML のレンダリングをそれぞれ示しています。
<div>نسق</div>
<div>نس<span>ق</span></div>
中国、日本、韓国語(CJK)の合字
Chromium はすでに合字をサポートし、デフォルトで有効になっていますが、いくつかの制限があります。複数の CJK コードポイントを含む合字は、レンダリングの最適化のために以前のレイアウト エンジンではサポートされていません。LayoutNG ではこれらの制限がなくなり、スクリプトに関係なく合字をサポートしています。
次の例は、Adobe SourceHanSansJP フォントを使用して 3 つの任意合法的にレンダリングする方法を示しています。
コンテンツのサイズに合わせた要素
コンテンツに合わせてサイズが調整される要素(インライン ブロックなど)の場合、現在のレイアウト エンジンは、まずブロックのサイズを計算してから、コンテンツのレイアウトを実行します。フォントが積極的にカーニングされている場合など、コンテンツとブロックのサイズが一致しない場合があります。LayoutNG では、ブロックが実際のコンテンツに基づいてサイズ調整されるため、この障害モードが排除されています。
以下の例は、コンテンツに合わせてサイズ調整された黄色のブロックを示しています。Lato フォントはカーニングで T と - の間のスペースを調整し、黄色のボックスの境界がテキストの境界と一致している必要があります。
行の折り返し
前述の問題と同様に、サイズ - コンテンツ ブロックのコンテンツがブロックよりも大きい(幅が広い)場合、コンテンツが不必要にラップされることがあります。これは非常にまれですが、方向性が混在したコンテンツでも発生することがあります。
追加情報
互換性の問題と LayoutNG によって修正されたバグについて詳しくは、上記のリンク先の問題を参照するか、Chromium バグ データベースで Fixed-In-LayoutNG とマークされたバグを検索してください。
LayoutNG が原因でウェブサイトの破損が疑われる場合は、バグレポートを送信してください。Google で調査いたします。