• file
• revisions
• annotate
• diff
• comparison
• raw

css-overflow/Overview.bs@68f652c3f1eb (annotated)

css-overflow/Overview.bs

Thu, 08 Jun 2017 12:13:05 -0700

author

L. David Baron <[email protected]>

date

Thu, 08 Jun 2017 12:13:05 -0700

changeset 19383

68f652c3f1eb

parent 19381

dbe1da284fb5

child 19665

c018e0ea0721

permissions

-rw-r--r--

Make editor lines referring to me consistent, and include w3cid.

peter@16999	1	<h1>CSS Overflow Module Level 4</h1>
dbaron@15115	2	<pre class="metadata">
dbaron@15115	3	Status: ED
jackalmage@15674	4	Work Status: Exploring
peter@16999	5	ED: https://drafts.csswg.org/css-overflow-4/
dbaron@15115	6	Shortname: css-overflow
dbaron@15115	7	Group: csswg
florian@17019	8	Level: 4
peter@16999	9	TR: https://www.w3.org/TR/css-overflow-4/
peter@16999	10	Previous version: https://www.w3.org/TR/css-overflow-3/
dbaron@19383	11	Editor: L. David Baron, Mozilla https://www.mozilla.org/, https://dbaron.org/, w3cid 15393
git@18674	12	Editor: Florian Rivoal, On behalf of Bloomberg, http://florian.rivoal.net/
dbaron@15115	13	Abstract: This module contains the features of CSS relating to new mechanisms of overflow handling in visual media (e.g., screen or paper). In interactive media, it describes features that allow the overflow from a fixed size container to be handled by pagination (displaying one page at a time). It also describes features, applying to all visual media, that allow the contents of an element to be spread across multiple fragments, allowing the contents to flow across multiple regions or to have different styles for different fragments.
git@19337	14	Ignored Terms: scroll
dbaron@15115	15	</pre>
dbaron@15115	16	<pre class="link-defaults">
jackalmage@15315	17	type: dfn; spec:css-multicol-1; text:overflow column
git@19337	18	spec:css-pseudo-4; type:selector; text:::first-letter
git@19337	19	spec:css-pseudo-4; type:selector; text:::first-line
dbaron@15115	20	</pre>
dbaron@15115	21	<pre class="anchors">
peter@16986	22	url: https://drafts.csswg.org/selectors-3/#subject; type: dfn; text: subject;
dbaron@15115	23	</pre>
dbaron@6475	24	<style>
dbaron@6477	25	table.source-demo-pair {
dbaron@6477	26	width: 100%;
dbaron@6477	27	}
dbaron@6481	28
dbaron@6475	29	.in-cards-demo {
dbaron@6475	30	width: 13em;
dbaron@6475	31	height: 8em;
dbaron@6475	32
dbaron@6475	33	padding: 4px;
dbaron@6475	34	border: medium solid blue;
dbaron@6475	35	margin: 6px;
dbaron@6475	36
dbaron@6475	37	font: medium/1.3 Times New Roman, Times, serif;
dbaron@6475	38	white-space: nowrap;
dbaron@6475	39	}
dbaron@6481	40
dbaron@6477	41	.bouncy-columns-demo {
dbaron@6477	42	width: 6em;
dbaron@6477	43	height: 10em;
dbaron@6477	44	float: left;
dbaron@6477	45	margin: 1em;
dbaron@6477	46	font: medium/1.25 Times New Roman, Times, serif;
dbaron@6477	47	white-space: nowrap;
dbaron@6477	48	}
dbaron@6477	49	.bouncy-columns-demo.one {
dbaron@6477	50	background: aqua; color: black;
dbaron@6477	51	transform: rotate(-3deg);
dbaron@6477	52	}
dbaron@6477	53	.bouncy-columns-demo.two {
dbaron@6477	54	background: yellow; color: black;
dbaron@6477	55	transform: rotate(3deg);
dbaron@6477	56	}
dbaron@6479	57
dbaron@6480	58	.article-font-inherit-demo {
dbaron@6480	59	font: 1em/1.25 Times New Roman, Times, serif;
dbaron@6480	60	white-space: nowrap;
dbaron@6480	61	}
dbaron@6480	62	.article-font-inherit-demo.one {
dbaron@6480	63	width: 12em;
dbaron@6480	64	font-size: 1.5em;
dbaron@6480	65	margin-bottom: 1em;
dbaron@6480	66	height: 4em;
dbaron@6480	67	}
dbaron@6480	68	.article-font-inherit-demo.two {
dbaron@6480	69	width: 11em;
dbaron@6480	70	margin-left: 5em;
dbaron@6480	71	margin-right: 2em;
dbaron@6480	72	}
dbaron@6480	73
dbaron@6481	74	.dark-columns-demo {
dbaron@6481	75	width: 6em;
dbaron@6481	76	height: 10em;
dbaron@6481	77	float: left;
dbaron@6481	78	margin-right: 1em;
dbaron@6481	79	font: medium/1.25 Times New Roman, Times, serif;
dbaron@6481	80	white-space: nowrap;
dbaron@6481	81	}
dbaron@6481	82	.dark-columns-demo.one {
dbaron@6481	83	background: aqua; color: black;
dbaron@6481	84	}
dbaron@6481	85	.dark-columns-demo.one :link {
dbaron@6481	86	color: blue;
dbaron@6481	87	}
dbaron@6481	88	.dark-columns-demo.one :visited {
dbaron@6481	89	color: purple;
dbaron@6481	90	}
dbaron@6481	91	.dark-columns-demo.two {
dbaron@6481	92	background: navy; color: white;
dbaron@6481	93	}
dbaron@6481	94	.dark-columns-demo.two :link {
dbaron@6481	95	color: aqua;
dbaron@6481	96	}
dbaron@6481	97	.dark-columns-demo.two :visited {
dbaron@6481	98	color: fuchsia;
dbaron@6481	99	}
dbaron@6481	100
dbaron@6479	101	.article-max-lines-demo {
dbaron@6479	102	font: 1em/1.25 Times New Roman, Times, serif;
dbaron@6479	103	white-space: nowrap;
dbaron@6479	104	}
dbaron@6479	105	.article-max-lines-demo.one::first-letter {
dbaron@6479	106	font-size: 2em;
dbaron@6479	107	line-height: 0.9;
dbaron@6479	108	}
dbaron@6479	109	.article-max-lines-demo.one {
dbaron@6479	110	font-size: 1.5em;
dbaron@6479	111	width: 16em;
dbaron@6479	112	}
dbaron@6479	113	.article-max-lines-demo.two {
dbaron@6479	114	width: 11.5em;
dbaron@6479	115	float: left; margin-right: 1em;
dbaron@6479	116	}
dbaron@6479	117	.article-max-lines-demo.three {
dbaron@6479	118	width: 11.5em;
dbaron@6479	119	float: left;
dbaron@6479	120	}
dbaron@6475	121	</style>
dbaron@6470	122
dbaron@6470	123	<h2 id="intro">
dbaron@6470	124	Introduction</h2>
dbaron@6470	125
git@19333	126	Note: At the time of writing, [[CSS-OVERFLOW-3]] is not completely finalized yet.
git@19333	127	To avoid accidental divergences and maintenance overhead,
git@19333	128	This specification is written as a delta specification over css-overflow Level 3.
git@19333	129	Once the level 3 specification is final,
git@19333	130	its content will be integrated into this specification,
git@19333	131	which will then replace it.
git@19333	132	Until then, this specification only contains additions and extensions to level 3.
git@19333	133
dbaron@6470	134	<p>
dbaron@6470	135	In CSS Level 1 [[CSS1]], placing more content than would fit
dbaron@6470	136	inside an element with a specified size
dbaron@6470	137	was generally an authoring error.
dbaron@6470	138	Doing so caused the content to extend
dbaron@6470	139	outside the bounds of the element,
dbaron@6470	140	which would likely cause
dbaron@6470	141	that content to overlap with other elements.
dbaron@6470	142	</p>
dbaron@6470	143
dbaron@6470	144	<p>
dbaron@6470	145	CSS Level 2 [[CSS21]] introduced the 'overflow' property,
dbaron@6470	146	which allows authors to have overflow be handled by scrolling,
dbaron@6470	147	which means it is no longer an authoring error.
dbaron@6470	148	It also allows authors to specify
dbaron@6470	149	that overflow is handled by clipping,
dbaron@6470	150	which makes sense when the author's intent
dbaron@6470	151	is that the content not be shown.
git@19333	152	This was further refined in the CSS Overflow Module Level 3 [[CSS-OVERFLOW-3]].
dbaron@6470	153	</p>
dbaron@6470	154
dbaron@6470	155	<p>
dbaron@6470	156	However, scrolling is not the only way
dbaron@6470	157	to present large amounts of content,
dbaron@6470	158	and may even not be the optimal way.
dbaron@6470	159	After all, the codex replaced the scroll
dbaron@6470	160	as the common format for large written works
dbaron@6470	161	because of its advantages.
dbaron@6470	162	</p>
dbaron@6470	163
dbaron@6470	164	<p>
dbaron@6470	165	This specification introduces
dbaron@6470	166	a mechanism for Web pages to specify
dbaron@6484	167	that an element of a page should handle overflow
dbaron@6470	168	through pagination rather than through scrolling.
dbaron@6470	169	</p>
dbaron@6470	170
dbaron@6470	171	<p>
dbaron@6470	172	This specification also extends the concept of overflow
dbaron@6470	173	in another direction.
dbaron@6484	174	Instead of requiring that authors specify a single area
dbaron@6470	175	into which the content of an element must flow,
dbaron@6484	176	this specification allows authors to specify multiple fragments,
dbaron@6470	177	each with their own dimensions and styles,
dbaron@6470	178	so that the content of the element can flow from one to the next,
dbaron@6470	179	using as many as needed to place the content without overflowing.
dbaron@6470	180	</p>
dbaron@6470	181
dbaron@6470	182	<p>
dbaron@6470	183	In both of these cases, implementations must
dbaron@6470	184	break the content in the block-progression dimension.
dbaron@6470	185	Implementations must do this is described
dbaron@6470	186	in the CSS Fragmentation Module [[!CSS3-BREAK]].
dbaron@6470	187	</p>
dbaron@6470	188
dbaron@9850	189	<h2 id="overflow-concepts">Types of overflow</h2>
dbaron@9850	190
git@19333	191	Issue: copy level 3 content when final
dbaron@9850	192
dbaron@9850	193
dbaron@7811	194	<h2 id="overflow-properties">Overflow properties</h2>
dbaron@7811	195
git@19333	196	Issue: copy level 3 content when final
dbaron@7814	197
florian@15277	198
git@18680	199	<h2 id="scollbar-gutter-property">
git@18680	200	Reserving space for the scrollbar: the 'scrollbar-gutter' property</h2>
florian@15277	201
git@18680	202	The space between the inner border edge and the outer padding edge
git@18680	203	which user agents may reserve to display the scrollbar
git@18680	204	is called the <dfn>scrollbar gutter</dfn>.
git@18680	205
git@18680	206	The 'scrollbar-gutter' property gives control to the author
git@18680	207	over the presence of <a>scrollbar gutters</a>
git@18680	208	separately from the ability to control the presence of scrollbars
git@18680	209	provided by the 'overflow' property.
git@18680	210
git@18680	211	<pre class="propdef">
git@18680	212	Name: scrollbar-gutter
git@18680	213	Value: ''auto'' | [ ''stable'' | ''always'' ] && ''both''? && ''force''?
git@18680	214	Initial: auto
git@18680	215	Inherited: yes
git@18680	216	Computed value: specified value
git@18680	217	</pre>
git@18680	218
git@18680	219	This property affects the presence of <a>scrollbar gutters</a>
git@18680	220	placed at the <a>inline start</a> edge or <a>inline end</a> edge of the box.
git@18680	221
git@18680	222	The presence of a <a>scrollbar gutter</a>
git@18680	223	at the <a>block start</a> edge and <a>block end</a> edge of the box
git@18680	224	cannot be controlled in this level,
git@18680	225	and is determined the same way as the presence of <a>scrollbar gutters</a>
git@18680	226	placed at the <a>inline start</a> edge or <a>inline end</a> edge of the box
git@18680	227	when 'scrollbar-gutter' is ''scrollbar-gutter/auto''.
git@18680	228
git@18680	229	Scrollbars which by default are placed over the content box
git@18680	230	and do not cause <a>scrollbar gutters</a> to be created
git@18680	231	are called <dfn>overlay scrollbars</dfn>.
git@18680	232	Such scrollbars are usually partially transparent, revealing the content behind them if any.
git@18680	233	Their appearance and size may vary
git@18680	234	based on whether and how the user is interacting with them.
git@18680	235
git@18680	236	Scrollbars which are always placed in a <a>scrollbar gutter</a>,
git@18680	237	consuming space when present,
git@18680	238	are called <dfn>classic scrollbars</dfn>.
git@18680	239	Such scrollbars are usually opaque.
git@18680	240
git@18680	241	Whether <a>classic scrollbars</a> or <a>overlay scrollbars</a> are used is UA defined.
git@18680	242
git@18680	243	The appearance and size of the scrollbar is UA defined.
git@18680	244
git@18680	245	Whether scrollbars appear on the start or end edge of the box is UA defined.
git@18680	246
git@18680	247	For <a>classic scrollbars</a>,
git@18680	248	the width of the <a>scrollbar gutter</a> is the same as the width of the scrollbar.
git@18680	249	For <a>overlay scrollbars</a>,
git@18680	250	the width of the <a>scrollbar gutter</a> is UA defined.
git@18680	251	However, it must not be 0,
git@18680	252	and it must not change based on user interactions with the page or the scrollbar
git@18680	253	even if the scrollbar itself changes.
git@18680	254	Also, it must be the same for all elements in the page.
git@18680	255
git@18680	256	The values of this property have the following meaning:
git@18680	257
git@18680	258	<dl dfn-for="scrollbar-gutter">
git@18680	259	<dt><dfn>''scrollbar-gutter/auto''</dfn>
git@18680	260	<dd><a>Classic scrollbars</a> consume space by creating a <a>scrollbar gutter</a>
git@18680	261	when 'overflow' is ''overflow/scroll',
git@18680	262	or when 'overflow' is ''overflow/auto'' and the box is overflowing.
git@18680	263	<a>Overlay scrollbars</a> do not consume space.
git@18680	264
git@18680	265	<dt><dfn>''stable''</dfn>
git@18680	266	<dd>The <a>scrollbar gutter</a> is present when
git@18680	267	'overflow' is ''overflow/scroll'' or ''overflow/auto''
git@18680	268	and the scrollbar is a <a>classic scrollbar</a>
git@18680	269	even if the box is not overflowing,
git@18680	270	but not when the scrollbar is an <a>overlay scrollbar</a>.
git@18680	271
git@18680	272	<dt><dfn>''always''</dfn>
git@18680	273	<dd>The <a>scrollbar gutter</a> is always present when
git@18680	274	'overflow' is ''overflow/scroll'' or ''overflow/auto'',
git@18680	275	regardless of the type of scrollbar or
git@18680	276	of whether the box is overflowing.
git@18680	277
git@18680	278	<dt><dfn>''both''</dfn>
git@18680	279	<dd>If a <a>scrollbar gutter</a> would be present
git@18680	280	on one of the inline start edge or the inline end edge of the box,
git@18680	281	another <a>scrollbar gutter</a> must be present on the opposite edge as well.
git@18680	282
git@18680	283	<dt><dfn>''force''</dfn>
git@18680	284	<dd>When the ''scrollbar-gutter/force'' keyword is present
git@18680	285	''scrollbar-gutter/stable'' and ''scrollbar-gutter/always'' take effect
git@18680	286	when 'overflow' is ''overflow/visible'', ''overflow/hidden'' or ''overflow/clip''
git@18680	287	in addition ''overflow/auto'' or ''overflow/scroll''.
git@18680	288	This does not cause a scrollbar to be displayed, only a <a>scrollbar gutter</a>.
git@18680	289	</dl>
git@18680	290
git@18680	291	When the <a>scrollbar gutter</a> is present but the scrollbar is not,
git@18680	292	or the scrollbar is transparent or otherwise does not fully obscure the <a>scrollbar gutter</a>,
git@18680	293	the background of the <a>scrollbar gutter</a> must be painted as an extension of the padding.
git@18680	294
git@18680	295	<div class=note>
git@18680	296	Note: The following table summarises the interaction of 'overflow' and 'scrollbar-gutter',
git@18680	297	showing in which case space is reserved for the <a>scrollbar gutter</a>.
git@18680	298	In this table, “G” represents cases where space is reserved for the <a>scrollbar gutter</a>,
git@18680	299	“f?” cases where space is reserved for the <a>scrollbar gutter</a>
git@18680	300	if ''scrollbar-gutter/force'' was specified,
git@18680	301	and empty cells cases where the no space is reserved.
git@18680	302
git@18680	303	<table class=data>
git@18680	304	<thead>
git@18680	305	<tr>
git@18680	306	<td>
git@18680	307	<td>
git@18680	308	<th colspan=2>Classic scrollbars
git@18680	309	<th colspan=2>Overlay scrollbars
git@18680	310	<tr>
git@18680	311	<th>'overflow'
git@18680	312	<th>'scrollbar-gutter'
git@18680	313	<th>Overflowing
git@18680	314	<th>Not overflowing
git@18680	315	<th>Overflowing
git@18680	316	<th>Not overflowing
git@18680	317	</thead>
git@18680	318	<tr>
git@18680	319	<th rowspan=3>'overflow/scroll'
git@18680	320	<th>''scrollbar-gutter/auto''
git@18680	321	<td>G
git@18680	322	<td>G
git@18680	323	<td>
git@18680	324	<td>
git@18680	325	<tr>
git@18680	326	<th>''scrollbar-gutter/stable''
git@18680	327	<td>G
git@18680	328	<td>G
git@18680	329	<td>
git@18680	330	<td>
git@18680	331	<tr>
git@18680	332	<th>''scrollbar-gutter/always''
git@18680	333	<td>G
git@18680	334	<td>G
git@18680	335	<td>G
git@18680	336	<td>G
git@18680	337	<tr>
git@18680	338	<th rowspan=3>''overflow/auto''
git@18680	339	<th>''scrollbar-gutter/auto''
git@18680	340	<td>G
git@18680	341	<td>
git@18680	342	<td>
git@18680	343	<td>
git@18680	344	<tr>
git@18680	345	<th>''scrollbar-gutter/stable''
git@18680	346	<td>G
git@18680	347	<td>G
git@18680	348	<td>
git@18680	349	<td>
git@18680	350	<tr>
git@18680	351	<th>''scrollbar-gutter/always''
git@18680	352	<td>G
git@18680	353	<td>G
git@18680	354	<td>G
git@18680	355	<td>G
git@18680	356	<tr>
git@18680	357	<th rowspan=3>''overflow/visible'', ''overflow/hidden'', ''overflow/clip''
git@18680	358	<th>''scrollbar-gutter/auto''
git@18680	359	<td>
git@18680	360	<td>
git@18680	361	<td>
git@18680	362	<td>
git@18680	363	<tr>
git@18680	364	<th>''scrollbar-gutter/stable''
git@18680	365	<td>f?
git@18680	366	<td>f?
git@18680	367	<td>
git@18680	368	<td>
git@18680	369	<tr>
git@18680	370	<th>''scrollbar-gutter/always''
git@18680	371	<td>f?
git@18680	372	<td>f?
git@18680	373	<td>f?
git@18680	374	<td>f?
git@18680	375	</table>
git@18680	376	</div>
florian@15277	377
florian@15278	378	<h2 id="fragmentation">Fragmentation of overflow</h2>
florian@15277	379
florian@15279	380	The 'continue' property gives authors the ability
florian@15279	381	to request that content that does not fit inside an element
florian@15279	382	be fragmented (in the sense of [[!CSS3-BREAK]]),
florian@15279	383	and provides alternatives
florian@15279	384	for where the remaining content should continue.
florian@15279	385
florian@15279	386	Notably, this property explains traditional pagination,
florian@15279	387	and extends it further.
florian@15279	388
florian@15278	389	<pre class=propdef>
florian@15278	390	Name: continue
jackalmage@15301	391	Value: ''auto'' | ''overflow'' | ''paginate'' | ''fragments'' | ''discard''
florian@15293	392	Initial: auto
florian@15278	393	Applies to: block containers [[!CSS21]], flex containers [[!CSS3-FLEXBOX]], and grid containers [[!CSS3-GRID-LAYOUT]]
florian@15278	394	Inherited: no
florian@15278	395	Percentages: N/A
florian@15278	396	Media: visual
florian@15278	397	Computed value: see below
florian@15278	398	Animatable: no
florian@15278	399	Canonical order: <abbr title="follows order of property value definition">per grammar</abbr>
florian@15278	400	</pre>
florian@15277	401
florian@15282	402	Issue: The naming of this property and its values is preliminary.
florian@15282	403	This was initially proposed as
florian@15282	404	"fragmentation: auto | none | break | clone | page"
florian@15282	405	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>,
florian@15282	406	and there is not yet wide agreement as to which naming is better.
florian@15277	407
florian@15284	408	Issue: This property is meant to generalize and replace 'region-fragment'.
florian@15284	409	Once it is sufficiently stable in this specification,
florian@15284	410	'region-fragment' should be removed from the regions specification in favor of this.
florian@15284	411
florian@15278	412	Note: ''continue: fragments'' replaces "overflow:fragments"
florian@15278	413	from earlier versions of this specification,
florian@15278	414	while ''continue: paginate'' replaces "overflow: paged-x | paged-y | paged-x-controls | paged-y-controls"
florian@15277	415
florian@15278	416	<dl dfn-for="continue" dfn-type="value">
florian@15293	417	<dt><dfn>auto</dfn>
florian@15293	418	<dd>''continue/auto'' may only occur as a computed value
florian@15279	419	if the element is a <a spec="css-regions">CSS Region</a>
florian@15293	420	other than the last one in a <a spec="css-regions">region chain</a>.
florian@15293	421	Content that doesn't fit is pushed to the next region of the chain.
florian@15293	422
florian@15293	423	In all other cases, ''continue/auto'' computes to one of the other values.
florian@15278	424
florian@15278	425	<dt><dfn>overflow</dfn>
florian@15278	426	<dd>Content that doesn't fit overflows, according to the 'overflow' property
florian@15278	427
florian@15278	428	<dt><dfn>discard</dfn>
florian@15278	429	<dd>Content that doesn't fit is discarded at a fragmentation break
florian@15278	430
florian@15278	431	Note: generalized from region-fragment: break; on the last region of a region chain
florian@15278	432
florian@15279	433	Issue: When the element isn't a <a spec="css-break">fragmentation container</a> already,
florian@15279	434	should this work by turning it directly into one,
florian@15279	435	or by creating a <a>fragment box</a> inside it like ''continue/fragments'' does?
florian@15278	436
florian@15278	437	<dt><dfn>paginate</dfn>
florian@15278	438	<dd>Content that doesn't fit paginates.
florian@15278	439	This creates a paginated view inside the element
florian@15278	440	similar to the way that 'overflow: scroll' creates a scrollable view.
florian@15278	441
florian@15279	442	See <a href="#paginated-overflow">paginated overflow</a>
florian@15278	443
florian@15278	444	Note: Print is effectively "continue: paginate" on the root.
dbaron@7811	445	<dt><dfn>fragments</dfn>
florian@15278	446	<dd>content that doesn't fit causes the element to copy itself and continue laying out.
florian@15279	447
florian@15278	448	See <a href="#fragment-overflow">fragment overflow</a>.
dbaron@7811	449	</dl>
dbaron@7811	450
florian@15279	451	The computed value of the 'continue' for a given element or pseudo element is determined as follow:
florian@15279	452	<ol>
git@19381	453	<li>On elements or pseudo elements with <a>layout containment</a> (see [[!CSS-CONTAIN-1]]),
git@19381	454	if the specificied value is ''continue/auto'' or ''continue/fragments''
git@19381	455	then the computed value is ''continue/overflow''.
git@19381	456	<li>Otherwise, if the specified value is ''continue/auto''
florian@15279	457	<ol>
florian@15279	458	<li>On a <a spec="css-regions">CSS Region</a> other than the last one in a <a spec="css-regions">region chain</a>,
florian@15293	459	the computed value is ''continue/auto''
florian@15279	460	<li>On a page
florian@15279	461	the computed value is ''continue/paginate''
florian@15279	462	<li>On a <a>fragment box</a>
florian@15279	463	the computed value is ''continue/fragments''
florian@15283	464	<li>Otherwise, the computed value is ''continue/overflow''
florian@15279	465	</ol>
git@19381	466	<li>Otherwise, if the specified value is ''continue/framgents''
florian@15279	467	<ol>
florian@15279	468	<li>On a page
florian@15279	469	the computed value is ''continue/paginate''
florian@15279	470	<li>Otherwise, the computed value is the specified value
florian@15279	471	</ol>
florian@15279	472	<li>In all other cases, the computed value is the specified value
florian@15279	473	</ol>
florian@15279	474
florian@15280	475	Issue: If we introduce a pseudo element that can select columns in a multicol,
florian@15293	476	we would need to specify that auto computes to auto on it,
florian@15293	477	or introduce a new value and have auto compute to that
florian@15280	478	(but what would that value compute to on things that aren't columns?).
florian@15280	479
florian@15278	480	Note: For background discussions leading to this property, see these threads:
florian@15278	481	<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
florian@15278	482	<a href="https://lists.w3.org/Archives/Public/www-style/2015Jan/0357.html">proposal for a fragmentation property</a>
dbaron@14821	483
dbaron@6470	484	<h2 id="paginated-overflow">Paginated overflow</h2>
dbaron@6470	485
florian@15278	486	This section introduces and defines the meaning of the ''continue/paginate'' value of the 'continue' property.
dbaron@6470	487
florian@15278	488	Issue: Write this section
florian@15278	489
florian@15281	490	Issue: Pages should be possible to style with @page rules. How does that work for nested pages?
florian@15281	491
florian@15281	492	<div class="issue">
florian@15281	493	Should traditional pagination (e.g. when printing)
florian@15293	494	be expressed through some magic in the computed value of ''continue/auto'',
florian@15281	495	or by inserting this in the UA stylesheet:
florian@15281	496	<pre><code class="lang-css">
florian@15281	497	@media (overflow-block: paged), (overflow-block: optional-paged) {
florian@15281	498	:root {
florian@15281	499	continue: paginate;
florian@15281	500	}
florian@15281	501	}
florian@15281	502	</code></pre>
florian@15281	503	</div>
florian@15281	504
florian@15281	505	Issue: Traditional pagination (e.g. when printing) assumes that
florian@15281	506	:root is contained in the page box,
florian@15281	507	rather than having the page box be a pseudo element child of :root.
florian@15281	508	Can we work around that using something similar to fragment boxes?
florian@15281	509	Or maybe by having a fragment box (reproducing :root) inside a page box inside :root?
florian@15281	510
florian@15281	511	Issue: How does the page box model work when it is a child of a regular css box?
florian@15281	512
florian@15278	513	Issue: The initial proposal in [[CSS3GCPM]] and implemantation from Opera
florian@15278	514	used 4 values instead of ''continue/paginate'':
florian@15278	515	"paged-x | paged-y | paged-x-controls | paged-y-controls".
florian@15278	516	Should this property also include these values,
florian@15278	517	or are they better handled as separate properties?
florian@15278	518	(e.g.: "pagination-layout: auto | horizontal | vertical", "pagination-controls: auto | none")
florian@15278	519
florian@15278	520	Issue: Ability to display N pages at once
florian@15278	521	rather than just one page at once?
florian@15278	522	Could this be a value of "pagination-layout", such as:
florian@15278	523	"pagination-layout: horizontal 2;"
dbaron@6470	524
florian@15303	525	Issue: Brad Kemper has proposed a model for combining pagination and
florian@15303	526	fragment overflow, which also deals with displaying multiple pages.
florian@15303	527	<a href="http://www.w3.org/mid/[email protected]">http://www.w3.org/mid/[email protected]</a>
florian@15303	528
dbaron@6497	529	<p class="issue">
dbaron@6497	530	The current implementation of paginated overflow uses
git@19337	531	the overflow/overflow-x/overflow-y properties
git@19337	532	rather than the overflow-style property as proposed
dbaron@6497	533	in the [[CSS3GCPM]] draft
dbaron@6497	534	(which also matches the [[CSS3-MARQUEE]] proposal).
florian@15278	535	or the 'continue' property as described here.
dbaron@6497	536	</p>
dbaron@6497	537
dbaron@6484	538	<h2 id="fragment-overflow">Fragment overflow</h2>
dbaron@6470	539
florian@15278	540	This section introduces and defines the meaning of
florian@15278	541	the ''continue/fragments'' value of the 'continue' property.
dbaron@6470	542
dbaron@6470	543	<p>
florian@15278	544	When the computed value of 'continue' for an element is ''continue/fragments'',
dbaron@6470	545	and implementations would otherwise have created a box for the element,
dbaron@6491	546	then implementations must create a sequence of <dfn>fragment box</dfn>es
dbaron@6470	547	for that element.
florian@15278	548	(It is possible for an element with ''continue: fragments''
dbaron@15115	549	to generate only one <a>fragment box</a>.
florian@15278	550	However, if an element's computed 'continue' is not ''continue/fragments'',
dbaron@15115	551	then its box is not a <a>fragment box</a>.)
dbaron@15115	552	Every <a>fragment box</a> is a fragmentation container,
dbaron@6491	553	and any overflow
dbaron@6491	554	that would cause that fragmentation container to fragment
dbaron@15115	555	causes another <a>fragment box</a> created as a next sibling
dbaron@6470	556	of the previous one.
dbaron@6470	557	<span class="issue">Or is it as though it's a next sibling of
dbaron@6470	558	the element? Need to figure out exactly how this interacts with
dbaron@6470	559	other box-level fixup.</span>
dbaron@15115	560	Additionally, if the <a>fragment box</a> is also
dbaron@6492	561	a multi-column box (as defined in [[!CSS3COL]]
dbaron@6492	562	<span class="issue">though it defines <i>multi-column element</i></span>)
dbaron@15115	563	any content that would lead to the creation of <a>overflow columns</a> [[!CSS3COL]]
dbaron@6492	564	instead is flown into an additional fragment box.
dbaron@6491	565	However, fragment boxes may themselves be broken
dbaron@6491	566	(due to fragmentation in a fragmentation context outside of them,
dbaron@6491	567	such as pages, columns, or other fragment boxes);
dbaron@6491	568	such breaking leads to fragments of the same fragment box
dbaron@6491	569	rather than multiple fragment boxes.
dbaron@6491	570	(This matters because fragment boxes may be styled by their index;
dbaron@6491	571	such breaking leads to multiple fragments of a fragment box
dbaron@6491	572	with a single index.
dbaron@6491	573	This design choice is so that
dbaron@6491	574	breaking a fragment box across pages does not break
dbaron@6491	575	the association of indices to particular pieces of content.)
dbaron@6491	576	<span class="issue">Should a forced break that breaks to
dbaron@6491	577	an outer fragmentation context cause a new fragment of a single
dbaron@6491	578	fragment box or a new fragment box?</span>
dbaron@6491	579	<span class="issue">Should we find a term other than
dbaron@15115	580	<a>fragment box</a> here to make this a little less confusing?</span>
dbaron@6470	581	</p>
dbaron@6470	582
dbaron@6470	583	<p class="issue">
dbaron@6491	584	What if we want to be able to style the pieces of an element
dbaron@6491	585	split within another type of fragmentation context?
dbaron@6491	586	These rules prevent ever using ''::nth-fragment()'' for that,
dbaron@6491	587	despite that the name seems the most logical name for such a feature.
dbaron@6470	588	</p>
dbaron@6470	589
dbaron@6475	590	<div class="example">
git@19338	591	<table class="source-demo-pair"><tr><td>
git@19338	592	<pre><code highlight="html">&lt;!DOCTYPE HTML&gt;
dbaron@6475	593	&lt;title&gt;Breaking content into
dbaron@6475	594	equal-sized cards&lt;/title&gt;
dbaron@6475	595	&lt;style&gt;
dbaron@6475	596	.in-cards {
florian@15278	597	continue: fragments;
dbaron@6475	598
dbaron@6475	599	width: 13em;
dbaron@6475	600	height: 8em;
dbaron@6475	601
dbaron@6475	602	padding: 4px;
dbaron@6475	603	border: medium solid blue;
dbaron@6475	604	margin: 6px;
dbaron@6475	605
dbaron@6475	606	font: medium/1.3 Times New
dbaron@6475	607	Roman, Times, serif;
dbaron@6475	608	}
dbaron@6475	609	&lt;/style&gt;
dbaron@6475	610	&lt;div class="in-cards"&gt;
dbaron@6475	611	In this example, the text in the div
dbaron@6475	612	is broken into a series of cards.
dbaron@6475	613	These cards all have the same style.
dbaron@6475	614	The presence of enough content to
dbaron@6475	615	overflow one of the cards causes
dbaron@6475	616	another one to be created. The second
dbaron@6475	617	card is created just like it's the
dbaron@6475	618	next sibling of the first.
git@19338	619	&lt;/div&gt;</code></pre></td><td>
dbaron@6475	620	<div class="in-cards-demo">In this example, the text in the<br>div is broken into a series of<br>cards. These cards all have the<br>same style. The presence of<br>enough content to overflow<br>one of the cards causes another</div>
dbaron@6475	621	<div class="in-cards-demo">one to be created. The second<br>card is created just like it's the<br>next sibling of the first.</div>
dbaron@6475	622	</td></tr></table>
dbaron@6475	623	</div>
dbaron@6475	624
dbaron@6487	625	<p class="issue">
florian@15278	626	We should specify that ''continue: fragments'' does not apply
dbaron@6487	627	to at least some table parts,
dbaron@6487	628	and perhaps other elements as well.
dbaron@6487	629	We need to determine exactly which ones.
dbaron@6487	630	</p>
dbaron@6487	631
dbaron@6488	632	<p class="issue">
dbaron@6488	633	This specification needs to say which type of
dbaron@6488	634	fragmentation context is created
dbaron@15113	635	so that it's clear which values of the 'break-*' properties
dbaron@6488	636	cause breaks within this context.
dbaron@15113	637	We probably want ''break-*: region'' to apply.
dbaron@6488	638	</p>
dbaron@6488	639
dbaron@6494	640	<p class="issue">
dbaron@6494	641	This specification needs a processing model
dbaron@6494	642	that will apply in cases where the layout containing the
dbaron@6494	643	fragments has characteristics that use the intrinsic size of the fragments
dbaron@6494	644	to change the amount of space available for them,
dbaron@6494	645	such as [[CSS3-GRID-LAYOUT]].
dbaron@6494	646	There has already been some work on such a processing model
dbaron@6494	647	in [[CSS3-REGIONS]],
dbaron@6494	648	and the work done on a model there,
dbaron@6494	649	and the editors of that specification,
dbaron@6494	650	should inform what happens in this specification.
dbaron@6494	651	</p>
dbaron@6494	652
dbaron@6484	653	<h3 id="fragment-styling">Fragment styling</h3>
dbaron@6470	654
dbaron@6484	655	<h4 id="fragment-pseudo-element">The ::nth-fragment() pseudo-element</h4>
dbaron@6470	656
dbaron@6470	657	<p>
dbaron@15120	658	The <dfn selector>::nth-fragment()</dfn> pseudo-element
dbaron@15120	659	is a pseudo-element
dbaron@15115	660	that describes some of the <a>fragment box</a>es generated by an element.
dbaron@6470	661	The argument to the pseudo-element takes the same syntax
dbaron@6470	662	as the argument to the :nth-child() pseudo-class
dbaron@6470	663	defined in [[!SELECT]], and has the same meaning
dbaron@6470	664	except that the number is relative to
dbaron@15115	665	<a>fragment box</a>es generated by the element
dbaron@6470	666	instead of siblings of the element.
dbaron@6470	667	</p>
dbaron@6470	668
dbaron@6470	669	<p class="note">
dbaron@6484	670	Selectors that allow addressing fragments
dbaron@6470	671	by counting from the end rather than the start
dbaron@6470	672	are intentionally not provided.
dbaron@6470	673	Such selectors would interfere with determining
dbaron@6484	674	the number of fragments.
dbaron@6470	675	</p>
dbaron@6470	676
dbaron@6489	677	<p class="issue">
dbaron@6489	678	Depending on future discussions,
dbaron@6489	679	this ''::nth-fragment(<var>an+b</var>)'' syntax
dbaron@6489	680	may be replaced with
dbaron@6489	681	the new ''::fragment:nth(<var>an+b</var>)'' syntax.
dbaron@6489	682	</p>
dbaron@6489	683
dbaron@6484	684	<h4 id="style-of-fragments">Styling of fragments</h4>
dbaron@6470	685
dbaron@6470	686	<p class="issue">
florian@15278	687	Should this apply to continue:fragments only,
florian@15278	688	or also to continue:paginate?
dbaron@6470	689	(If it applies,
dbaron@6470	690	then stricter property restrictions would be needed
florian@15278	691	for continue:paginate.)
dbaron@6470	692	</p>
dbaron@6470	693
dbaron@6470	694	<p>
dbaron@6484	695	In the absence of rules with ''::nth-fragment()'' pseudo-elements,
dbaron@15115	696	the computed style for each <a>fragment box</a>
dbaron@6470	697	is the computed style for the element
dbaron@15115	698	for which the <a>fragment box</a> was created.
dbaron@15115	699	However, the style for a <a>fragment box</a> is also influenced
dbaron@15115	700	by rules whose selector's <a>subject</a> [[!SELECT]]
dbaron@6484	701	has an ''::nth-fragment()'' pseudo-element,
dbaron@15115	702	if the 1-based number of the <a>fragment box</a> matches
dbaron@6484	703	that ''::nth-fragment()'' pseudo-element
dbaron@6484	704	and the selector (excluding the ''::nth-fragment()'' pseudo-element)
dbaron@6484	705	matches the element generating the fragments.
dbaron@6470	706	</p>
dbaron@6470	707
dbaron@6486	708	<p>
dbaron@15115	709	When determining the style of the <a>fragment box</a>,
dbaron@6486	710	these rules that match the fragment pseudo-element
dbaron@6486	711	cascade together with the rules that match the element,
dbaron@6486	712	with the fragment pseudo-element adding the specificity
dbaron@6486	713	of a pseudo-class to the specificity calculation.
dbaron@6486	714	<span class="issue">Does this need to be specified in
dbaron@6486	715	the cascading module as well?</span>
dbaron@6486	716	</p>
dbaron@6486	717
dbaron@6477	718	<div class="example">
git@19338	719	<table class="source-demo-pair"><tr><td>
git@19338	720	<pre><code highlight="html">&lt;!DOCTYPE HTML&gt;
dbaron@6477	721	&lt;style&gt;
dbaron@6477	722	.bouncy-columns {
florian@15278	723	continue: fragments;
dbaron@6477	724	width: 6em;
dbaron@6477	725	height: 10em;
dbaron@6477	726	float: left;
dbaron@6477	727	margin: 1em;
dbaron@6477	728	font: medium/1.25 Times New
dbaron@6477	729	Roman, Times, serif;
dbaron@6477	730	}
dbaron@6484	731	.bouncy-columns::nth-fragment(1) {
dbaron@6477	732	background: aqua; color: black;
dbaron@6477	733	transform: rotate(-3deg);
dbaron@6477	734	}
dbaron@6484	735	.bouncy-columns::nth-fragment(2) {
dbaron@6477	736	background: yellow; color: black;
dbaron@6477	737	transform: rotate(3deg);
dbaron@6477	738	}
dbaron@6477	739	&lt;/style&gt;
dbaron@6477	740	&lt;div class="bouncy-columns"&gt;
dbaron@6477	741	<i>...</i>
git@19338	742	&lt;/div&gt;</code></pre></td><td>
dbaron@6477	743	<div class="bouncy-columns-demo one">In this<br>example, the<br>text in the div<br>is broken into<br>a series of<br>columns. The<br>author<br>probably</div>
dbaron@6477	744	<div class="bouncy-columns-demo two">intended the<br>text to fill two<br>columns. But<br>if it happens to<br>fill three<br>columns, the<br>third column is<br>still created. It</div>
dbaron@6484	745	<div class="bouncy-columns-demo">just doesn't<br>have any<br>fragment-specific<br>styling because<br>the author<br>didn't give it<br>any.</div>
dbaron@6477	746	</td></tr></table>
dbaron@6477	747	</div>
dbaron@6477	748
dbaron@6470	749	<p>
florian@15278	750	Styling an ''::nth-fragment()'' pseudo-element with the 'continue'
dbaron@6490	751	property does take effect;
dbaron@15115	752	if a <a>fragment box</a> has a
florian@15278	753	computed value of 'continue' other than ''fragments''
dbaron@6490	754	then that fragment box is the last fragment.
florian@15278	755	However, overriding 'continue' on the first fragment
dbaron@15115	756	does not cause the <a>fragment box</a> not to exist;
dbaron@6490	757	whether there are fragment boxes at all is determined by
dbaron@6490	758	the computed value of overflow for the element.
dbaron@6470	759	</p>
dbaron@6470	760
dbaron@6470	761	<p>
dbaron@6485	762	Styling an ''::nth-fragment()'' pseudo-element with the 'content'
dbaron@6485	763	property has no effect;
dbaron@6485	764	the computed value of 'content' for the fragment box
dbaron@6485	765	remains the same as the computed value of content for the element.
dbaron@6485	766	</p>
dbaron@6485	767
dbaron@6485	768	<p>
dbaron@15115	769	Specifying ''display: none'' for a <a>fragment box</a> causes
dbaron@6484	770	the fragment box with that index not to be generated.
dbaron@6470	771	However, in terms of the indices
dbaron@6484	772	used for matching ''::nth-fragment()'' pseudo-elements
dbaron@6484	773	of later fragment boxes,
dbaron@6470	774	it still counts as though it was generated.
dbaron@6470	775	However, since it is not generated, it does not contain any content.
dbaron@6470	776	</p>
dbaron@6470	777
dbaron@7813	778	<p>
dbaron@7813	779	Specifying other values of 'display', 'position',
dbaron@7813	780	or 'float' is permitted, but is not allowed to change
git@19337	781	the <a>inner display type</a>.
florian@15278	782	(Since 'continue' only
git@19337	783	applies to block containers, flex containers, and grid containers).
git@19337	784	<span class="issue">Need to specify exactly how this works</span>
dbaron@6470	785	</p>
dbaron@6470	786
dbaron@6470	787	<p>
dbaron@6470	788	To match the model for other pseudo-elements
dbaron@6470	789	where the pseudo-elements live inside their corresponding element,
dbaron@6484	790	declarations in ''::nth-fragment()'' pseudo-elements override
dbaron@6470	791	declarations in rules without the pseudo-element.
dbaron@6470	792	The relative priority within such declarations is determined
dbaron@6470	793	by normal cascading order (see [[!CSS21]]).
dbaron@6470	794	</p>
dbaron@6470	795
dbaron@6470	796	<p>
dbaron@6484	797	Styles specified on ''::nth-fragment()'' pseudo-elements
dbaron@15115	798	do affect inheritance to content within the <a>fragment box</a>.
dbaron@15115	799	In other words, the content within the <a>fragment box</a> must
dbaron@6484	800	inherit from the fragment box's style (i.e., the pseudo-element style)
dbaron@6470	801	rather than directly from the element.
dbaron@6484	802	This means that elements split between fragment boxes may
dbaron@6470	803	have different styles for different parts of the element.
dbaron@6470	804	</p>
dbaron@6470	805
dbaron@6472	806	<p class="issue">
dbaron@6472	807	This inheritance rule allows specifying styles indirectly
dbaron@6472	808	(by using explicit ''inherit'' or using default inheritance
dbaron@15117	809	on properties that don't apply to ''::first-letter'')
dbaron@6472	810	that can't be specified directly
dbaron@6472	811	(based on the rules in the next section).
dbaron@6472	812	This is a problem.
dbaron@6484	813	The restrictions that apply to styling inside fragments
dbaron@6484	814	should also apply to inheritance from fragments.
dbaron@6472	815	</p>
dbaron@6472	816
dbaron@6480	817	<div class="example">
git@19338	818	<table class="source-demo-pair"><tr><td>
git@19338	819	<pre><code highlight="html">&lt;!DOCTYPE HTML&gt;
dbaron@6480	820	&lt;style&gt;
dbaron@6480	821	.article {
florian@15278	822	continue: fragments;
dbaron@6480	823	}
dbaron@6484	824	.article::nth-fragment(1) {
dbaron@6480	825	font-size: 1.5em;
dbaron@6480	826	margin-bottom: 1em;
dbaron@6480	827	height: 4em;
dbaron@6480	828	}
dbaron@6491	829	.article::nth-fragment(2) {
dbaron@6480	830	margin-left: 5em;
dbaron@6480	831	margin-right: 2em;
dbaron@6480	832	}
dbaron@6480	833	&lt;/style&gt;
dbaron@6480	834	&lt;div class="article"&gt;
dbaron@6480	835	The &lt;code&gt;font-size&lt;/code&gt; property<i>...</i>
git@19338	836	&lt;/div&gt;</code></pre></td><td>
dbaron@6484	837	<div class="article-font-inherit-demo one">The <code>font-size</code> property<br>specified on the fragment<br>is inherited into the</div>
dbaron@6484	838	<div class="article-font-inherit-demo two">descendants of the fragment.<br>This means that inherited<br>properties can be used<br>reliably on a fragment, as in<br>this example.</div>
dbaron@6480	839	</td></tr></table>
dbaron@6480	840	</div>
dbaron@6478	841
dbaron@6484	842	<h4 id="style-in-fragments">Styling inside fragments</h4>
dbaron@6470	843
dbaron@6470	844	<p class="issue">
florian@15278	845	Should this apply to continue:fragments only,
florian@15278	846	or also to continue:paginate?
dbaron@6470	847	</p>
dbaron@6470	848
dbaron@6470	849	<p>
dbaron@6484	850	The ''::nth-fragment()'' pseudo-element
dbaron@6470	851	can also be used to style
dbaron@15115	852	content inside of a <a>fragment box</a>.
dbaron@6470	853	Unlike the ''::first-line'' and ''::first-letter'' pseudo-elements,
dbaron@6484	854	the ''::nth-fragment()'' pseudo-element can be applied
dbaron@6470	855	to parts of the selector other than the subject:
dbaron@6470	856	in particular, it can match ancestors of the subject.
dbaron@6470	857	However, the only CSS properties applied
dbaron@6470	858	by rules with such selectors
dbaron@6470	859	are those that apply
dbaron@6470	860	to the ''::first-letter'' pseudo-element.
dbaron@6470	861	</p>
dbaron@6470	862
dbaron@6470	863	<p>
dbaron@6470	864	To be more precise,
dbaron@6484	865	when a rule's selector has ''::nth-fragment()'' pseudo-elements
dbaron@6470	866	attached to parts of the selector other than the subject,
dbaron@6470	867	the declarations in that rule apply to
dbaron@6470	868	a fragment (or pseudo-element thereof) when:
dbaron@6470	869	</p>
dbaron@6470	870	<ol>
dbaron@6470	871	<li>
dbaron@6470	872	the declarations are for properties that apply to the
dbaron@6470	873	''::first-letter'' pseudo-element,
dbaron@6470	874	</li>
dbaron@6470	875	<li>
dbaron@6470	876	the declarations would apply to
dbaron@6470	877	that fragment (or pseudo-element thereof)
dbaron@6484	878	had those ''::nth-fragment()'' pseudo-elements been removed,
dbaron@6470	879	with a particular association between
dbaron@6470	880	each sequence of simple selectors and the element it matched,
dbaron@6470	881	and
dbaron@6470	882	</li>
dbaron@6470	883	<li>
dbaron@6484	884	for each removed ''::nth-fragment()'' pseudo-element,
dbaron@15115	885	the fragment lives within a <a>fragment box</a>
dbaron@6470	886	of the element associated in that association
dbaron@6470	887	with the selector that the pseudo-element was attached to,
dbaron@6470	888	and whose index matches the pseudo-element.
dbaron@6470	889	</li>
dbaron@6470	890	</ol>
dbaron@6470	891
dbaron@6481	892	<div class="example">
git@19338	893	<table class="source-demo-pair"><tr><td>
git@19338	894	<pre><code highlight="html">&lt;!DOCTYPE HTML&gt;
dbaron@6481	895	&lt;style&gt;
dbaron@6481	896	.dark-columns {
florian@15278	897	continue: fragments;
dbaron@6481	898	width: 6em;
dbaron@6481	899	height: 10em;
dbaron@6481	900	float: left;
dbaron@6481	901	margin-right: 1em;
dbaron@6481	902	font: medium/1.25 Times New
dbaron@6481	903	Roman, Times, serif;
dbaron@6481	904	}
dbaron@6484	905	.dark-columns::nth-fragment(1) {
dbaron@6481	906	background: aqua; color: black;
dbaron@6481	907	}
dbaron@6484	908	.dark-columns::nth-fragment(1) :link {
dbaron@6481	909	color: blue;
dbaron@6481	910	}
dbaron@6484	911	.dark-columns::nth-fragment(1) :visited {
dbaron@6481	912	color: purple;
dbaron@6481	913	}
dbaron@6484	914	.dark-columns::nth-fragment(2) {
dbaron@6481	915	background: navy; color: white;
dbaron@6481	916	}
dbaron@6484	917	.dark-columns::nth-fragment(2) :link {
dbaron@6481	918	color: aqua;
dbaron@6481	919	}
dbaron@6484	920	.dark-columns::nth-fragment(2) :visited {
dbaron@6481	921	color: fuchsia;
dbaron@6481	922	}
dbaron@6481	923	&lt;/style&gt;
dbaron@6481	924	&lt;div class="dark-columns"&gt;
dbaron@6481	925	<i>...</i>
git@19338	926	&lt;/div&gt;</code></pre></td><td>
dbaron@6484	927	<div class="dark-columns-demo one">In this<br><a href="http://en.wiktionary.org/wiki/example">example</a>, the<br>text flows<br>from one<br>light-colored<br>fragment into<br>another<br>dark-colored</div>
dbaron@6484	928	<div class="dark-columns-demo two">fragment. We<br>therefore want<br>different styles<br>for <a href="http://www.w3.org/Provider/Style/IntoContext.html">hyperlinks</a><br>in the different<br>fragments.</div>
dbaron@6481	929	</td></tr></table>
dbaron@6481	930	</div>
dbaron@6481	931
dbaron@6478	932
dbaron@6470	933	<h3 id="max-lines">The 'max-lines' property</h3>
dbaron@6470	934
dbaron@6470	935	<p>
dbaron@6470	936	Authors may wish to style the opening lines of an element
dbaron@6470	937	with different styles
dbaron@6484	938	by putting those opening lines in a separate fragment.
dbaron@6470	939	However, since it may be difficult to predict the exact height
dbaron@6470	940	occupied by those lines
dbaron@6484	941	in order to restrict the first fragment to that height,
dbaron@6470	942	this specification introduces a 'max-lines' property
dbaron@6484	943	that forces a fragment to break
dbaron@6470	944	after a specified number of lines.
dbaron@6470	945	This forces a break after the given number of lines
dbaron@6470	946	contained within the element or its descendants,
dbaron@6470	947	as long as those lines are in the same block formatting context.
dbaron@6470	948	</p>
dbaron@6470	949
dbaron@15119	950	<pre class=propdef>
dbaron@15119	951	Name: max-lines
git@19337	952	Value: none | <<integer>>
git@19337	953	Initial: none
dbaron@15119	954	Applies to: fragment boxes
dbaron@15119	955	Inherited: no
peter@16989	956	Animatable: as <a href="https://www.w3.org/TR/css3-transitions/#animatable-types">integer</a>
dbaron@15119	957	Percentages: N/A
dbaron@15119	958	Media: visual
dbaron@15119	959	Computed value: specified value
dbaron@15119	960	Canonical order: <abbr title="follows order of property value definition">per grammar</abbr>
dbaron@15119	961	</pre>
dbaron@6470	962
dbaron@15115	963	<dl dfn-for="max-lines" dfn-type="value">
dbaron@15115	964	<dt><dfn>none</dfn>
dbaron@6470	965	<dd>
dbaron@6470	966	<p>
dbaron@6470	967	Breaks occur only as specified elsewhere.
dbaron@6470	968	</p>
dbaron@6470	969	</dd>
dbaron@6470	970
dbaron@15181	971	<dt><dfn><<integer>></dfn>
dbaron@6470	972	<dd>
dbaron@6470	973	<p>
dbaron@6470	974	In addition to any breaks specified elsewhere,
dbaron@6470	975	a break is forced before any line that would exceed
dbaron@6470	976	the given number of lines
dbaron@6470	977	being placed inside the element
dbaron@6470	978	(excluding lines that are in
dbaron@6470	979	a different block formatting context from
dbaron@6470	980	the block formatting context to which
dbaron@6470	981	an unstyled child of the element would belong).
dbaron@6470	982	</p>
dbaron@6470	983
dbaron@6470	984	<p class="issue">
dbaron@6470	985	If there are multiple boundaries between this line
dbaron@6470	986	and the previous, where exactly (in terms of element
dbaron@6470	987	boundaries) is the break forced?
dbaron@6470	988	</p>
dbaron@6470	989
dbaron@6470	990	<p>
dbaron@6470	991	Only positive integers are accepted.
dbaron@6470	992	Zero or negative integers are a parse error.
dbaron@6470	993	</p>
dbaron@6470	994	</dd>
dbaron@6470	995	</dl>
dbaron@6470	996
dbaron@6484	997	<p class="issue">Should this apply to fragment overflow only, or also
florian@15296	998	to pagination?
florian@15296	999	Given what we're doing with the continue property,
florian@15296	1000	it should actually apply to any fragmentainer.</p>
florian@15296	1001
florian@15296	1002	Issue: having max-lines do nothing on regular elements is not ideal.
florian@15296	1003	When applied to non fragmentainers,
florian@15296	1004	it should probably cause 'continue' to compute to ''continue/discard''
florian@15296	1005	so that you only need to reach for one property rather than 2 to get
florian@15296	1006	that effect.
dbaron@6470	1007
dbaron@6479	1008	<div class="example">
git@19338	1009	<table class="source-demo-pair"><tr><td>
git@19338	1010	<pre><code highlight="html">&lt;!DOCTYPE HTML&gt;
dbaron@6479	1011	&lt;style&gt;
dbaron@6479	1012	.article {
florian@15278	1013	continue: fragments;
dbaron@6479	1014	}
dbaron@6479	1015	.article::first-letter {
dbaron@6479	1016	font-size: 2em;
dbaron@6479	1017	line-height: 0.9;
dbaron@6479	1018	}
dbaron@6484	1019	.article::nth-fragment(1) {
dbaron@6479	1020	font-size: 1.5em;
dbaron@6479	1021	max-lines: 3;
dbaron@6479	1022	}
dbaron@6491	1023	.article::nth-fragment(2) {
dbaron@6479	1024	column-count: 2;
dbaron@6479	1025	}
dbaron@6479	1026	&lt;/style&gt;
dbaron@6479	1027	&lt;div class="article"&gt;
dbaron@6479	1028	<i>...</i>
git@19338	1029	&lt;/div&gt;</code></pre></td><td>
dbaron@6479	1030	<div class="article-max-lines-demo one">The max-lines property allows<br>authors to use a larger font for the first<br>few lines of an article. Without the</div>
dbaron@6479	1031	<div class="article-max-lines-demo two">max-lines property, authors<br>might have to use the<br>'height' property instead, but<br>that would leave a slight gap<br>if the author miscalculated<br>how much height a given<br>number of lines would<br>occupy (which might be</div>
dbaron@6479	1032	<div class="article-max-lines-demo three">particularly hard if the author<br>didn't know what text would<br>be filling the space, exactly<br>what font would be used, or<br>exactly which platform's font<br>rendering would be used to<br>display the font).</div>
dbaron@6479	1033	</td></tr></table>
dbaron@6479	1034	</div>
dbaron@6478	1035
git@19337	1036	Privacy and Security Considerations {#priv-sec}
git@19337	1037	===============================================
git@19337	1038
git@19337	1039	This specification introduces no new security considerations.
git@19337	1040
git@19337	1041	The <a href="http://www.w3.org/2001/tag/">TAG</a> has developed a <a href="https://www.w3.org/TR/security-privacy-questionnaire/">self-review questionaire</a>
git@19337	1042	to help editors and Working Groups evaluate the risks introduced by their specifications.
git@19337	1043	Answers are provided below.
git@19337	1044
git@19337	1045	<dl>
git@19337	1046	<dt>Does this specification deal with personally-identifiable information?
git@19337	1047	<dd>No.
git@19337	1048
git@19337	1049	<dt>Does this specification deal with high-value data?
git@19337	1050	<dd>No.
git@19337	1051
git@19337	1052	<dt>Does this specification introduce new state for an origin that persists across browsing sessions?
git@19337	1053	<dd>No.
git@19337	1054
git@19337	1055	<dt>Does this specification expose persistent, cross-origin state to the web?
git@19337	1056	<dd>No.
git@19337	1057
git@19337	1058	<dt>Does this specification expose any other data to an origin that it doesn’t currently have access to?
git@19337	1059	<dd>No.
git@19337	1060
git@19337	1061	<dt>Does this specification enable new script execution/loading mechanisms?
git@19337	1062	<dd>No.
git@19337	1063
git@19337	1064	<dt>Does this specification allow an origin access to a user’s location?
git@19337	1065	<dd>No.
git@19337	1066
git@19337	1067	<dt>Does this specification allow an origin access to sensors on a user’s device?
git@19337	1068	<dd>No.
git@19337	1069
git@19337	1070	<dt>Does this specification allow an origin access to aspects of a user’s local computing environment?
git@19337	1071	<dd>No.
git@19337	1072
git@19337	1073	<dt>Does this specification allow an origin access to other devices?
git@19337	1074	<dd>No.
git@19337	1075
git@19337	1076	<dt>Does this specification allow an origin some measure of control over a user agent’s native UI?
git@19337	1077	<dd>No
git@19337	1078
git@19337	1079	<dt>Does this specification expose temporary identifiers to the web?
git@19337	1080	<dd>No.
git@19337	1081
git@19337	1082	<dt>Does this specification distinguish between behavior in first-party and third-party contexts?
git@19337	1083	<dd>No.
git@19337	1084
git@19337	1085	<dt>How should this specification work in the context of a user agent’s "incognito" mode?
git@19337	1086	<dd>No difference in behavior is needed.
git@19337	1087
git@19337	1088	<dt>Does this specification persist data to a user’s local device?
git@19337	1089	<dd>No.
git@19337	1090
git@19337	1091	<dt>Does this specification have a "Security Considerations" and "Privacy Considerations" section?
git@19337	1092	<dd>Yes, this is the section you are currently reading.
git@19337	1093
git@19337	1094	<dt>Does this specification allow downgrading default security characteristics?
git@19337	1095	<dd>No.
git@19337	1096	</dl>
git@19337	1097
git@19333	1098	<h2 id="changes" class="no-num">
git@19333	1099	Changes</h2>
git@19333	1100	<h3 id="changes-l3">
git@19333	1101	Changes Since Level 3</h3>
dbaron@6493	1102
git@19333	1103	The following changes were made to this specification since the
git@19333	1104	<a href="https://drafts.csswg.org/css-overflow-3/">CSS Overflow Module Level 3</a>:
git@19333	1105
git@19333	1106	<ul>
git@19333	1107	<li>The Fragmentation of overflow, Paginated overflow, and Fragment overflow sections and subsections have been removed form Level 3 and moved to Level 4.
git@19333	1108	<li>The 'scrollbar-gutter' property has been added.
git@19333	1109	</ul>
dbaron@6493	1110
dbaron@6470	1111	<h2 class=no-num id="acknowledgments">
dbaron@6470	1112	Acknowledgments</h2>
dbaron@6470	1113
dbaron@6470	1114	<p>
dbaron@6470	1115	Thanks especially to the feedback from
dbaron@6496	1116	Rossen Atanassov,
dbaron@6496	1117	Bert Bos,
dbaron@6496	1118	Tantek Çelik,
dbaron@6496	1119	John Daggett,
dbaron@6496	1120	fantasai,
dbaron@6496	1121	Daniel Glazman,
dbaron@6496	1122	Vincent Hardy,
dbaron@6470	1123	H&aring;kon Wium Lie,
dbaron@6496	1124	Peter Linss,
dbaron@7815	1125	Robert O'Callahan,
dbaron@6470	1126	Florian Rivoal,
dbaron@6473	1127	Alan Stearns,
dbaron@6496	1128	Steve Zilles,
dbaron@6470	1129	and all the rest of the
dbaron@6470	1130	<a href="http://lists.w3.org/Archives/Public/www-style/">www-style</a> community.