[css-overflow] Introduce the 'continue' property

All sections that previously refered to the 'fragments' and 'paged-*'
values of overflow are also patched up to use the 'continue' property
instead.

Author: frivoal

css-overflow/Overview.bs

@@ -464,76 +464,119 @@ Introduction</h2>
 		'overflow-x' and 'overflow-y' instead?
 	</p>
 
-<h2 id="fragmentation-properties">Fragmentation properties</h2>
+<h2 id="fragmentation">Fragmentation of overflow</h2>
 
-Issue: This section is a WIP, and currently just holds bits of information that need to be massaged into proper form.
+	<pre class=propdef>
+		Name: continue
+		Value: ''auto'' | ''overflow'' | ''paginate'' | ''fragments'' | ''discard'' | ''next'' 
+		Initial: ''auto''
+		Applies to: block containers [[!CSS21]], flex containers [[!CSS3-FLEXBOX]], and grid containers [[!CSS3-GRID-LAYOUT]]
+		Inherited: no
+		Percentages: N/A
+		Media: visual
+		Computed value: see below
+		Animatable: no
+		Canonical order: <abbr title="follows order of property value definition">per grammar</abbr>
+	</pre>
 
- | ''paged-x'' | ''paged-y'' | ''paged-x-controls'' | ''paged-y-controls'' | ''fragments''
+Issue: Naming is preliminary.
+This was initially proposed as
+"fragmentation: auto | none | break | clone | page"
+in <a href="https://lists.w3.org/Archives/Public/www-style/2015Jan/0357.html">https://lists.w3.org/Archives/Public/www-style/2015Jan/0357.html</a>
 
-	<p class="issue">
-		Are all 4 of the ''paged-*'' values really needed?
-	</p>
+Note: ''continue: fragments'' replaces "overflow:fragments"
+from earlier versions of this specification,
+while ''continue: paginate'' replaces "overflow: paged-x | paged-y | paged-x-controls | paged-y-controls"
 
-	<dl>
-		<dt><dfn>paged-x</dfn>
-		<dt><dfn>paged-y</dfn>
-		<dt><dfn>paged-x-controls</dfn>
-		<dt><dfn>paged-y-controls</dfn>
+Issue: The definitions below are vaguely worded, and need to be more specific.
+
+	<dl dfn-for="continue" dfn-type="value">
+		<dt><dfn>auto</dfn>
+		<dd>Behavior varies between the other values, depending on contex.
+		See the section below on computed values for details.
+
+		<dt><dfn>overflow</dfn>
+		<dd>Content that doesn't fit overflows, according to the 'overflow' property
+
+		<dt><dfn>discard</dfn>
+		<dd>Content that doesn't fit is discarded at a fragmentation break
+
+		Note: generalized from region-fragment: break; on the last region of a region chain
+		<dt><dfn>next</dfn>
+		<dd>Content that doesn't fit is pushed to the next region
+		if the element is part of a region chain,
+		or to the next page if the element is part of a page chain. If
+		there isn't a next region or page, it overflows.
+
+		Note: Behavior could have been to discard
+		but discarding anything should be a very explicit behavior
+
+		<dt><dfn>paginate</dfn>
+		<dd>Content that doesn't fit paginates.
+		This creates a paginated view inside the element
+		similar to the way that 'overflow: scroll' creates a scrollable view.
+
+		Pages can be styled with @page rules.
+
+		Note: Print is effectively "continue: paginate" on the root.
+
+		See <a href="#paginated-overflow">paginated overflow</a>
 		<dt><dfn>fragments</dfn>
-		<dd>
-			These values are collectively the <dfn dfn>fragmenting values</dfn>;
-			they are defined in the sections on
-			<a href="#paginated-overflow">paginated overflow</a> and
-			<a href="#fragment-overflow">fragment overflow</a>.
-		</dd>
+		<dd>content that doesn't fit causes the element to copy itself and continue laying out.
+		See <a href="#fragment-overflow">fragment overflow</a>.
 	</dl>
 
