CSS オーバーフローモジュール レベル 4

1. はじめに

この仕様は、[CSS-OVERFLOW-3]を拡張します。 この仕様には、次の主要な節が含まれています:

オーバーフローのスクロールおよびクリッピング制御

この節では、レベル 3 のoverflow-* プロパティに対する比較的単純な拡張を定義します。

自動省略記号。

この節では、レベル 3 の*-ellipsis プロパティに対する実験的な拡張をいくつか定義します。

オーバーフローのリダイレクト

この節では、新たに生成された断片化コンテナーへオーバーフローをリダイレクトすることによって処理するための、 非常に実験的かつ探索的な新しいモデルを定義します。

注: 執筆時点では、[CSS-OVERFLOW-3] はまだ完全には 最終化されていません。 意図しない相違や保守上の負担を避けるため、 この仕様は css-overflow レベル 3 に対する差分仕様として記述されています。 レベル 3 の仕様が最終化された時点で、 その内容はこの仕様に統合され、 その後、この仕様がレベル 3 の仕様を置き換えます。 それまでは、この仕様にはレベル 3 に対する追加および拡張のみが含まれます。

1.1. 値の定義

この仕様は、[CSS2]のCSS プロパティ 定義規則に従い、[CSS-VALUES-3]の値定義構文を使用します。 この仕様で定義されていない値型は、CSS 値および単位 [CSS-VALUES-3] で定義されています。 他の CSS モジュールと組み合わせることで、これらの値型の定義が拡張される場合があります。

各定義に列挙されているプロパティ固有の値に加えて、 この仕様で定義されるすべてのプロパティは、 プロパティ値として CSS 全域キーワードも受け入れます。 読みやすさのため、これらは明示的には繰り返し記載されていません。

1.2. モジュール間の相互作用

このモジュールは、[CSS-OVERFLOW-3]で定義されている機能を拡張します。

2. オーバーフローの概念と用語

最終化された時点で、レベル 3 の内容をコピーします。

3. オーバーフローのスクロールとクリッピング

最終化された時点で、レベル 3 の内容をコピーします。

3.1. オーバーフローの管理: overflow-x、overflow-y、および overflow プロパティ

このレベルでは、overflow-x および overflow-y プロパティ （および overflow 一括指定プロパティ）を 置換要素にも適用されるよう拡張します。

置換要素では、 visible 以外のすべての算出値の使用値は、clip です。 ホスト言語は、このような要素に clip の既定値を適用し、 その overflow-clip-margin を content-box に設定するUA スタイル シート規則を定義するべきです。

注: 置換 要素に対する overflow の適用は、 画像がその有効なレイアウトボックスの外側に効果を描画できるようにするために追加されました。 推奨される UA スタイルシート規則は、その元の動作を既定で実現するためのものです。 課題 7059および課題 7144の議論を参照してください。 これは CSS2.1 からの変更であり、リスクがあります。

