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

1. はじめに

この仕様は、[CSS-OVERFLOW-3]を拡張します。 主なセクションは以下の通りです：

オーバーフローのスクロールと切り取り制御

このセクションでは、overflow-*プロパティ レベル3への比較的シンプルな拡張を定義します。

自動省略記号

このセクションでは、*-ellipsisプロパティ レベル3への実験的な拡張を定義します。

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

このセクションでは、オーバーフローを新しく生成されたフラグメンテーションコンテナへリダイレクトするための、 非常に実験的な新しいモデルを定義します。

注意: 本文執筆時点では、[CSS-OVERFLOW-3]はまだ完全には確定していません。 意図しない分岐や保守の負担を避けるため、 この仕様はcss-overflowレベル3の差分仕様として記述されています。 レベル3仕様が最終確定したら、その内容は本仕様に統合され、 本仕様がレベル3を置き換えることになります。 それまでの間、本仕様にはレベル3への追加・拡張のみが含まれます。

1.1. 値の定義

この仕様は、CSSプロパティ定義の慣例（[CSS2]）に従い、 値定義構文（[CSS-VALUES-3]）を使用しています。 この仕様で定義されていない値型は、CSS Values & Units [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となります。 ホスト言語は、UAスタイルシートの規則を定義し、 そのような要素に対してデフォルト値としてclipを適用し、 overflow-clip-marginをcontent-boxに設定する必要があります。

注意: overflowの置換要素への適用は、 画像がレイアウトボックスの外側に効果を描画できるようにするために追加されました。 推奨されるUAスタイルシートの規則は、デフォルトで元の挙動を実現するためのものです。 詳細はIssue 7059やIssue 7144の議論を参照してください。 これはCSS2.1からの変更点であり、リスクがあります。

overflowの置換要素への適用は、まだ調整中です。[Issue #7144]

3.2. 切り取り範囲の拡張：overflow-clip-margin-*プロパティ

これらのプロパティおよびその略記は、 ボックスのオーバーフロークリップ端を定義します。 つまり、ボックスの境界からどれだけ外側まで ボックスの内容が描画可能となり、 どの時点で（overflow: clipなどの） 効果によってクリップされるかを正確に決定します。 オーバーフロークリップ端でクリップすることが定義されている効果に該当します。 略記/ロングハンドの関係は、 marginと同様ですが、 略記には制限された構文がありますので注意してください。

値の定義は以下の通りです：

<visual-box>

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

省略した場合、 置換要素でない場合はpadding-box、 置換要素の場合はcontent-boxがデフォルトとなります。

overflow-clip-marginの置換要素への適用は、まだ調整中です。[Issue #7144]

<length [0,∞]>

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

オーバーフロークリップ端の角の形状は、 ボックスの境界端から同じ累積オフセット分だけ広がった 外部ボックスシャドウと まったく同じ方法で形作られます。 CSS Backgrounds 3 § 4.2 Corner Shaping および CSS Backgrounds 3 § 6.1.1 シャドウの形状・広がり・ノックアウトを参照し、 特に境界端を超えるアウトセットの式に注意してください。

注意: このプロパティは overflow: hiddenやoverflow: scrollのボックスには効果がありません。 それらはオーバーフロークリップ端を使うことが定義されていません。

4. 自動省略記号

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

このセクションは[CSS-OVERFLOW-3]に再同期が必要な場合があります。

このプロパティは、インラインコンテンツが、そのブロックコンテナ要素（「ブロック」）のインライン進行方向のラインボックス端をオーバーフローする際、 overflowがvisible以外である場合の描画を指定します。

このプロパティは継承されませんが、 ラインボックスのインライン整形コンテキストを確立するために生成される匿名ブロックコンテナボックス（block container参照）は無視され、 実際に適用されるプロパティ値は非匿名ボックス上のものとなります。これは例7の「入れ子段落」部分で確認できます。 「NESTED」という語が匿名ブロックコンテナにラップされ、その text-overflowプロパティが初期値であっても、省略記号が表示されています。

テキストがオーバーフローするのは、例えば折り返し禁止（white-space: nowrap）や、単語が長すぎて収まらない場合です。 各値の意味は次の通りです：

clip

オーバーフローしたインラインコンテンツをブロックコンテナ要素でクリップします。 文字が部分的に描画される場合があります。

ellipsis

切り取られたインラインコンテンツを表すため、エリプシス文字（U+2026）を描画します。 実装によっては、より言語・スクリプト・書字方向に適した省略記号を代用したり、 エリプシス文字が利用できない場合は「...」で代用することもあります。

<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つの場合は、1つ目がline-left端に、 2つ目がline-right端に適用されます。 end、line-left、line-rightの用語定義は[CSS-WRITING-MODES-3]を参照してください。

注意:値が2つの場合にline-leftやline-rightを使う理由は、startやend ではなく、矢印などの方向性文字の利用を容易にするためです。

ellipsisやstring値の場合、 実装は、必要に応じて該当端の文字や原子的インラインレベル要素を隠し、 省略記号／文字列を残りインラインコンテンツの端に直ちに隣接して配置する必要があります。 行の先頭の文字や原子的インラインレベル要素は、 省略記号でなくクリップされる必要があります。

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

省略動作の詳細

• 省略はレンダリングのみに影響し、レイアウトやポインターイベントの送出には影響しません： UAは、省略記号上で発生したポインターイベントを、text-overflowがnoneであったかのように elided要素へ送出すべきです。
• 省略記号はブロックに従ってスタイル及びベースライン整列されます。
• 省略は相対位置指定や他のグラフィック変形の後に発生します。
• 省略記号のための十分なスペースがない場合、 省略記号自体の描画をクリップします （その側で、行上の中立文字がtext-overflow:clip値と同様にクリップされたはずの側）。

省略記号とのユーザー操作

• ユーザーがコンテンツを操作している場合 （編集・選択・スクロール等）、 ユーザーエージェントはellipsis、string値、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 IS AWESOME, YES
</div>

<div style="text-overflow:clip; overflow:hidden">
CSS IS AWESOME, YES
</div>

<div style="text-overflow:ellipsis; overflow:hidden">
CSS IS AWESOME, YES
</div>

<div style="text-overflow:ellipsis; overflow:hidden">
NESTED
 <p>PARAGRAPH</p>
WON’T ELLIPSE.
</div>

<div style="text-overflow:fade; overflow:hidden">
CSS IS AWESOME, YES
</div>

注意:省略記号が配置される側は、ブロックのdirectionに依存します。 例：overflow hiddenで右から左（direction: rtl）のブロックは、インラインコンテンツを左側でクリップし、 省略記号は左側に配置され、クリップされた内容を表します。

この注意の図示用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 is awesome, especially when you can scroll
to see extra text instead of just
having it overlap other text by default.
</div>

内容の一部がスクロールで表示されると、他の部分が反対側で表示外になることがあります。 その内容のブロックコンテナ要素がスクロールしている要素自身であり、 text-overflowの算出値が2つで、開始端の値が非clip値の場合、 実装はクリップされた内容の代わりに省略記号／文字列を描画しなければなりません。 詳細は前述の値定義と同じですが、ここでは省略記号／文字列はブロックのdirection（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 Leading and half-leading参照）。 テキストの整列とジャスティフィケーションは配置後に行われ、 省略記号も行内容と一緒に測定対象となります。

注意: ブロックオーバーフロー省略記号の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 "… (continued on next page)";
}
strong {
  display: block;
  text-transform: uppercase;
}

<li><a href="cheese-is-milk">
  <strong>Cheese is Actually Made of Milk!</strong>
  Investigative reporters at the World Wide Web Press Corps
  have discovered the secret of cheese.
  Tracing through byzantine layers of bureaucracy and shadow corporations,
  our crack team of journalists have traced the source of camembert.
</a></li>

+---------------------------------------+
| CHEESE IS ACTUALLY MADE OF MILK!      |
| Investigative reporters at the World  |
| Wide Web Press Corps have discovered  |
| the secret of cheese. Tracing through |
| byzantine…  (continued on next page)  |
+---------------------------------------+

5.1.1. レガシー互換性

レガシーなコンテンツとの互換性のため、 line-clampをサポートするUAは、-webkit-line-clampプロパティと、 -webkit-discardという追加値を continueプロパティに対してもサポートしなければなりません。

line-clampと同様に、-webkit-line-clampは max-lines、continue、block-ellipsisの略記ですが、以下が異なります：

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

• continueを-webkit-discardに設定し、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: line 1<br>
  a: line 2<br>
  <div id=b>
    b: line 1<br>
    b: line 2<br>
    b: line 3<br>
    b: line 4<br>
  </div>
  a: line 3<br>
  a: line 4<br>
</div>

a: line 1
a: line 2
b: line 1
b: line 2…
a: line 3…

a: line 1
a: line 2
b: line 1…

注意: max-linesは マルチカラムコンテナには効果がありません。 なぜなら、それらが持つラインボックスはすべて 独立整形コンテキストの中にネストされているからです。

正の整数のみ受け付けます。 0や負の整数は無効であり、 宣言は無視されなければなりません。

注: widows、orphans、break-insideプロパティは、region break（max-linesプロパティによって導入される強制的な改段） の位置には影響しません。

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

continueプロパティは、著者がボックスを断片化コンテナ（[CSS-BREAK-3]参照）に変換し、 断片化分割以降の内容を破棄するよう指定するためのものです。

このプロパティは region-fragmentプロパティ（[CSS-REGIONS-1]）の一般化・置換を目的としています。 本仕様で十分に安定したら、regions仕様から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への影響が明確であること [Issue #2970]

• 位置指定要素のstatic位置が破棄された内容内の場合は描画されない？ Sydney F2F会議議事録も参照。 [Issue #2971]

ただし、内在サイズは断片化コンテナをまたいで算出されるため、 この内容もボックスのmin-contentやmax-content インラインサイズ（CSS Fragmentation 3 § 5.1 可変サイズの断片化ボックスへの分割参照）算出時に考慮されます。min-contentとmax-content ブロックサイズは、 断片化フローの開始から最初の強制分割まで、 または強制分割がなければ断片化フローの末尾までの内容を基に算出されます。

注意: 並列断片化フローの場合、 ボックスツリー内で断片化分割以降に現れる内容も、 その位置がこの断片化コンテナの末尾となる位置より上にレイアウトされる場合は 描画されることがあります。

付録A: オーバーフローのリダイレクト

このセクションは非常に実験的です。 continueプロパティの拡張による新しいユースケースへの対応を記録しています。 しかし現時点では合意に至っていません。 議論を促進するためにここに掲載されており、 実験的でない実装は推奨されません。

CSSレベル1 [CSS1]では、指定されたサイズの要素内に収まらない内容を配置することは、 一般的に著者側の誤りとされていました。 こうすると内容が要素の境界外にはみ出し、 他の要素と重なってしまうことが多くなります。

CSSレベル2 [CSS2]では、overflowプロパティが導入され、 スクロールによるオーバーフロー処理が可能となり、もはや著者側の誤りとはされなくなりました。 また、オーバーフローをクリップ処理する指定も可能となり、 著者の意図が内容を表示しない場合に理にかなっています。 この領域はCSS Overflow Module Level 3 [CSS-OVERFLOW-3]で更に洗練されました。

しかし、スクロールは内容を表示する唯一の方法ではなく、 必ずしも最適な方法であるとも限りません。 コデックスが巻物に取って代わったのも、その利点によるものです。

本仕様は、Webページの要素がスクロールではなくページ分割でオーバーフローを処理できる仕組みを導入します。

また本仕様は、オーバーフローの概念をさらに拡張します。 著者が要素内容を流し込む単一領域のみ指定を求めるのではなく、 複数の断片をそれぞれ独自の寸法やスタイルで指定できるようにし、 内容が次々に流れていくことで、オーバーフローせず配置できるようにします。

いずれの場合も、実装はブロック進行方向で内容を分割する必要があります。 この分割方法はCSS Fragmentation Module [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をregions仕様から削除し、このプロパティに統合すべきです。

注意: continue: fragmentsは 以前の仕様の"overflow:fragments"を置き換えたもので、 continue: paginateは "overflow: paged-x | paged-y | paged-x-controls | paged-y-controls"を置き換えています。

auto

autoは、要素がCSS Regionであり、region chain内の最後でない場合のみ算出値として現れます。 収まりきらない内容はチェーンの次のリージョンに送られます。

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

これは§ 5.3 オーバーフローの断片化：continueプロパティでの定義とは異なります。どちらのモデルが適切か？

overflow

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

paginate

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

ページ分割オーバーフローを参照

注意: 印刷は、ルートで「continue: paginate」とみなせます。

fragments

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

断片化オーバーフローを参照。

continueプロパティの算出値は以下の通り決定されます：

1. レイアウト封じ込めを持つ要素または疑似要素の場合、 指定値がautoまたはfragmentsなら 算出値はoverflowとなります。
2. それ以外で指定値がautoの場合
   1. CSS Regionでregion chain内の最後でなければ 算出値はauto
   2. ページ上なら 算出値はpaginate
   3. fragment boxなら 算出値はfragments
   4. それ以外は算出値はoverflow
3. それ以外で指定値がfragmentsの場合
   1. ページ上なら 算出値はpaginate
   2. それ以外は指定値がそのまま算出値
4. その他の場合は指定値がそのまま算出値

multicolのカラムを選択できる疑似要素を導入する場合、 autoがその上ではautoになるように指定する必要があるか、 新しい値を追加してautoがそれに算出されるようにする必要があるかもしれません （ただしそれがカラム以外には何になるか？）。

注意: このプロパティの背景議論は以下スレッドを参照：overflow, overflow-x, overflow-y, overflow-styleの議論、fragmentationプロパティ提案

ページ分割オーバーフロー

このセクションは、paginate値と continueプロパティの意味を定義します。

このセクションの執筆が必要

ページは@pageルールでスタイル指定可能にすべき。ネストしたページにどう適用する？

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

従来のページ分割（例：印刷時）は :rootがpage box内に含まれることを前提としており、 page boxが:rootの疑似要素子になるのではない。 fragment box類似で回避できるか？ それともpage box内にfragment box（:rootを再現）が入り、そのpage boxが:root内にあるモデル？

page boxモデルが通常のcss boxの子になった場合、どのように動作するか？

[CSS3GCPM]初期案およびOperaの実装は paginateの代わりに4値 "paged-x | paged-y | paged-x-controls | paged-y-controls"を使っていた。 このプロパティにもこれらの値を含めるべきか、 それとも別プロパティで扱うべきか？ （例："pagination-layout: auto | horizontal | vertical", "pagination-controls: auto | none"）

1ページだけでなく複数ページ同時表示の能力は？ "pagination-layout: horizontal 2;"のような値で可能か？

Brad Kemperによるページ分割と断片化オーバーフローの統合モデル提案あり。複数ページ表示も考慮。 https://www.w3.org/mid/FF1704C5-D5C1-4D6F-A99D-0DD094036685@gmail.com

ページ分割オーバーフローは現在、 overflow/overflow-x/overflow-yプロパティで実装されており、 [CSS3GCPM]ドラフトや [CSS3-MARQUEE]提案で提案されている overflow-styleプロパティや、ここで説明されているcontinueプロパティとは異なる。

断片化オーバーフロー

このセクションは、fragments値とcontinue プロパティの意味を定義します。

要素のcontinue算出値がfragmentsで、 実装がその要素にボックスを生成する場合、 実装はその要素のために一連の断片ボックスを生成しなければなりません。 （continue: fragmentsを持つ要素が 断片ボックスを1つだけ生成する場合もあります。 ただし、要素の算出continueが fragmentsでなければ、 そのボックスは断片ボックスではありません。） すべての断片ボックスは断片化コンテナであり、 その断片化コンテナが断片化される原因となるオーバーフローは、 前の断片ボックスの次の兄弟として さらに断片ボックスを生成させます。 それは要素の次の兄弟として生成されるか？他のボックスレベルの修正との正確な関係要検討。 さらに、断片ボックスが [css-multicol-1]で定義されるマルチカラムボックスである場合、 ただし定義はmulti-column container overflow columnsになるはずだった内容は 追加の断片ボックスに流し込まれます。 ただし、断片ボックス自体も外部の断片化コンテキスト（ページ・カラム・他の断片ボックス等）による断片化で分割される場合があります。 その場合、同じ断片ボックスの断片が複数生成され、 複数の断片ボックスではなくなります。 （これは断片ボックスがインデックスでスタイル指定される場合に重要です。 ページ分割で断片ボックスを分割しても、インデックスと内容の関係が維持されるようにするためです。） 強制分割が外部断片化コンテキストへ分割した場合、単一断片ボックスの新しい断片か、新しい断片ボックスか？ ここで断片ボックス以外の用語にした方が分かりやすい？

要素が他の断片化コンテキスト内で分割された部分をスタイル指定したい場合はどうする？ このルールでは::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内のテキストが
  一連のカードに分割されます。
  これらのカードはすべて同じスタイルです。
  十分な内容があれば、カードが
  オーバーフローし、さらに
  カードが生成されます。2番目の
  カードは最初のカードの
  次の兄弟として生成されます。
</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など他の値は指定可能ですが、 内側のdisplay型は変更できません。 （continueはブロックコンテナ・flexコンテナ・gridコンテナにのみ適用されます。）詳細な動作仕様が必要

他の疑似要素と同様、疑似要素は対応する要素の中に存在するため、 ::nth-fragment()疑似要素への宣言は 疑似要素無しルールの宣言より優先されます。 優先度は通常のカスケード順で決定されます（[CSS2]参照）。

::nth-fragment()疑似要素上のスタイルは、 断片ボックス内の内容への継承に影響します。 つまり、断片ボックス内の内容は 断片ボックス（疑似要素）のスタイルから継承し、要素から直接継承しません。 これにより、1つの要素が複数断片ボックスに分割された場合、部位ごとに異なるスタイルとなることがあります。

この継承ルールにより、 直接指定できないスタイル（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">
  The <code>font-size</code> property...
</div>

断片内部のスタイリング

これはcontinue:fragmentsのみに適用すべきか、 continue:paginateにも適用すべきか？

::nth-fragment()疑似要素は 断片ボックス内部の内容にも スタイル指定に利用できます。 ::first-lineや::first-letter疑似要素と異なり、 ::nth-fragment()疑似要素は セレクタの主題以外の部分にも適用できます。 ただし、そういったセレクタで適用できるCSSプロパティは ::first-letter疑似要素に適用できるものに限られます。

より厳密には、 セレクタの主題以外の部分に ::nth-fragment()疑似要素が付いている場合、 そのルールの宣言は、断片（またはその疑似要素）に対して以下を満たすとき適用されます：

1. 宣言が::first-letter疑似要素に適用できるプロパティであること
2. 疑似要素無しでそのルールが その断片（またはその疑似要素）に適用されること
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
適用対象:	すべての要素

オーバーレイスクロールバーの場合、 scrollbar gutterの正確な幅はUAによって定義されます。 ただし、0であってはならず、 ページやスクロールバーに対するユーザー操作によって変化してはならず、 スクロールバー自体が変化した場合でも、 オーバーレイスクロールバーの最も広い形の幅をカバーすることが期待されます。 ただし、これは明確に定義されている範囲内でです。

このプロパティの新しい値の意味は以下の通りです:

always

scrollbar gutterは、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キーワードが指定されている場合、stableとalways はoverflowがvisible、hidden、またはclipの場合にも auto や scrollと同様に有効になります。 これはスクロールバー自体を表示するものではなく、scrollbar gutterを表示するものです。

この値により、作者はスクローラーに隣接する要素の端にも、 スクロール領域と同じスペースを確保し、コンテンツを揃えることができます。 クラシックスクロールバーのためにパディングを追加し、オーバーレイスクロールバーでは追加しないことで同じ効果も得られますが、 作者がパディングを追加すべきかや、その量を知る手段がありません。

具体例として（執筆時点）、GmailのUIに見られます: OSレベルでクラシックスクロールバーが有効な場合は、Gmailはツールバーに正しいパディングを追加し、 メールリスト内のアイコンと揃えています。一方で、オーバーレイスクロールバーの場合はパディングが誤って追加され、 （オレンジの点線は議論の箇所を強調するために手動で追加）揃いません。

ツールバーのスペース調整を scrollbar-gutter: stable forceで行えば、 両方のケースやスクロールバーのサイズが異なるシステムでもアイコンの位置が揃います。

この値があるため、 プロパティは単なるスクロールコンテナだけでなく、 すべての要素に適用されるようになりました。 これにより、overflow: visibleな要素にも適用できます（例参照）。 ただし、これは実装上の困難を招く可能性があり、 UAは既存コードに頼ってガターの配置ができず、従来ガターを持てなかった要素にも対応しなければなりません。 overflowが適用できるすべての要素に制限すれば、 ユースケースには影響なく、実装も容易になるかもしれません。 それでも、スクロールコンテナに限定するよりは難易度が高い可能性があります。

上記の実装課題以外にも、 この値が意図通りに問題を確実に解決するかは不明です。 スクロールバーやガターのサイズ・位置はUAの定義によって異なり、 要素ごとに変化する可能性があります。 スクロールバーの外観や位置はUAが決定するため、 それに影響するプロパティのリストには制限がありません。 direction（HTMLのdir属性経由）や scrollbar-widthなどを設定すれば、 UAが要素にスクロールバーを作成した場合の位置やサイズを把握でき、 適切なガターを配置できるかもしれませんが、保証はできません。

仕様の初期段階では、 この値が例示した効果を達成する唯一の手段でした。 しかし、その後scrollbar-gutter: stableが overflow: hidden要素にも適用できるようになりました。 overflow: hiddenには他に望ましくない効果もありますが、 scrollbar-gutter: stableと overflow: hiddenの組み合わせでも scrollbar-gutter: stable forceと同じようにスペースを追加でき、 上述の他の課題も考慮すると、十分な回避策となる可能性があります。

match-parent

親にscrollbar gutter（または両端にガター）があるブロックレベルボックスでは、 この値を指定すると、親のガターと同じ側・同じ幅のガターを持つようになります。 さらに、 ガターは親ボックスのガターと重なるようになります。

scrollbar-gutter: match-parentが指定されたボックスに ガター側に非ゼロのボーダーやマージンがある場合、 そのボックスのガターサイズはparent.gutter - child.border - child.marginとなり、 ガター＋ボーダー＋マージンが親のガターと重なります。

scrollbar-gutter/ match-parent が指定されたボックスが スクロールコンテナの場合は、 スクロールバーのタイプやoverflowプロパティ、 scrollbar-gutterプロパティの他の値によって、 独自のスクロールバー用の追加ガターが必要になる場合があります。 これは親のガターとは重ならず、追加で確保されます。

注記: 以下の表は、さまざまなスクロールバータイプにおけるoverflowとscrollbar-gutterの相互作用をまとめたものであり、 どの場合にscrollbar gutterのためにスペースが確保されるかを示しています。

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月の作業草案以降の主な変更点：

• text-overflow の定義を [CSS-UI-4] から移動しました。
• scrollbar-gutter のコア定義を [CSS-OVERFLOW-3] に移動しました（この仕様が差分解除されるときにここに戻されます）、 探索的な scrollbar-gutter 拡張アイデアは付録に移しました。
• overflow と overflow-clip-margin の定義を 置換要素 にも適用するよう拡張しました。 この動作の詳細は 現在も議論中です。 (Issue 7144)
• longhands を overflow-clip-margin に定義しました。 (Issue 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 コミュニティの皆様。