-	<div class="issue">
-		Having split the overflow and fragmentation properties, this issue is no longer relevant, but there are
-		useful bits of information in the thread, so I am leaving it here for now.
-
-		There are <a href="http://lists.w3.org/Archives/Public/www-style/2012May/1197.html">discussions</a>
-		about how overflow, overflow-style, overflow-x and overflow-y
-		should work and interact with each other.
-		Until consensus on this topic is reached,
-		it is not completely clear which of these
-		should be used for
-		paged-x | paged-y | paged-x-controls | paged-y-controls | fragments
-	</div>
+Issue: There is some overlap between overflow, discard and next.
+Only 2 of the 3 ever make sense in any situation,
+even though it isn't always the same two.
+It may be possible to reduce this to 2 values.
+An earlier proposal combined discard and next into break,
+although this had the downside of making discard a non explicit behavior.
 
+Note: For background discussions leading to this property, see these threads:
+<a href="http://lists.w3.org/Archives/Public/www-style/2012May/1197.html">discussion of overflow, overflow-x, overflow-y and overflow-style</a> and
+<a href="https://lists.w3.org/Archives/Public/www-style/2015Jan/0357.html">proposal for a fragmentation property</a>
 
 <h2 id="paginated-overflow">Paginated overflow</h2>
 
-<p class="issue">overflow:paginate or overflow:pages (or paged-x, paged-y, paged-x-controls, paged-y-controls as [[CSS3GCPM]] has?)</p>
+This section introduces and defines the meaning of the ''continue/paginate'' value of the 'continue' property.
+
+Issue: Write this section
 
-<p class="issue">Ability to display N pages at once
-rather than just one page at once?</p>
+Issue: The initial proposal in [[CSS3GCPM]] and implemantation from Opera
+used 4 values instead of ''continue/paginate'':
+"paged-x | paged-y | paged-x-controls | paged-y-controls".
+Should this property also include these values,
+or are they better handled as separate properties?
+(e.g.: "pagination-layout: auto | horizontal | vertical", "pagination-controls: auto | none")
+
+Issue: Ability to display N pages at once
+rather than just one page at once?
+Could this be a value of "pagination-layout", such as:
+"pagination-layout: horizontal 2;"
 
 	<p class="issue">
 		The current implementation of paginated overflow uses
 		the 'overflow'/'overflow-x'/'overflow-y' properties
 		rather than the 'overflow-style' property as proposed
 		in the [[CSS3GCPM]] draft
 		(which also matches the [[CSS3-MARQUEE]] proposal).
-		We should probably switch away from 'overflow-style',
-		but that's not 100% clear.
+		or the 'continue' property as described here.
 	</p>
 
 <h2 id="fragment-overflow">Fragment overflow</h2>
 
-	<p>
-		This section introduces and defines the meaning of
-		the new ''fragments'' value of the 'overflow' property.
-	</p>
+This section introduces and defines the meaning of
+the ''continue/fragments'' value of the 'continue' property.
 
 	<p>
-		When the computed value of 'overflow' for an element is ''fragments'',
+		When the computed value of 'continue' for an element is ''continue/fragments'',
 		and implementations would otherwise have created a box for the element,
 		then implementations must create a sequence of <dfn>fragment box</dfn>es
 		for that element.