置換 要素に対する overflow の適用については、現在も検討中です。[課題 #7144]

3.2. クリッピング境界の拡張: overflow-clip-margin-* プロパティ

これらのプロパティおよびその一括指定プロパティは、 ボックスのオーバーフロークリップ 辺を定義します。 すなわち、ボックスの境界の外側へ正確にどれだけの距離まで ボックスの内容を描画できるかを定めます。 その後、 効果（上記の overflow: clip など） によってクリップされます。 これらの効果は、ボックスのオーバーフロークリップ辺までクリップするものとして定義されています。 一括指定プロパティ/個別指定プロパティの関係は、 margin と同様ですが、 一括指定プロパティの構文には制限があることに注意してください。

値は次のように定義されます:

<visual-box>

指定したオフセットがゼロの場合に、オーバーフロークリップ辺の起点として使用するボックス辺を指定します。

省略した場合、 非置換要素では padding-box、 置換 要素では content-box が既定値になります。

置換要素に対する overflow-clip-margin の適用については、現在も検討中です。[課題 #7144]

<length [0,∞]>

指定したオフセットは、 指定したボックス辺からオーバーフロークリップ辺を どれだけ拡張するかを決定します。 負の値は無効です。 省略した場合の既定値はゼロです。

オーバーフロークリップ 辺の角は、 ボックスのボーダー辺からの累積オフセットと同じ拡張半径を持つ外側の ボックスシャドウとまったく同じ形状になります。 CSS 背景および境界 3 § 4.2 角の形状およびCSS 背景および境界 3 § 6.1.1 シャドウの形状、拡張、およびくり抜きを参照してください。 特に、ボーダー辺を越える外側への拡張に関する式に注意してください。

注: このプロパティは、 overflow: hidden または overflow: scroll を持つボックスには効果がありません。 これらはオーバーフロークリップ辺を使用するものとして定義されていません。

4. 自動省略記号

4.1. インラインオーバーフローの省略記号: text-overflow プロパティ

この節は、 [CSS-OVERFLOW-3]に合わせて再同期する必要があるかもしれません。

このプロパティは、インライン内容が、 overflow が visible 以外であるブロックコンテナー要素（「ブロック」）の インライン進行方向で行ボックスの辺からオーバーフローした場合のレンダリングを指定します。

このプロパティは継承されませんが、 行ボックスのインライン整形コンテキストを確立するために 生成される匿名ブロックコンテナーボックス（ブロック コンテナーを参照）は 無視され、 適用されるプロパティの値は、 匿名でないボックスの値になります。これは、例 7の「ネストされた段落」の部分で確認できます: 「NESTED」という単語は、text-overflow プロパティが初期値である 匿名ブロックコンテナーで囲まれているにもかかわらず、 省略記号によって省略されます。

テキストは、たとえば折り返しが阻止された場合 （たとえば white-space: nowrap による場合や、単一の 単語が長すぎて収まらない場合）にオーバーフローすることがあります。 値の意味は次のとおりです:

clip

ブロックコンテナー要素からオーバーフローするインライン内容をクリップします。 文字は一部分だけがレンダリングされる場合があります。

ellipsis

クリップされたインライン内容を表す省略記号（U+2026）を レンダリングします。 実装は、言語、用字系、または書字モードにより適した 省略記号に置き換えることができます。 また、省略記号を利用できない場合は、3つのドット「...」に置き換えることができます。

<string>

クリップされたインライン内容を表すために、指定された文字列をレンダリングします。 指定された文字列は、双方向テキスト処理の目的では 独立した段落として扱われます。

fade( [ <length> | <percentage> ] )

行ボックスからオーバーフローするインライン内容をクリップします。 文字は一部分だけがレンダリングされる場合があります。 さらに、UA は行ボックスの辺付近に フェードアウト効果を適用しなければならず、 その辺では完全に透明になります。

フェードがブラウザー間で 同一になるよう、 フェードアウトの計算方法を 定義する必要があるでしょうか？ おそらく mask-image: linear-gradient(to right, rgba(0,0,0,1), rgba(0,0,0,0)) のようなものにするべきですが、 行の関連部分にのみ適用する必要があります。

引数は、フェード効果が 適用される距離を決定します。 <percentage> は、行ボックスの幅に対して解決されます。 0未満の値は0に切り詰められます。 行ボックスの幅を超える値は、行ボックスの幅に切り詰められます。

行ボックスが、 希望する長さでフェード効果を表示するには 短すぎる場合、 効果を破棄するべきでしょうか、 収まるまで適用距離を短縮するべきでしょうか、 それともフェードの終端をクリップするべきでしょうか？

行ボックスから オーバーフローするものや、 行ボックスに重なるものを どのように処理するべきでしょうか？ フェードは行の論理的な内容に適用するべきでしょうか、 行ボックスの物理的な領域に適用するべきでしょうか、 それとも両者の交差部分に適用するべきでしょうか？

fade

fade() と同じですが、 フェード効果が適用される距離は UA によって決定されます。妥当な値として 1em が提案されています。

このプロパティの定義では、読みやすさのために「文字」という用語を使用していますが、 実装上は「書記素クラスタ」[UAX29]を意味します。

値が1つの場合は、 行ボックスのend 辺にのみ適用されます。 値が2つの場合、 最初の値はline-left 辺に適用され、 2番目の値はline-right 辺に適用されます。 end、line-left、および line-right という用語は、[CSS-WRITING-MODES-3]で定義されています。

注: 値が2つの場合に、start および end ではなく、line-left および line-right を使用するのは意図的なものであり、 矢印などの方向を示す文字を使いやすくするためです。

ellipsis 値 および文字列値の場合、 実装は、省略記号/文字列を収めるために必要に応じて、行の該当する辺にある文字および アトミックインラインレベル要素を非表示にし、 残ったインライン内容の該当する辺の すぐ隣に省略記号/文字列を配置しなければなりません。 行の最初の文字またはアトミックインラインレベル 要素は、省略記号で省略するのではなく、 クリップしなければなりません。

div {
  font-family: monospace;
  white-space: pre;
  overflow: hidden;
  width: 9ch;
  text-overflow: ellipsis;
}

省略処理の 詳細

• 省略処理はレンダリングにのみ影響し、レイアウトにも ポインターイベントの配送にも影響してはなりません: UA は、省略記号上のすべてのポインターイベントを、 text-overflow が none であったかのように、省略された要素へ配送するべきです。
• 省略記号は、ブロックに従ってスタイル指定され、ベースラインに揃えられます。
• 省略処理は、相対位置指定およびその他のグラフィカルな変形の後に行われます。
• 省略記号のための空間が不足している場合は、 省略記号自体のレンダリングをクリップします （行上の中立文字が text-overflow:clip 値によって 本来クリップされる側と同じ側で行います）。

省略記号に対する ユーザー操作

• ユーザーが内容を操作している場合 （たとえば編集、選択、スクロール）、 ユーザーエージェントは、ellipsis、文字列値、fade、または fade() を text-overflow:clip として扱うことができます。
• 省略記号を選択すると、省略されたテキストが選択されるべきです。 省略されたテキストがすべて選択された場合、 UA は省略記号も選択されている状態を表示するべきです。 部分的に選択された省略テキストの動作は、UA に委ねられます。

div {
  font-family: Helvetica, sans-serif;
  line-height: 1.1;
  width: 3.1em;
  border: solid .1em black;
  padding: 0.2em; margin:1em 0;
}

<div>
CSS は素晴らしい、そうです
</div>

<div style="text-overflow:clip; overflow:hidden">
CSS は素晴らしい、そうです
</div>

<div style="text-overflow:ellipsis; overflow:hidden">
CSS は素晴らしい、そうです
</div>

<div style="text-overflow:ellipsis; overflow:hidden">
ネスト
 <p>段落</p>
省略記号で省略されません。
</div>

<div style="text-overflow:fade; overflow:hidden">
CSS は素晴らしい、そうです
</div>

注: 省略記号が配置される行の側は、 ブロックのdirection によって決まります。 たとえば、オーバーフローを非表示にする右から左の （direction: rtl） ブロックは、インライン内容を左 側でクリップします。 したがって、クリップされた内容を表す text-overflow の省略記号は、左側に 配置されます。

この注を示す RTL の図を ここに挿入します。

スクロールインターフェイスとの 省略記号の相互作用

この節は、text-overflow:clip 以外の text-overflow （clip 以外の text-overflow） および overflow:scroll を持つ要素に適用されます。

clip 以外の text-overflow を持つ要素が、テキストのインライン進行方向で overflow: scroll となっており、 ブラウザーがスクロールの仕組みを提供する場合 （たとえば、要素上のスクロールバー、 スワイプスクロール用のタッチインターフェイスなど）、 ユーザー体験を向上させるために、実装には次のような追加の詳細があります:

要素がスクロールされると（たとえば、ユーザーまたは DOM 操作によって）、 要素の内容がさらに表示されます。 text-overflow の値は、 要素の内容がさらに表示されるかどうかに影響するべきではありません。 clip 以外の text-overflow が設定されている場合、 より多くの内容がスクロールされて表示領域に入るにつれて、 実装は、収まる追加内容をすべて表示し、 本来クリップされる内容 （または省略記号/文字列のための空間を確保するために必要な内容）のみを切り詰めるべきです。 これは、要素が内容の端を 表示できる位置までスクロールされるまで続きます。 その時点では、その内容を 省略記号/文字列ではなく表示するべきです。

div.crawlbar {
  text-overflow: ellipsis;
  height: 2em;
  overflow: scroll;
  white-space: nowrap;
  width: 15em;
  border:1em solid black;
}

<div class="crawlbar">
CSS は素晴らしく、特にスクロールして
単に既定で他のテキストに重ねる代わりに
追加のテキストを表示できる場合はなおさらです。
</div>

一部の内容がスクロールされて表示領域に入ると、 反対側では別の内容が表示領域からスクロールして外れる可能性があります。 その内容のブロックコンテナー要素が、 スクロールを行っているものと同じであり、 text-overflow の算出値が2つの値を持ち、 始端辺に適用される値が clip 以外の値である場合、 実装は、クリップされた内容の代わりに 省略記号/文字列をレンダリングしなければなりません。 その詳細は上記の値の定義と同じですが、 省略記号/文字列は、ブロックの方向（direction プロパティに従う）の start（end ではなく）に 描画されます。

内容がスクロールされている間、 実装は省略記号/文字列のレンダリングを調整できます （たとえば、行の辺ではなくボックスの辺に揃えます）。

始端と終端の両方の省略記号/文字列を配置するための空間が不足している場合は、 終端の省略記号/文字列のみをレンダリングするべきです。

4.2. ブロック軸オーバーフローの表示: block-ellipsis プロパティ

このプロパティを使用すると、切り詰められた、または中断された内容の連続性を 示すために、（強制的なまたは非強制的な）領域分割の 前にある最後の行ボックスへ内容を挿入できます。 このプロパティは、ブロック コンテナー自体に直接含まれる行ボックスにのみ影響しますが、 継承されるため、上書きされない限り子孫の行ボックスにも影響します。 ボックスに、領域 分割の直前にある行ボックスが含まれていない場合、 このプロパティは効果を持ちません。

注: このような領域分割を持つボックスを生成する方法については、附属書 A: オーバーフローのリダイレクトを参照してください。

これは、他の種類の 断片化分割（たとえば、ページや段）にも適用するべきでしょうか？

挿入された内容は、ブロックオーバーフロー省略記号と呼ばれます。 値の意味は次のとおりです:

none

レンダリングには影響しません。

auto

影響を受ける行ボックスの末尾に、ブロック オーバーフロー省略記号として、省略記号（U+2026）—または組版上より適切な同等物—を レンダリングします。 UA は、最も適切な省略文字列を決定するために、内容の 言語、 書記体系、および書字 モードの規則を使用するべきです。

<string>

影響を受ける行ボックスの末尾に、 指定された文字列をブロックオーバーフロー省略記号としてレンダリングします。 文字列が不合理なほど長い場合、UA はその文字列を切り詰めることができます。

block-ellipsis が none でない場合、 ブロック オーバーフロー省略記号の文字列は、 匿名インラインで囲まれ、 ブロックコンテナーのルートインライン ボックスの直接の子として、 行ボックスの末尾に配置されます。 これにより、行ボックス内で 行の他の内容が使用できる空間が減少します。 このインラインには unicode-bidi: plaintext および line-height: 0 が割り当てられ、行全体に ブロックオーバーフロー省略記号全体を 収めることができる最後のソフト折り返し機会（[CSS-TEXT-3]を参照）の後に配置されます。 この目的では、overflow-wrap によって追加されたソフト折り返し機会は無視されます。 その結果、行ボックスの内容全体が押し出された場合、 行ボックスには、CSS 2.1 § 10.8.1 レディングと ハーフレディングで定義されているストラットが含まれていると見なされます。 テキストの配置および両端揃えは、 配置後に行われ、 挿入されたブロックオーバーフロー省略記号を 行の残りの内容と一緒に測定します。

注: ブロックオーバーフロー省略記号のline-height を 0 に設定することで、 その挿入によって行の高さが増加しないことが保証されます。 高さが増加すると、さらに再レイアウトが発生し、循環が生じる可能性があります。 これは、ブロックオーバーフロー 省略記号を描画時の操作として挿入することとほぼ同等ですが、配置と 両端揃えには引き続き関与します。 欠点は、ブロック オーバーフロー省略記号内の通常より高い、または深いグリフがオーバーフローする可能性があることです。

ブロック オーバーフロー省略記号を、 ::first-letter または ::first-line 擬似要素のいずれにも含めてはなりません。

後続の内容を受け取る、後続の断片化コンテナーが断片化コンテキスト内に存在する場合、 ブロックオーバーフロー省略記号によって押し出された内容は、その断片化コンテナーへ送られなければなりません。

UA は、ブロックオーバーフロー省略記号を分割不可能な文字列として扱わなければなりません。 ブロックオーバーフロー省略記号の一部でもオーバーフローする場合、 それはスクロール可能なオーバーフローとして扱われ、 そのレンダリングは text-overflow プロパティの影響を受けます。

ブロック オーバーフロー省略記号はイベントを捕捉しません: ポインターイベントは、その下にあるものへ配送されます。

これは、ボックスの内在サイズにも影響しません: min-content および max-content サイズは、 block-ellipsis が none であるかのように算出されます。

注: 将来の仕様でこの機能が拡張される可能性があります。 たとえば、テキストのスタイルを指定するための ::ellipsis 擬似要素を提供したり、 インラインレベルまたはブロックレベルの標識として使用する ブロックの子要素を選択できるようにしたりすることが考えられます （その場合、イベントを捕捉できます）。

5. オーバーフローの断片化

5.1. 可視行の制限: line-clamp 一括指定 プロパティ

line-clamp プロパティは、max-lines、block-ellipsis、および continue プロパティの一括指定プロパティです。

当面の間、 実験的な実装には、この一括指定プロパティとその個別指定プロパティで定義された 完全な動作に従うことが推奨されますが、 作者に公開するのは一括指定プロパティのみにすることが推奨されます。 これは、個別指定プロパティとその値を さらに調整しやすくし、 特に名前を変更する可能性に対応するためです。

このプロパティを使用すると、ブロックコンテナーの内容を 指定された行数に制限できます。 残りの内容は断片化によって取り除かれ、 レンダリングも測定もされません。 任意で、切り詰められた、または中断された内容の連続性を示すために、 最後の行ボックスへ内容を挿入することもできます。

値の意味は次のとおりです:

none

max-lines を none、continue を auto、 block-ellipsis を none に設定します。

<integer [1,∞]> <block-ellipsis>?

max-lines を指定された <integer>、continue を discard、 block-ellipsis プロパティを値の2番目の成分に設定します。 省略した場合は auto に設定します。

この仕組みの動作の詳細については、 対応する個別指定プロパティを参照してください。

li {
  line-clamp: 5 "…（次のページに続く）";
}
strong {
  display: block;
  text-transform: uppercase;
}

<li><a href="cheese-is-milk">
  <strong>チーズは実際には牛乳から作られている！</strong>
  ワールド・ワイド・ウェブ報道団の調査記者が
  チーズの秘密を発見した。
  複雑に入り組んだ官僚機構と影の企業を追跡し、
  精鋭記者チームはカマンベールの源を突き止めた。
</a></li>

+---------------------------------------+
| チーズは実際には牛乳から作られている！ |
| ワールド・ワイド・ウェブ報道団の       |
| 調査記者がチーズの秘密を発見した。     |
| 複雑な官僚機構と影の企業を追跡し、     |
| 精鋭記者…（次のページに続く）          |
+---------------------------------------+

5.1.1. レガシー互換性

レガシーな内容との互換性のため、 line-clamp をサポートする UA は、-webkit-line-clamp プロパティと、 continue プロパティの追加の値である-webkit-discard もサポートしなければなりません。

line-clamp と同様に、-webkit-line-clamp は、 max-lines、continue、および block-ellipsis の一括指定プロパティですが、 次の点が異なります:

• 構文は none | <integer [1,∞]> です

• continue を discard ではなく -webkit-discard に設定します

• block-ellipsis を無条件に auto に設定します

さらに、display プロパティの算出値が -webkit-box または -webkit-inline-box であるボックスの子（匿名の子を含む）では、 max-lines、continue、および block-ellipsis プロパティの使用値は、 親ボックスの算出値から取得されます。 ボックス自体におけるこれらのプロパティの算出値は無視されます。

-webkit-discard 値は、discard と同じように動作しますが、 親の display プロパティの算出値が -webkit-box または -webkit-inline-box であり、かつ親の-webkit-box-orient プロパティの算出値が vertical である場合にのみ効果を持ちます。

注: レガシーな-webkit-line-clamp プロパティの実装は、 ここで指定されているものと同一の動作をしてきたわけではありません。 過去の動作には癖があり、堅牢性も低いものでした。 これは、たとえばこの ブログ記事に記録されています。 現在の設計は、その初期の実験における誤りから学んだものであり、 実装を最終的に指定された動作へ変更できるよう、 既存の内容と十分に互換性を持つことを意図しています。 さらなる調整が必要であることが判明した場合は、 この仕様に組み込まれます。 それまでは、相違が存在する可能性があることに作者は注意するべきです。

5.2. 指定行数の後での強制分割: max-lines プロパティ

このプロパティは、領域分割を捕捉する断片化コンテナーではないボックスには効果を持ちません。

それ以外の場合、max-lines の値が none でなければ、 N 番目の子孫のインフロー行ボックスの後に領域分割が強制されます。 ここで、N は max-lines の指定値です。 同じブロック整形コンテキスト内にある行ボックスのみが数えられます: 独立した整形コンテキストを確立する子孫の内容は、 行ボックスを数える際に飛ばされます。

行ボックスが N 個未満の場合、 max-lines は領域分割を導入しません。

<div id=a>
  a: 1行目<br>
  a: 2行目<br>
  <div id=b>
    b: 1行目<br>
    b: 2行目<br>
    b: 3行目<br>
    b: 4行目<br>
  </div>
  a: 3行目<br>
  a: 4行目<br>
</div>

a: 1行目
a: 2行目
b: 1行目
b: 2行目…
a: 3行目…

a: 1行目
a: 2行目
b: 1行目…

注: これは、max-lines を 段組みコンテナーに適用しても効果がないことを意味します。 これは、段組みコンテナーに含まれるすべての行ボックスが、独立した整形コンテキストにネストされるためです。

正の整数のみが受け入れられます。 ゼロまたは負の整数は無効であり、 宣言を無視させなければなりません。

注: widows、orphans、および break-inside プロパティは、 max-lines プロパティによって導入される強制的な領域分割の 位置には影響しません。

5.3. オーバーフローの断片化: continue プロパティ

continue プロパティを使用すると、作者は ボックスを断片化コンテナーに変換し（[CSS-BREAK-3]を参照）、 断片化分割後の内容を破棄するよう指定できます。

このプロパティは、 [CSS-REGIONS-1] の region-fragment プロパティを一般化して置き換えることを目的としています。 この仕様において十分に安定した時点で、領域仕様から region-fragment を削除し、 このプロパティに置き換えるべきです。

auto

ボックスに収まりきらない内容がある場合、 超過した内容は通常の規則に従って処理されます。

discard

ボックスがまだ領域分割を捕捉する断片化コンテナーでない場合、そのようなコンテナーになります。[CSS-BREAK-3] 最初の領域分割後の内容はレンダリングされません（下記を参照）。 （ボックスが段組みコンテナーである場合、 すべてのオーバーフロー段もレンダリングされません。）

注: この領域 分割は、強制的 （たとえば max-lines、または break-before/break-after プロパティなど、別の仕組みによって課されるもの） である場合も、非強制的（たとえば、サイズ制約により内容がこの断片化コンテナーからオーバーフローする場合） である場合もあります。 他の断片化コンテキストに適用される分割（このボックス 自体のページ化など）によって、 内容が破棄されることはありません。

注: このプロパティによって、ボックスが 独立した整形 コンテキストを確立することはありません。

次の図のように、過度に長くオーバーフローする 1行と、 断片化方向に収まりきらない追加の4行を持つ記事では、 overflow と continue プロパティの組み合わせに応じて、異なるレンダリングが可能です。

	continue: discard	continue: auto
overflow: visible
overflow: hidden

continue: discard によって「レンダリングされない」内容は、display: none と同様に破棄されます:

• レンダリングされません。

• 音声レンダリングにも利用できません。

• ユーザー操作を許可しません。

• OM への影響が 明確に定義されていることを確認します。[課題 #2970]

• 静的位置が破棄された 内容内にある位置指定要素がレンダリングされない場合はどうなるでしょうか？ シドニー F2F 会議での議論も参照してください。 [課題 #2971]

ただし、内在サイズは断片化コンテナー全体にわたって算出されるため、 この内容は、ボックスのmin-content および max-content インラインサイズを求める目的では 考慮されます（CSS 断片化 3 § 5.1 サイズの異なるフラグメンテナーへの分割を参照）。Min-content および max-content ブロックサイズは、 強制的分割が 存在する場合は、断片化フローの先頭から最初の強制的分割までの内容に基づいて算出され、 強制的分割が存在しない場合は、断片化フローの末尾までの内容に基づいて算出されます。

注: 並列断片化フローの場合、 ボックスツリー内で断片化分割の後に現れる内容でも、 この断片化コンテナーの末尾を表す位置より 上にレイアウトされる場合は、引き続きレンダリングされる可能性があります。

附属書 A: オーバーフローの リダイレクト

この節は非常に 実験的です。 追加のユースケースを解決するために、 continue プロパティの機能を 拡張しようとする現在の試みを記録しています。 ただし、現時点では合意が得られていません。 議論を促すためにここで提示していますが、 非実験的な実装は推奨されません。

CSS レベル 1 [CSS1] では、指定されたサイズの要素内に 収まりきらない量の内容を配置することは、 通常、オーサリングエラーでした。 そうすると、内容が要素の 境界外へはみ出し、 その内容が他の要素と 重なる可能性が高くなりました。

CSS レベル 2 [CSS2] では、overflow プロパティが導入され、 作者はオーバーフローをスクロールによって処理できるようになり、 オーサリングエラーではなくなりました。 また作者は、オーバーフローを クリッピングによって処理するよう指定することもできます。 これは、内容を表示しないことが 作者の意図である場合に適しています。 これは、CSS オーバーフローモジュール レベル 3 [CSS-OVERFLOW-3] でさらに改良されました。

ただし、大量の内容を 提示する方法はスクロールだけではなく、 スクロールが最適な方法でない場合もあります。 結局のところ、大量の文書の一般的な形式として 冊子体が巻物に取って代わったのは、 冊子体に利点があったためです。

この仕様では、ページの要素が オーバーフローをスクロールではなく ページ化によって処理するよう、 Web ページで指定するための仕組みを導入します。

この仕様は、オーバーフローの概念を 別の方向にも拡張します。 要素の内容を流し込む単一の領域を 作者が指定することを要求する代わりに、 この仕様では、作者がそれぞれ独自の寸法とスタイルを持つ 複数の断片を指定できます。 これにより、要素の内容は断片から次の断片へ流れ、 オーバーフローせずに内容を配置するために必要な数の断片を使用できます。

どちらの場合も、実装は ブロック進行方向で内容を分割しなければなりません。 実装がこれを行う方法は、 CSS 断片化モジュール [CSS-BREAK-3] で説明されています。

オーバーフローのチャネリング: continue プロパティ

continue プロパティを使用すると、作者は 要素内に収まらない内容を 断片化するよう要求し（[CSS-BREAK-3]における意味で）、 残りの内容をどこで継続するかについて 選択肢を指定できます。

特に、このプロパティは従来のページ化を説明し、 さらに拡張します。

この プロパティとその値の名前は暫定的なものです。 当初は 「fragmentation: auto | none | break | clone | page」として https://lists.w3.org/Archives/Public/www-style/2015Jan/0357.html で提案されましたが、どの名前がより適切であるかについては、まだ広範な合意がありません。

このプロパティは、 region-fragment を一般化して置き換えることを目的としています。 この仕様において十分に安定した時点で、領域仕様から region-fragment を削除し、 このプロパティに置き換えるべきです。

注: continue: fragments は、 この仕様の以前のバージョンにあった 「overflow:fragments」を置き換えます。 一方、continue: paginate は「overflow: paged-x | paged-y | paged-x-controls | paged-y-controls」を置き換えます。

auto

要素が領域チェーン内の最後以外のCSS 領域である場合に限り、 auto が算出値として現れる可能性があります。 収まりきらない内容は、チェーン内の次の領域へ送られます。

それ以外のすべての場合、auto は他のいずれかの値として算出されます。

これは、 指定値が算出値となる§ 5.3 オーバーフローの断片化: continue プロパティの定義とは異なります。 どちらのモデルがより適切でしょうか？

overflow

収まりきらない内容は、overflow プロパティに従ってオーバーフローします

paginate

収まりきらない内容はページ化されます。 「overflow: scroll」がスクロール可能なビューを作成するのと同様に、 要素内にページ化されたビューを作成します。

ページ化されたオーバーフローを参照してください

注: 印刷は、実質的にルート上の 「continue: paginate」です。

fragments

収まりきらない内容があると、要素は自身を複製してレイアウトを継続します。

断片化されたオーバーフローを参照してください。

特定の要素または擬似要素における continue の算出値は、 次のように決定されます:

1. レイアウト封じ込めを持つ要素または擬似要素（[CSS-CONTAIN-1]を参照）では、 指定値が auto または fragments の場合、 算出値は overflow です。
2. それ以外で、指定値が auto の場合
   1. 領域 チェーン内の最後以外のCSS 領域では、 算出値は auto です
   2. ページでは、 算出値は paginate です
   3. 断片ボックスでは、 算出値は fragments です
   4. それ以外の場合、算出値は overflow です
3. それ以外で、指定値が fragments の場合
   1. ページでは、 算出値は paginate です
   2. それ以外の場合、算出値は指定値です
4. その他のすべての場合、算出値は指定値です

段組み内の段を選択できる 擬似要素を導入する場合、 その擬似要素では auto が auto として算出されることを指定するか、 新しい値を導入して auto がその値として算出されるようにする必要があります （ただし、段ではないものにおいて、その値は何として算出されるのでしょうか？）。

注: このプロパティに至った背景の議論については、 次のスレッドを参照してください: overflow、 overflow-x、overflow-y、および overflow-style に関する議論と、fragmentation プロパティの提案

ページ化されたオーバーフロー

この節では、continue プロパティの paginate 値を導入し、その意味を定義します。

この節を執筆します

@page 規則によってページの スタイルを指定できるようにするべきです。ネストされたページでは、どのように機能するのでしょうか？

@media (overflow-block: paged), (overflow-block: optional-paged) {
  :root {
    continue: paginate;
  }
}

従来のページ化 （たとえば印刷時）では、 ページボックスが :root の擬似要素の子になるのではなく、 :root がページボックスに含まれていることを前提とします。 断片ボックスに似たものを使用して、これを回避できるでしょうか？ または、:root 内のページボックス内に、:root を再現する断片ボックスを配置する方法はどうでしょうか？

通常の CSS ボックスの 子である場合、ページボックスモデルはどのように機能するのでしょうか？

[CSS3GCPM]における最初の提案と Opera の実装では、 paginate の代わりに4つの値を使用していました: 「paged-x | paged-y | paged-x-controls | paged-y-controls」。 このプロパティにもこれらの値を含めるべきでしょうか、 それとも別のプロパティとして扱う方が適切でしょうか？ （たとえば、「pagination-layout: auto | horizontal | vertical」、「pagination-controls: auto | none」）

一度に1ページだけでなく、 N ページを同時に表示できるようにするべきでしょうか？ これは、次のような「pagination-layout」の値にできるでしょうか: 「pagination-layout: horizontal 2;」

Brad Kemper は、複数ページの表示にも対応する、 ページ化と断片オーバーフローを 組み合わせるためのモデルを提案しています。https://www.w3.org/mid/FF1704C5-D5C1-4D6F-A99D-0DD094036685@gmail.com

ページ化されたオーバーフローの現在の実装では、 [CSS3GCPM] 草案で提案された overflow-style プロパティ （[CSS3-MARQUEE] の提案とも一致します）や、 ここで説明されている continue プロパティではなく、 overflow/overflow-x/overflow-y プロパティを使用しています。

断片化されたオーバーフロー

この節では、continue プロパティの fragments 値を 導入し、その意味を定義します。

要素の continue の算出値が fragments であり、 それ以外の場合に実装がその要素のボックスを作成する状況では、 実装は、その要素のために一連の断片ボックスを 作成しなければなりません。 （continue: fragments を持つ要素が、断片ボックスを1つだけ生成する場合もあります。 ただし、要素の continue の算出値が fragments でない場合、 そのボックスは断片ボックスではありません。） すべての断片ボックスは断片化コンテナーであり、 その断片化コンテナーを断片化させる オーバーフローが発生すると、 直前の断片ボックスの次の兄弟として、別の断片ボックスが作成されます。それとも、要素の次の兄弟であるかのように扱われるのでしょうか？ これが他のボックスレベルの修正と どのように相互作用するかを正確に把握する必要があります。 さらに、断片ボックスが 段組みボックスでもある場合 （[css-multicol-1] で定義されていますただし、そこで定義されているのは段組み コンテナーです）、 オーバーフロー 段 [css-multicol-1] の作成につながる内容は、 代わりに追加の断片ボックスへ流し込まれます。 ただし、断片ボックス自体が分割される場合もあります （ページ、段、または他の断片ボックスなど、 断片ボックス外部の断片化コンテキストにおける断片化によるものです）。 このような分割では、複数の断片ボックスではなく、 同じ断片ボックスの複数の断片が生成されます。 （断片ボックスはそのインデックスに基づいてスタイル指定される場合があるため、これは重要です。 このような分割では、単一のインデックスを持つ断片ボックスの 複数の断片が生成されます。 この設計が選択されたのは、 断片ボックスをページ間で分割しても、 インデックスと特定の内容部分との関連付けが壊れないようにするためです。）外側の断片化コンテキストへ分割する強制分割では、 単一の断片ボックスの新しい断片を生成するべきでしょうか、 それとも新しい断片ボックスを生成するべきでしょうか？ ここでは、混乱を少し軽減するために、断片ボックス以外の用語を使用するべきでしょうか？

別の種類の断片化コンテキスト内で 分割された要素の各部分に スタイルを指定できるようにしたい場合は、どうなるでしょうか？ これらの規則により、その目的で ::nth-fragment() を使用することはできません。 この名前が、そのような機能にとって最も論理的な名前に見えるにもかかわらずです。

<!DOCTYPE HTML><title>内容を同じ大きさの
  カードに分割する</title>
<style>
  .in-cards {
    continue: fragments;

    width: 13em;
    height: 8em;

    padding: 4px;
    border: medium solid blue;
    margin: 6px;

    font: medium/1.3 Times New
      Roman, Times, serif;
  }
</style>
<div class="in-cards">
  この例では、div 内のテキストが
  一連のカードに分割されます。
  これらのカードはすべて同じスタイルを持ちます。
  1つのカードからオーバーフローする
  十分な量の内容があると、
  別のカードが作成されます。2番目の
  カードは、1番目のカードの
  次の兄弟であるかのように作成されます。
</div>

<!DOCTYPE HTML><style>
  .article {
    continue: fragments;
  }
  .article::first-letter {
    font-size: 2em;
    line-height: 0.9;
  }
  .article::nth-fragment(1) {
    font-size: 1.5em;
    max-lines: 3;
  }
  .article::nth-fragment(2) {
    column-count: 2;
  }
</style>
<div class="article">
  ...
</div>

continue: fragments は、少なくとも一部の表の構成要素には 適用されず、 おそらく他の要素にも適用されないことを指定するべきです。 正確にどの要素であるかを判断する必要があります。

どの break-* プロパティ値がこのコンテキスト内で 分割を発生させるかを明確にするため、 この仕様では、作成される 断片化コンテキストの種類を指定する必要があります。 おそらく break-*: region を適用することになります。

この仕様には、 断片を含むレイアウトが、 断片の内在サイズを使用して 断片に利用可能な空間の量を変更する特性を持つ場合に 適用される処理モデルが必要です。 たとえば [CSS3-GRID-LAYOUT] が該当します。 このような処理モデルについては、すでに [CSS-REGIONS-1] である程度の作業が行われています。 そこで行われたモデルに関する作業と、 その仕様の編集者の知見を、 この仕様における処理へ反映するべきです。

断片のスタイル指定

::nth-fragment() 擬似要素

::nth-fragment() 擬似要素は、 要素によって生成される一部の断片 ボックスを記述する擬似要素です。 擬似要素の引数は、[SELECT] で 定義される :nth-child() 擬似クラスの引数と同じ構文を取り、 同じ意味を持ちます。 ただし、番号は要素の兄弟ではなく、 要素によって生成される断片ボックスを基準とします。

始端ではなく終端から数えることで 断片を指定できるセレクターは、 意図的に提供されていません。 このようなセレクターは、 断片数の決定を妨げるためです。

今後の 議論によっては、 この ::nth-fragment(an+b) 構文は、 新しい ::fragment:nth(an+b) 構文に 置き換えられる可能性があります。

断片のスタイル指定

これは continue:fragments のみに適用するべきでしょうか、 それとも continue:paginate にも適用するべきでしょうか？ （適用する場合、 continue:paginate には より厳しいプロパティ制限が必要になります。）

::nth-fragment() 擬似要素を持つ規則が存在しない場合、 各断片 ボックスの算出スタイルは、 その断片ボックスが作成された要素の算出スタイルになります。 ただし、断片ボックスのスタイルは、 セレクターの主体 [SELECT] が ::nth-fragment() 擬似要素を持つ規則からも影響を受けます。 これは、断片ボックスの1から始まる番号が その ::nth-fragment() 擬似要素と一致し、 セレクター（::nth-fragment() 擬似要素を除く）が 断片を生成する要素と一致する場合です。

断片ボックスのスタイルを決定する際、 断片擬似要素と一致するこれらの規則は、 要素と一致する規則と一緒にカスケードされます。 断片擬似要素は、詳細度の計算に 擬似クラスの詳細度を追加します。これはカスケードモジュールでも 指定する必要があるでしょうか？

<!DOCTYPE HTML><style>
  .bouncy-columns {
    continue: fragments;
    width: 6em;
    height: 10em;
    float: left;
    margin: 1em;
    font: medium/1.25 Times New
      Roman, Times, serif;
  }
  .bouncy-columns::nth-fragment(1) {
    background: aqua; color: black;
    transform: rotate(-3deg);
  }
  .bouncy-columns::nth-fragment(2) {
    background: yellow; color: black;
    transform: rotate(3deg);
  }
</style>
<div class="bouncy-columns">
  ...
</div>

::nth-fragment() 擬似要素に continue プロパティでスタイルを指定すると効果があります。 断片ボックスの continue の算出値が fragments 以外である場合、その断片ボックスが最後の断片になります。 ただし、最初の断片で continue を 上書きしても、 断片ボックスが存在しなくなることはありません。 断片ボックスが存在するかどうかは、 要素の overflow の算出値によって決まります。

::nth-fragment() 擬似要素に content プロパティでスタイルを指定しても効果はありません。 断片ボックスの content の算出値は、 要素の content の算出値と 同じままです。

断片ボックスに display: none を指定すると、 そのインデックスを持つ断片ボックスは生成されません。 ただし、後続の断片ボックスの ::nth-fragment() 擬似要素との照合に使用する インデックスに関しては、 生成されたものとして引き続き数えられます。 ただし、生成されないため、内容は含まれません。

display、 position、 または float に他の値を指定することは許可されますが、 内側表示型を変更することは許可されません。 （continue は、 ブロックコンテナー、フレックスコンテナー、およびグリッドコンテナーにのみ適用されるためです）。これがどのように 機能するかを正確に指定する必要があります

擬似要素が対応する要素内に存在する 他の擬似要素のモデルと一致させるため、 ::nth-fragment() 擬似要素内の宣言は、 擬似要素を持たない規則内の宣言を上書きします。 このような宣言間の相対的な優先順位は、 通常のカスケード順序によって決定されます（[CSS2]を参照）。

::nth-fragment() 擬似要素で指定されたスタイルは、 断片ボックス内の内容への継承に影響します。 言い換えると、断片ボックス内の内容は、 要素から直接継承するのではなく、 断片ボックスのスタイル（すなわち、擬似要素のスタイル）から継承しなければなりません。 これは、複数の断片ボックスに分割された要素では、 要素の部分ごとに異なるスタイルを持つ場合があることを意味します。

この継承規則により、 直接指定できないスタイルを 間接的に指定できます （明示的な inherit を使用するか、::first-letter に適用されないプロパティで 既定の継承を使用します）。 これは、次の節の規則に基づけば、 直接指定することはできません。 これは問題です。 断片内部のスタイル指定に適用される制限は、 断片からの継承にも適用するべきです。

<!DOCTYPE HTML><style>
  .article {
    continue: fragments;
  }
  .article::nth-fragment(1) {
    font-size: 1.5em;
    margin-bottom: 1em;
    height: 4em;
  }
  .article::nth-fragment(2) {
    margin-left: 5em;
    margin-right: 2em;
  }
</style>
<div class="article">
  <code>font-size</code> プロパティ...
</div>

断片内部のスタイル指定

これは continue:fragments のみに適用するべきでしょうか、 それとも continue:paginate にも適用するべきでしょうか？

::nth-fragment() 擬似要素は、 断片 ボックス内の内容に スタイルを指定するためにも使用できます。 ::first-line および ::first-letter 擬似要素とは異なり、 ::nth-fragment() 擬似要素は、 主体以外のセレクター部分にも 適用できます。 特に、主体の祖先と一致できます。 ただし、このようなセレクターを持つ規則によって 適用される CSS プロパティは、 ::first-letter 擬似要素に 適用されるものだけです。

より正確には、 規則のセレクターで、主体以外のセレクター部分に ::nth-fragment() 擬似要素が付加されている場合、 その規則内の宣言は、次の条件を満たすときに 断片（またはその擬似要素）へ適用されます:

1. 宣言が、::first-letter 擬似要素に適用されるプロパティに関するものであり、
2. それらの ::nth-fragment() 擬似要素を削除した場合に、 各単純セレクター列と、 それが一致する要素との間に特定の関連付けを持って、 宣言がその断片（またはその擬似要素）に 適用されるものであり、
3. 削除された各 ::nth-fragment() 擬似要素について、 その断片が、擬似要素の付加先セレクターに 当該関連付けで関連付けられた要素の断片ボックス内に存在し、 そのインデックスが擬似要素と一致すること。

<!DOCTYPE HTML><style>
  .dark-columns {
    continue: fragments;
    width: 6em;
    height: 10em;
    float: left;
    margin-right: 1em;
    font: medium/1.25 Times New
      Roman, Times, serif;
  }
  .dark-columns::nth-fragment(1) {
    background: aqua; color: black;
  }
  .dark-columns::nth-fragment(1) :link {
    color: blue;
  }
  .dark-columns::nth-fragment(1) :visited {
    color: purple;
  }
  .dark-columns::nth-fragment(2) {
    background: navy; color: white;
  }
  .dark-columns::nth-fragment(2) :link {
    color: aqua;
  }
  .dark-columns::nth-fragment(2) :visited {
    color: fuchsia;
  }
</style>
<div class="dark-columns">
  ...
</div>

附属書 B: scrollbar-gutter の拡張候補

この節は非規範的です。

この節では、 追加のユースケースを解決するために、 scrollbar-gutter プロパティを 拡張しようとする現在の試みを記録しています。 ただし、現時点では合意が得られていません。 議論を促すためにここで提示していますが、 非実験的な実装は推奨されません。

この例では、 scrollbar-gutter プロパティの追加値をすべて使用します:

• ヘッダー/ツールバーの scrollbar-gutter: always force

• スクロールコンテナーの scrollbar-gutter: always

• スクロールコンテナー内の各行の scrollbar-gutter: match-parent

名前:	scrollbar-gutter
新しい値:	auto | [ [ stable | always ] && both-edges? && force? ] || match-parent
適用対象:	すべての要素

オーバーレイスクロールバーでは、 スクロールバーガターが存在する場合、その正確な幅は UA によって定義されます。 ただし、0であってはならず、 スクロールバー自体が変化する場合でも、ページまたはスクロールバーに対するユーザー操作に基づいて 変化してはなりません。 これは、明確に定義できる範囲において、 最も幅が広い状態のオーバーレイスクロールバーの 幅を覆うことを想定しています。

このプロパティの新しい値の意味は次のとおりです:

always

overflow が scroll、hidden、または auto の場合、 スクロールバーの種類や ボックスがオーバーフローしているかどうかにかかわらず、 スクロールバーガターが常に存在します。

scrollbar-gutter: always は、 要素の辺付近にある（小さな）対話型要素が 表示されたオーバーレイスクロールバーに覆われる問題を 解決するために使用できます。 代表的な例は基本的な ToDo リストです。 各行はテキストで始まり、右揃えされたチェックボックスで終わります。 クラシックスクロールバーでは問題ありませんが、 オーバーレイスクロールバーはチェックボックスを覆い、操作しにくくする可能性があります。

オーバーレイスクロールバーは通常一時的であり、操作されていないときは消えるため、 覆われたチェックボックスがまったく使用できなくなるわけではありません。 ただし、スクロールバーが表示されると操作を妨げ、 不自然な操作感になります。 作者は右側にパディングを追加して問題を解決しようとするかもしれませんが、 （1）どれだけ追加するべきでしょうか？ また（2）クラシックスクロールバーの場合、そのパディングは必要ありません。scrollbar-gutter: always はこの問題を解決し、 クラシックスクロールバーの場合は最初の例と同じ結果を保ちながら、 オーバーレイスクロールバーでは必要なガターを追加します:

Apple はこの値の追加に消極的です。 作者がこの値を広範に使用しすぎて、 対話型要素によって正当化されない場合でもオーバーレイスクロールバー用のガターを挿入し、 オーバーレイスクロールバーによる空間節約の利点を損なう可能性があるためです。

代替の解決策が提案されています: 焦点となるのは対話型要素であるため、 スクロールバーの下に配置されることを回避する必要がある 要素へ適用するプロパティを用意できるかもしれません。 有効にすると、必要に応じて要素の右または左のマージンを 適切な値だけ拡大し、 オーバーレイスクロールバーの下に配置される場合は、そこから要素を押し出します。 それ以外の場合、要素は変更されません。

追加の切り替えによって、 要素の inline-end と inline-start の両方のマージンを拡大するか、 どちらも拡大しないようにできる可能性もあります。 これは、可視の境界線または背景を持つ スクローラーのブロックレベルの子孫で特に役立つ可能性があります: オーバーレイスクロールバーとの衝突を避けるために一方の側へ空間を追加すると、 スクロールバーが消えたときに中央からずれて見えます。 両側のマージンを増やすことで、これを回避できます。

さらに別の可能性として、要素を保護するためにマージンを拡大するか、 要素の内容を保護するためにパディングを拡大するかを選択できるようにすることが考えられます。

構文は、たとえば scrollbar-avoid: none | [self | content] && both-edges? のようなものにできます。

興味深い点として、これにより scrollbar-gutter: match-parent の必要性が 軽減される可能性があります。 親に scrollbar-gutter: stable または scrollbar-gutter: always を、 選択した子に scrollbar-gutter: match-parent を指定して対処する状況は、 代わりに親を scrollbar-gutter: auto のままにし、 関連する子に scrollbar-avoid: self または scrollbar-avoid: content を使用することで 対処できるように思われます。

force

force キーワードが存在する場合、 overflow が auto または scroll の場合に加え、 visible、hidden、または clip の場合にも、stable および always が効果を持ちます。 これによってスクロールバーが表示されるわけではなく、スクロールバーガターのみが表示されます。

この値を使用すると、作者は スクローラーに隣接する要素の辺に、 スクローラー自体で確保されているものと同じ量の空間を確保し、 内容を視覚的に揃えることができます。 クラシックスクロールバーの場合にパディングを追加し、オーバーレイスクロールバーの場合には追加しないことでも、 同じ効果を実現できます。 ただし、この値がなければ、作者がパディングを追加するべきかどうか、 また追加する場合はどれだけ追加するべきかを確実に判断する方法がありません。

具体的な例は、執筆時点の Gmail の UI で確認できます: Gmail は、メール一覧の上にあるツールバー内のコントロールを 一覧内のコントロールと揃えようとしますが、 必ずしも成功しません。 次に2つのスクリーンショットを示します。 1つはクラシックスクロールバーを有効にしたもの（OS レベル）で、 Gmail は一覧の上にあるツールバーへ追加するべきパディングの量を正しく推測しています。 もう1つはオーバーレイスクロールバーを有効にしたもので、 Gmail は誤ってパディングを追加し、 配置をずらしています （議論している点を強調するために、オレンジ色の点線を手動で追加しています）。

ツールバー内のこの間隔を パディングではなく scrollbar-gutter: stable force で作成すれば、 どちらの場合でもアイコンの配置を維持できます。 また、スクロールバーのサイズが一般的でないシステムでも配置を維持できます。

この値のために、 このプロパティはスクロールコンテナーだけではなく、 すべての要素に適用されるようになっています。 これにより、例に示す overflow: visible 要素にも適用できます。 ユーザーエージェントは既存のコードだけに依存してガターを配置できず、 これまでガターを持てなかった要素にも配置する必要があるため、 実装が困難になる可能性があります。 overflow が適用されるすべての要素に制限しても、 ユースケースへの悪影響はおそらくなく、 実装を容易にできる可能性があります。 ただし、それでもスクロールコンテナーだけに 制限するより難しい可能性があります。

上記の 実装上の課題に加えて、 この値が意図するほど確実に問題を解決できるかは明確ではありません。 スクロールバーとそのガターのサイズおよび側は UA によって定義されるため、 要素ごとに異なる可能性があります。 スクロールバーの外観と位置はユーザーエージェントに委ねられるため、 それらに影響を与える可能性のあるプロパティの一覧に制限はありません。 direction（HTML の dir 属性の設定を通じて）や scrollbar-width などのプロパティを設定すれば、 要素がスクロール可能である場合にユーザーエージェントがどのようなスクロールバーを作成するかを 判断するための十分なコンテキストが得られ、 適切な場所に同じサイズのガターを作成できる可能性はありますが、 保証はできません。

仕様の初期の 版では、 この値が例で説明した効果を実現する唯一の方法でした。 しかし、その後、scrollbar-gutter: stable が overflow: hidden 要素に適用されるようになりました。 overflow: hidden の適用には、 このコンテキストでは望ましくない可能性がある他の効果もありますが、 scrollbar-gutter: stable と overflow: hidden の 組み合わせは、scrollbar-gutter: stable force と同じ方法で間隔を追加します。 また、特に上記の他の問題を考慮すると、 十分な回避策になる可能性があります。

match-parent

親がスクロールバーガター（または両方の辺にガター）を持つブロックレベルボックスでは、 ボックスが親のガターと同じ側に、同じ幅の スクロールバーガターを持つようになります。 さらに、 そのガターは親ボックスのガターと重なるようになります。

scrollbar-gutter: match-parent を持つボックスが、 ガターが想定される側にゼロでない 境界線またはマージンを持つ場合、 そのボックスのガターのサイズは parent.gutter - child.border - child.margin となり、 ガター+境界線+マージンが親のガターと重なります。

scrollbar-gutter/ match-parent を持つボックス自体がスクロールコンテナーである場合、 スクロールバーの種類、 その overflow プロパティ、 および scrollbar-gutter プロパティの他の値によっては、 自身のスクロールバー用に追加のガターが必要になる場合があります。 これは、match-parent 値のために追加されるガター量とは別に追加され、 親のガターとは重なりません。

注: 次の表は、異なる種類のスクロールバーにおける overflow と scrollbar-gutter の相互作用を要約し、 どの場合にスクロールバーガター用の空間が確保されるかを示します。

スクロールバーガター用の空間を確保するべきか？

overflow	scrollbar-gutter	クラシックスクロールバー		オーバーレイスクロールバー （オーバーフローしているかどうかにかかわらず）
		オーバーフローしている	オーバーフローしていない
scroll	auto	はい	はい
	stable	はい	はい
	always	はい	はい	はい
auto	auto	はい
	stable	はい	はい
	always	はい	はい	はい
hidden	auto
	stable	はい	はい
	always	はい	はい	はい
visible, clip	auto
	stable	force の場合	force の場合
	always	force の場合	force の場合	force の場合

附属書 C: プライバシーに関する 考慮事項

この仕様では、プライバシーに関する新たな考慮事項は導入されません。

附属書 D: セキュリティに関する考慮事項

この仕様では、セキュリティに関する新たな考慮事項は導入されません。

変更点

最近の変更点

2017年6月の 作業草案以降の主な変更点は次のとおりです:

• [CSS-UI-4]から text-overflow の定義を移動しました。
• scrollbar-gutter の中核となる定義を [CSS-OVERFLOW-3] へ移動し （この仕様が差分仕様でなくなった時点で、ここへコピーして戻されます）、 実験的な scrollbar-gutter の拡張案を附属書へ移動しました。
• overflow および overflow-clip-margin を置換要素にも適用する拡張を定義しました。 これが正確にどのように機能するかについては、現在も引き続き 議論中です。 （課題 7144）
• overflow-clip-margin の個別指定プロパティを定義しました。 （課題 7245）

レベル 3 以降の変更点

未定

謝辞

特に、 Rossen Atanassov、 Bert Bos、 Tantek Çelik、 John Daggett、 fantasai、 Daniel Glazman、 Vincent Hardy、 Håkon Wium Lie、 Peter Linss、 Robert O’Callahan、 Florian Rivoal、 Alan Stearns、 Steve Zilles、 およびその他すべての www-style コミュニティからのフィードバックに感謝します。