-		(It is possible for an element with ''overflow: fragments''
+		(It is possible for an element with ''continue: fragments''
 		to generate only one <a>fragment box</a>.
-		However, if an element's computed 'overflow' is not ''fragments'',
+		However, if an element's computed 'continue' is not ''continue/fragments'',
 		then its box is not a <a>fragment box</a>.)
 		Every <a>fragment box</a> is a fragmentation container,
 		and any overflow
@@ -579,7 +622,7 @@ rather than just one page at once?</p>
   equal-sized cards&lt;/title&gt;
 &lt;style&gt;
   .in-cards {
-    overflow: fragments;
+    continue: fragments;
 
     width: 13em;
     height: 8em;
@@ -608,7 +651,7 @@ rather than just one page at once?</p>
 	</div>
 
 	<p class="issue">
-		We should specify that ''overflow: fragments'' does not apply
+		We should specify that ''continue: fragments'' does not apply
 		to at least some table parts,
 		and perhaps other elements as well.
 		We need to determine exactly which ones.
@@ -669,11 +712,11 @@ rather than just one page at once?</p>
 <h4 id="style-of-fragments">Styling of fragments</h4>
 
 	<p class="issue">
-		Should this apply to fragment overflow only,
-		or also to paginated overflow?
+		Should this apply to continue:fragments only,
+		or also to continue:paginate?
 		(If it applies,
 		then stricter property restrictions would be needed
-		for paginated overflow.)
+		for continue:paginate.)
 	</p>
 
 	<p>
@@ -704,7 +747,7 @@ rather than just one page at once?</p>
 		<table class="source-demo-pair"><tr><td><pre>&lt;!DOCTYPE HTML&gt;
 &lt;style&gt;
   .bouncy-columns {
-    overflow: fragments;
+    continue: fragments;
     width: 6em;
     height: 10em;
     float: left;
@@ -731,19 +774,15 @@ rather than just one page at once?</p>
 	</div>
 
 	<p>
-		Styling an ''::nth-fragment()'' pseudo-element with the 'overflow'
+		Styling an ''::nth-fragment()'' pseudo-element with the 'continue'
 		property does take effect;
 		if a <a>fragment box</a> has a
-		computed value of 'overflow' other than ''fragments''
+		computed value of 'continue' other than ''fragments''
 		then that fragment box is the last fragment.
-		However, overriding 'overflow' on the first fragment
+		However, overriding 'continue' on the first fragment
 		does not cause the <a>fragment box</a> not to exist;
 		whether there are fragment boxes at all is determined by
 		the computed value of overflow for the element.
-		<span class="issue">Need to reword this to refer to the
-		appropriate choice of 'overflow-x' or 'overflow-y',
-		and then point to rule about the handling of the other one
-		of 'overflow-x' or 'overflow-y'.</span>
 	</p>
 
 	<p>
@@ -767,8 +806,8 @@ rather than just one page at once?</p>
 		Specifying other values of 'display', 'position',
 		or 'float' is permitted, but is not allowed to change
 		the computed value of 'display-inside'.
-		(Since 'overflow', 'overflow-x', and 'overflow-y' only
-		apply to block containers, flex containers, and grid containers
+		(Since 'continue' only
+		applies to block containers, flex containers, and grid containers
 		the computed value of 'display-inside' is always
 		''display-inside/block'', ''display-inside/flex'', or
 		''display-inside/grid''.
@@ -811,7 +850,7 @@ rather than just one page at once?</p>
 		<table class="source-demo-pair"><tr><td><pre>&lt;!DOCTYPE HTML&gt;
 &lt;style&gt;
   .article {
-    overflow: fragments;
+    continue: fragments;
   }
   .article::nth-fragment(1) {
     font-size: 1.5em;
@@ -834,9 +873,8 @@ rather than just one page at once?</p>
 <h4 id="style-in-fragments">Styling inside fragments</h4>
 
 	<p class="issue">
-		Should this apply to fragment overflow only,
-		or also to paginated overflow,
-		or even to pagination across pages?
+		Should this apply to continue:fragments only,
+		or also to continue:paginate?
 	</p>
 
 	<p>
@@ -886,7 +924,7 @@ rather than just one page at once?</p>
 		<table class="source-demo-pair"><tr><td><pre>&lt;!DOCTYPE HTML&gt;
 &lt;style&gt;
   .dark-columns {
-    overflow: fragments;
+    continue: fragments;
     width: 6em;
     height: 10em;
     float: left;
@@ -993,7 +1031,7 @@ to pagination?</p>
 		<table class="source-demo-pair"><tr><td><pre>&lt;!DOCTYPE HTML&gt;
 &lt;style&gt;
   .article {
-    overflow: fragments;
+    continue: fragments;
   }
   .article::first-letter {
     font-size: 2em;
@@ -1020,7 +1058,7 @@ to pagination?</p>
 
 	<p class="issue">
 		This specification should define useful behavior
-		for all values of 'overflow'
+		for all values of 'overflow' and 'continue'
 		in static media (such as print).
 		Current implementation behavior is quite poor and
 		produces unexpected results when authors have not considered