Overview.bs

<pre class="metadata">
Title: CSS Overflow Module Level 4
Status: ED
Work Status: Revising
ED: https://drafts.csswg.org/css-overflow-4/
Shortname: css-overflow
Group: csswg
Level: 4
TR: https://www.w3.org/TR/css-overflow-4/
Editor: L. David Baron, Google https://www.google.com/, https://dbaron.org/, w3cid 15393
Editor: Florian Rivoal, On behalf of Bloomberg, http://florian.rivoal.net/, w3cid 43241
Editor: Elika J. Etemad / fantasai, Apple, http://fantasai.inkedblade.net/contact, w3cid 35400
Abstract: This module contains the features of CSS relating to scrollable overflow handling in visual media.
	It builds on the <a href="https://www.w3.org/TR/css-overflow-3/">CSS Overflow Module Level 3</a>,
	defining
	'line-clamp', its longhands, and its legacy pre-standard syntax;
	adding a 'block-ellipsis' property;
	and expanding 'overflow-clip-margin' with longhands.
At Risk: ''continue: discard''
</pre>
<pre class="link-defaults">
type: dfn; spec:css-multicol-1; text:overflow column
spec:css-pseudo-4; type:selector; text:::first-letter
spec:css-pseudo-4; type:selector; text:::first-line
spec:css-writing-modes-4; type:dfn; text:start
spec:css-writing-modes-4; type:dfn; text:end
</pre>
<pre class="anchors">
url: https://drafts.csswg.org/selectors-3/#subject; type: dfn; text: subject;
url: https://www.w3.org/TR/CSS21/visudet.html#strut; type: dfn; text: strut;
</pre>
<pre class=metadata>
WPT Display: closed
WPT Path Prefix: /css/css-overflow/line-clamp/
</pre>
	<style>
		table.source-demo-pair {
			width: 100%;
		}

		.in-cards-demo {
			width: 13em;
			height: 8em;

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

			font: medium/1.3 Times New Roman, Times, serif;
			white-space: nowrap;
		}

		.bouncy-columns-demo {
			width: 6em;
			height: 10em;
			float: left;
			margin: 1em;
			font: medium/1.25 Times New Roman, Times, serif;
			white-space: nowrap;
		}
		.bouncy-columns-demo.one {
			background: aqua; color: black;
			transform: rotate(-3deg);
		}
		.bouncy-columns-demo.two {
			background: yellow; color: black;
			transform: rotate(3deg);
		}

		.article-font-inherit-demo {
			font: 1em/1.25 Times New Roman, Times, serif;
			white-space: nowrap;
		}
		.article-font-inherit-demo.one {
			width: 12em;
			font-size: 1.5em;
			margin-bottom: 1em;
			height: 4em;
		}
		.article-font-inherit-demo.two {
			width: 11em;
			margin-left: 5em;
			margin-right: 2em;
		}

		.dark-columns-demo {
			width: 6em;
			height: 10em;
			float: left;
			margin-right: 1em;
			font: medium/1.25 Times New Roman, Times, serif;
			white-space: nowrap;
		}
		.dark-columns-demo.one {
			background: aqua; color: black;
		}
		.dark-columns-demo.one :link {
			color: blue;
		}
		.dark-columns-demo.one :visited {
			color: purple;
		}
		.dark-columns-demo.two {
			background: navy; color: white;
		}
		.dark-columns-demo.two :link {
			color: aqua;
		}
		.dark-columns-demo.two :visited {
			color: fuchsia;
		}

		.article-max-lines-demo {
			font: 1em/1.25 Times New Roman, Times, serif;
			white-space: nowrap;
		}
		.article-max-lines-demo.one::first-letter {
			font-size: 2em;
			line-height: 0.9;
		}
		.article-max-lines-demo.one {
			font-size: 1.5em;
			width: 16em;
		}
		.article-max-lines-demo.two {
			width: 11.5em;
			float: left; margin-right: 1em;
		}
		.article-max-lines-demo.three {
			width: 11.5em;
			float: left;
		}
		.awesome-table td { padding: 5px; }
		.awesome-table {
			color: #000;
			background: #fff;
			margin: auto;
		}
	</style>

<h2 id="intro">
Introduction</h2>

	This specification extends [[!CSS-OVERFLOW-3]].
	It contains several primary sections:

	: [[#overflow-properties|Overflow Scrolling and Clipping Controls]]
	::
		This section defines relatively simple extensions to the 'overflow-*' properties [[css-overflow-3#overflow-properties|in Level 3]].

	: [[#auto-ellipsis|Automatic Ellipses]].
	::
		This section defines some experimental extensions to the '*-ellipsis' properties [[css-overflow-3#auto-ellipsis|in Level 3]].

	Note: At the time of writing, [[CSS-OVERFLOW-3]] is not completely finalized yet.
	To avoid accidental divergences and maintenance overhead,
	This specification is written as a delta specification over css-overflow Level 3.
	Once the level 3 specification is final,
	its content will be integrated into this specification,
	which will then replace it.
	Until then, this specification only contains additions and extensions to level 3.

<h3 id="values">
Value Definitions</h3>

	This specification follows the <a href="https://www.w3.org/TR/CSS2/about.html#property-defs">CSS property definition conventions</a> from [[!CSS2]]
	using the <a href="https://www.w3.org/TR/css-values-3/#value-defs">value definition syntax</a> from [[!CSS-VALUES-3]].
	Value types not defined in this specification are defined in CSS Values &amp; Units [[!CSS-VALUES-3]].
	Combination with other CSS modules may expand the definitions of these value types.

	In addition to the property-specific values listed in their definitions,
	all properties defined in this specification
	also accept the <a>CSS-wide keywords</a> as their property value.
	For readability they have not been repeated explicitly.

<h3 id="placement">
Module Interactions</h3>

	This module extends features defined in [[!CSS-OVERFLOW-3]].

<h2 id="overflow-concepts">
Overflow Concepts and Terminology</h2>

	Issue: Copy [[css-overflow-3#overflow-concepts|Level 3 content]] when final.


<h2 id="overflow-properties">
Scrolling and Clipping Overflow</h2>

	Issue: Copy [[css-overflow-3#overflow-properties|Level 3 content]] when final.

<h3 id="overflow-control">
Managing Overflow: the 'overflow-x', 'overflow-y', and 'overflow' properties</h3>

	This level extends the 'overflow-x' and 'overflow-y' properties
	(and 'overflow' [=shorthand=])
	to apply to [=replaced elements=].

	On [=replaced elements=],
	the [=used values=]
	of all computed values other than ''overflow/visible''
	is ''overflow/clip''.
	Host languages should define [=UA style sheet=] rules
	that apply a default value of ''overflow/clip'' to such elements
	and set their 'overflow-clip-margin' to ''overflow-clip-margin/content-box''.

	Note: Application of 'overflow' to [=replaced elements=] was added
	to allow images to paint effects outside their effective layout box;
	the recommended UA style sheet rules are to effect their original behavior as a default.
	See discussion in <a href="https://github.com/w3c/csswg-drafts/issues/7058">Issue 7059</a>
	and <a href="https://github.com/w3c/csswg-drafts/issues/7144">Issue 7144</a>.
	This is a change from <a href="https://www.w3.org/TR/CSS2/">CSS2.1</a>
	and is at-risk.

	ISSUE(7144): Application of 'overflow' to [=replaced elements=]
	is still being worked out.

<h3 id="overflow-clip-margin">
Expanding Clipping Bounds: the 'overflow-clip-margin-*' properties</h3>

	<pre class="propdef shorthand">
	Name: overflow-clip-margin-top, overflow-clip-margin-right, overflow-clip-margin-bottom, overflow-clip-margin-left, overflow-clip-margin-block-start, overflow-clip-margin-inline-start, overflow-clip-margin-block-end, overflow-clip-margin-inline-end
	Value: <<visual-box>> || <<length [0,∞]>>
	Initial: ''0px''
	Inherited: no
	Logical property group: overflow-clip-margin
	Applies to: boxes to which 'overflow' applies
	Computed value: the computed <<length>> and a <<visual-box>> keyword
	Animation type: per computed value if the <<visual-box>> values match; otherwise discrete
	</pre>

	<pre class="propdef shorthand">
	Name: overflow-clip-margin, overflow-clip-margin-inline, overflow-clip-margin-block
	Value: <<visual-box>> || <<length [0,∞]>>
	Initial: ''0px''
	Inherited: no
	Applies to: boxes to which 'overflow' applies
	</pre>

	These properties and their shorthands
	define the <dfn export>overflow clip edge</dfn> of the box,
	i.e. precisely <em>how far</em> outside its bounds
	the box’s content is allowed to paint
	before being clipped
	by effects (such as ''overflow: clip'', above)
	that are defined to clip to the box’s [=overflow clip edge=].
	The [=shorthand=]/[=longhand=] relationships are as for 'margin',
	but note that the [=shorthands=] have a restricted syntax.

	Values are defined as follows:

	<dl dfn-type=value dfn-for=overflow-clip-margin>
		: <dfn><<visual-box>></dfn>
		::
			Specifies the box edge to use as the [=overflow clip edge=] origin,
			i.e. when the specified offset is zero.

			If omitted,
			defaults to ''overflow-clip-margin/padding-box'' on non-[=replaced=] elements,
			or ''overflow-clip/content-box'' on [=replaced=] elements.

			ISSUE(7144): Application of 'overflow-clip-margin' to [=replaced elements=]
			is still being worked out.

		: <dfn><<length [0,∞]>></dfn>
		::
			The specified offset dictates
			how much the [=overflow clip edge=] is expanded from
			the specified box edge
			Negative values are invalid.
			Defaults to zero if omitted.
	</dl>

	The [=overflow clip edge=] is shaped in the corners
	exactly the same way as an <a spec=css-backgrounds-3>outer box-shadow</a>
	with a spread radius of the same cumulative offset
	from the box’s [=border edge=].
	See [[css-backgrounds-3#corner-shaping]]
	and [[css-backgrounds-3#shadow-shape]],
	noting in particular the formula for outsets beyond the [=border edge=].

	Note: This property has no effect on boxes
	with ''overflow: hidden'' or ''overflow: scroll'',
	which are not defined to use the [=overflow clip edge=].


<h2 id="auto-ellipsis">
Automatic Ellipses</h2>

<h3 id="text-overflow" caniuse="text-overflow">
Inline Overflow Ellipsis: the 'text-overflow' property</h3>

	<pre class="propdef">
	Name: text-overflow
	Value: [ clip | ellipsis | <<string>> | fade | <<fade()>> ]{1,2}
	Initial: clip
	Applies to: block containers
	Inherited: no
	Percentages: refer to the width of the line box
	Computed value: as specified, with lengths made absolute
	Animation type: by computed value type
	</pre>

	<wpt>
		line-clamp-auto-009.html
		line-clamp-auto-010.html
		webkit-line-clamp-036.html
		webkit-line-clamp-037.html
		line-clamp-with-text-overflow-string-003.html
	</wpt>

	ISSUE: This section might need to be re-synced against [[CSS-OVERFLOW-3]].

	This property specifies rendering when inline content overflows
	its line box edge
	in the inline progression direction of its block container element ("the block")
	that has 'overflow'
	other than ''overflow/visible''.

	Even though this property is not inherited,
	anonymous block container boxes generated to
	establish the line box's <a>inline formatting context</a> (see [=block container=])
	are ignored,
	and the value of the property that applies is the one
	on the non anonymous box.
	<span class=note>This can be seen in the “nested paragraph” part of <a href="#example-44082941">example 7</a>:
	even though the word “NESTED” is wrapped in an anonymous block container
	whose 'text-overflow' property has the initial value,
	it is ellipsed.</span>

	Text can overflow for example when it is prevented from wrapping
	(e.g. due to <code class="lang-css">white-space: nowrap</code>
	or a single word is too long to fit).
	Values have the following meanings:

	<dl dfn-for="text-overflow" dfn-type=value>
		<dt><dfn id=overflow-clip>clip</dfn>
		<dd>
			Clip inline content that overflows its block container element.
			Characters may be only partially rendered.

		<dt><dfn id=overflow-ellipsis>ellipsis</dfn>
		<dd>
			Render an ellipsis character (U+2026)
			to represent clipped inline content.
			Implementations may substitute a more language, script, or writing-mode appropriate
			ellipsis character,
			or three dots "..." if the ellipsis character is unavailable.

		<dt id=overflow-string><<string>>
		<dd>
			Render the given string to represent clipped inline content.
			The given string is treated as an independent paragraph
			for bidi purposes.

		<dt dfn-type=function><dfn>fade( [ <<length-percentage>> ] )</dfn>
		<dd>
			Clip inline content that overflows its line box.
			Characters may be only partially rendered.
			In addition, the UA must apply a fade out effect
			near the edge of the line box,
			reaching complete transparency at the edge.

			Issue: Do we need to define the way
			the fade out is calculated
			so that the fading is identical across browsers?
			It should probably be something like
			''mask-image: linear-gradient(to right, rgba(0,0,0,1), rgba(0,0,0,0))'',
			except applied to the relevant portion of the line only.

			The argument determines the distance
			over which the fade effect is applied.
			The <<percentage>> is resolved against the width of the line box.
			Values lower than 0 are clipped to 0.
			Values greater than the width of the line box are clipped to the width of the line box.

			Issue: If the line box is too short
			to display the fade effect at the desired length,
			should we drop the effect,
			or shrink the distance it is applied over until it fits,
			or clip the end of the fade?

			Issue: How should we deal with
			things overflowing out of the line box,
			or overlapping onto it?
			Should fade apply to the logical content of the line,
			or to the physical area of the line box,
			or the intersection of both?

		<dt><dfn>fade</dfn>
		<dd>
			Same as ''fade()'',
			but the distance over which the fading effect is applied
			is determined by the UA.
			''1em'' is suggested as a reasonable value.
	</dl>

	The term "character" is used in this property definition
	for better readability and means "grapheme cluster" [[!UAX29]]
	for implementation purposes.

	If there is one value,
	it applies only to the <a>end</a> line box edge.
	If there are two values,
	the first value applies to the <a>line-left</a> edge,
	and the second value applies to the <a>line-right</a> edge.
	The terms <a>end</a>, <a>line-left</a> and <a>line-right</a> are defined in [[!CSS-WRITING-MODES-3]].

	Note: the use of <a>line-left</a> and <a>line-right</a>
	rather than <a>start</a> and <a>end</a>
	when there are two values is intentional,
	to facilitate the use of directional characters such as arrows.

	For the ellipsis
	and string values,
	implementations must hide characters and
	<a href="https://www.w3.org/TR/CSS2/visuren.html#inline-boxes">
	atomic inline-level elements</a>
	at the applicable edge(s) of the line as necessary to fit the ellipsis/string, and
	place the ellipsis/string immediately adjacent
	to the applicable edge(s) of the remaining inline content.
	The first character or
	<a href="https://www.w3.org/TR/CSS2/visuren.html#inline-boxes">
	atomic inline-level element</a>
	on a line
	must be clipped rather than ellipsed.

	<div class=example>
		<h3 id="bidi-ellipsis" class="no-num no-toc">Bidi ellipsis examples</h3>

		These examples demonstrate which characters get hidden
		to make room for the ellipsis in a bidi situation:
		those visually at the edge of the line.

		Sample CSS:
		<pre><code highlight=css>
		div {
			font-family: monospace;
			white-space: pre;
			overflow: hidden;
			width: 9ch;
			text-overflow: ellipsis;
		}
		</code></pre>

		Sample HTML fragments, renderings, and your browser:
		<table class="awesome-table data">
			<thead><th>HTML<th>Reference rendering<th>Your Browser</thead>
			<tr>
			<td><code highlight=html>&lt;div>שלום 123456&lt;/div></code><td><div style="font-family:monospace">123456 ם…</div><td><div style="font-family: monospace; white-space: pre; overflow: hidden; width: 9ch; text-overflow: ellipsis">שלום 123456</div>
			<tr><td><code highlight=html>&lt;div dir=rtl>שלום 123456&lt;/div></code><td><div style="font-family:monospace">…456 שלום</div><td><div style="font-family: monospace; white-space: pre; overflow: hidden; width: 9ch; text-overflow: ellipsis" dir=rtl>שלום 123456</div>
		</table>
	</div>


<h3 id="ellipsing-details" class="no-num no-toc">
ellipsing details</h3>

	<ul>
		<li>
			Ellipsing only affects rendering and must not affect layout
			nor dispatching of pointer events:
			The UA should dispatch any pointer event on the ellipsis to the elided element,
			as if 'text-overflow' had been ''text-overflow/none''.

		<li>
			The ellipsis is styled and baseline-aligned according to the block.

		<li>
			Ellipsing occurs after relative positioning and other graphical transformations.

		<li>
			If there is insufficient space for the ellipsis,
			then clip the rendering of the ellipsis itself
			(on the same side that neutral characters on the line
			would have otherwise been clipped with the ''text-overflow:clip'' value).
	</ul>


<h3 id="ellipsis-interaction" class="no-num no-toc">
user interaction with ellipsis</h3>

	<ul>
		<li>
			When the user is interacting with content
			(e.g. editing, selecting, scrolling),
			the user agent may treat ''text-overflow/ellipsis'', string values, ''overflow-text/fade'' or ''overflow-text/fade()'' as ''text-overflow:clip''.

		<li>
			Selecting the ellipsis should select the ellipsed text.
			If all of the ellipsed text is selected,
			UAs should show selection of the ellipsis.
			Behavior of partially-selected ellipsed text is up to the UA.
	</ul>

	<div class="example">
		<h3 id="text-overflow-examples" class="no-num no-toc">text-overflow examples</h3>

		These examples demonstrate setting the text-overflow of a block container element
		that has text which overflows its dimensions:

		sample CSS for a div:
		<pre><code class="lang-css">
		div {
			font-family: Helvetica, sans-serif;
			line-height: 1.1;
			width: 3.1em;
			border: solid .1em black;
			padding: 0.2em; margin:1em 0;
		}
		</code></pre>

		sample HTML fragments, renderings, and your browser:
		<table class="awesome-table"><tbody>
		<tr>
			<th>HTML
			<th>sample rendering
			<th>your browser

		<tr>
			<td>
				<pre><code class="lang-markup">
				&lt;div&gt;
				CSS IS AWESOME, YES
				&lt;/div&gt;
				</code></pre>

			<td>
				<object type="image/png" data="images/cssisawesome.png">
				First, a box with text drawing outside of it.
				</object>

			<td>
				<div style="width:3.1em; border:solid .1em black; margin:1em 0; padding:.2em; font-family:Helvetica,sans-serif; line-height:1.1;">CSS IS AWESOME, YES</div>

		<tr>
			<td>
				<pre><code class="lang-markup">
				&lt;div style="<strong>text-overflow:clip;</strong> overflow:hidden"&gt;
				CSS IS AWESOME, YES
				&lt;/div&gt;
				</code></pre>

			<td>
				<object type="image/png" data="images/cssisaweso.png">
				Second, a similar box with the text clipped outside the box.
				</object>

			<td>
				<div style="width:3.1em; border:solid .1em black; margin:1em 0; padding:.2em; font-family:Helvetica,sans-serif; line-height:1.1; overflow:hidden;text-overflow:clip;">CSS IS AWESOME, YES</div>

		<tr>
			<td>
				<pre><code class="lang-markup">
				&lt;div style="<strong>text-overflow:ellipsis;</strong> overflow:hidden"&gt;
				CSS IS AWESOME, YES
				&lt;/div&gt;
				</code></pre>

			<td>
				<object type="image/png" data="images/cssisaw.png">
				Third, a similar box with an ellipsis representing the clipped text.
				</object>

			<td>
				<div style="width:3.1em; border:solid .1em black; margin:1em 0; padding:.2em;  font-family:Helvetica,sans-serif; line-height:1.1; overflow:hidden;text-overflow:ellipsis;">CSS IS AWESOME, YES</div>

		<tr>
			<td>
				<pre><code class="lang-markup">
				&lt;div style="<strong>text-overflow:ellipsis;</strong> overflow:hidden"&gt;
				NESTED
				 &lt;p&gt;PARAGRAPH&lt;/p&gt;
				WON'T ELLIPSE.
				&lt;/div&gt;
				</code></pre>

			<td>
				<object type="image/png" data="images/nes.png">
				Fourth, a box with a nested paragraph demonstrating anonymous block boxes equivalency and non-inheritance into a nested element.
				</object>

			<td>
				<div style="width:3.1em; border:solid .1em black; margin:1em 0; padding:.2em;  font-family:Helvetica,sans-serif; line-height:1.1; overflow:hidden;text-overflow:ellipsis;">NESTED
				 <p>PARAGRAPH</p>
				WON'T ELLIPSE.</div>

		<tr>
			<td>
				<pre><code class="lang-markup">
				&lt;div style="<strong>text-overflow:fade;</strong> overflow:hidden"&gt;
				CSS IS AWESOME, YES
				&lt;/div&gt;
				</code></pre>

			<td>
				<object type="image/png" data="images/cssisfade.png">
				a box with the text fading out on overflow.
				</object>

			<td>
				<div style="width:3.1em; border:solid .1em black; padding:.2em; font-family:Helvetica,sans-serif; line-height:1.1; overflow:hidden;text-overflow:clip;">CSS IS AWESOME, YES</div>
		</tbody></table>
	</div>

	Note: the side of the line that the ellipsis is placed depends on the 'direction' of the block.
	E.g. an overflow hidden right-to-left
	(<code class="lang-css">direction: rtl</code>)
	block clips inline content on the <a spec=css-writing-modes-3>left</a> side,
	thus would place a text-overflow ellipsis on the <a spec=css-writing-modes-3>left</a>
	to represent that clipped content.

	Issue: insert RTL example diagram here to illustrate note.


<h3 id="ellipsis-scrolling" class="no-num no-toc">
ellipsis interaction with scrolling interfaces</h3>

	This section applies to elements with text-overflow other than ''text-overflow:clip''
	(non-clip text-overflow)
	and overflow:scroll.

	When an element with non-clip text-overflow has overflow of scroll
	in the inline progression dimension of the text,
	and the browser provides a mechanism for scrolling
	(e.g. a scrollbar on the element,
	or a touch interface to swipe-scroll, etc.),
	there are additional implementation details that provide a better user experience:

	When an element is scrolled (e.g. by the user, DOM manipulation),
	more of the element's content is shown.
	The value of text-overflow should not affect
	whether more of the element's content is shown or not.
	If a non-clip text-overflow is set,
	then as more content is scrolled into view,
	implementations should show whatever additional content fits,
	only truncating content which would otherwise be clipped
	(or is necessary to make room for the ellipsis/string),
	until the element is scrolled far enough
	to display the edge of the content
	at which point that content should be displayed
	rather than an ellipsis/string.

	<div class="example">
		This example uses text-overflow on an element with overflow scroll
		to demonstrate the above described behavior.

		sample CSS:
		<pre><code class="lang-css">
		div.crawlbar {
			text-overflow: ellipsis;
			height: 2em;
			line-height: 1em;
			overflow: scroll;
			white-space: nowrap;
			width: 15em;
			border:1em solid black;
		}
		</code></pre>

		sample HTML fragment:
		<pre><code class="lang-markup">
		&lt;div class="crawlbar"&gt;
		CSS is awesome, especially when you can scroll
		to see extra text instead of just
		having it overlap other text by default.
		&lt;/div&gt;
		</code></pre>

		demonstration of sample CSS and HTML:
		<div style="text-overflow: ellipsis; height: 2em; line-height:1; overflow: scroll; white-space: nowrap; width: 15em; border:1em solid black;">
		CSS is awesome, especially when you can scroll
		to see extra text instead of just
		having it overlap other text by default.
		</div>
	</div>

	As some content is scrolled into view,
	it is likely that other content may scroll out of view on the other side.
	If that content's block container element is the same
	that's doing the scrolling,
	and the computed value of 'text-overflow' has two values, with
	the value applying to the start edge being a non-clip value,
	then implementations must render an ellipsis/string in place of
	the clipped content,
	with the same details as described in the value definition above,
	except that the ellipsis/string is drawn in the <a>start</a>
	(rather than <a>end</a>) of
	the block's direction (per the direction property).

	While the content is being scrolled,
	implementations may adjust their rendering of ellipses/strings
	(e.g. align to the box edges rather than line edges).

	<div class="example">
		Same as previous example except with <code>text-overflow: ellipsis ellipsis</code>, demonstrated:

		<div style="text-overflow: ellipsis ellipsis; height: 2em; line-height: 1em; overflow: scroll; white-space: nowrap; width: 15em; border:1em solid black;">
		CSS is awesome, especially when you can scroll
		to see extra text instead of just
		having it overlap other text by default.
		</div>
	</div>

	If there is insufficient space for both start
	and end ellipses/strings,
	then only the end ellipsis/string should be rendered.

<h3 id="block-ellipsis">
Indicating Block-Axis Overflow: the 'block-ellipsis' property</h3>

	<pre class=propdef>
		Name: block-ellipsis
		Value: no-ellipsis | auto | <<string>>
		Initial: no-ellipsis
		Applies to: [=block containers=]
		Inherited: yes
		Percentages: N/A
		Computed value: specified value
		Animation type: discrete
	</pre>

	<wpt pathprefix="/css/css-overflow/parsing/">
		block-ellipsis-invalid.html
		block-ellipsis-valid.html
	</wpt>

	This property allows inserting content into the last line box
	before a [=clamp point=] or a (forced <em>or</em> unforced) <a>region break</a>
	to indicate the continuity of truncated / interrupted content.
	It only affects line boxes contained directly by the <a>block container</a> itself,
	but as it inherits, will have an effect on descendants’ line boxes unless overridden.

	<wpt>
		block-ellipsis-011.html
		block-ellipsis-012.html
		block-ellipsis-022.html
		block-ellipsis-repaint-002.html
		line-clamp-auto-016.html
		line-clamp-auto-017.html
	</wpt>

	Ignoring any intervening [=absolutely positioned=] element
	or any element closing boundary,
	this property only affects a line box
	if it immediately precedes either a [=region break=] or a [=clamp point=],
	and the line box is in the same [=independent formatting context=]
	as the [=clamp point=] or the [=region break=].

	<wpt>
		line-clamp-auto-034.html
		line-clamp-auto-036.html
		line-clamp-auto-039.html
		line-clamp-auto-040.html
	</wpt>

	Note: See ''continue: discard'' for a way to generate boxes with such a [=region break=].

	The inserted content is called the <dfn>block overflow ellipsis</dfn>.
	Values have the following meanings:

	<dl dfn-for="block-ellipsis" dfn-type=value>
		<dt><dfn>no-ellipsis</dfn>
		<dd>
			The rendering is unaffected.

			<wpt>
				block-ellipsis-023.html
			</wpt>
		<dt><dfn>auto</dfn>
		<dd>
			Render an ellipsis character (U+2026)--
			or a more typographically-appropriate equivalent--
			as the <a>block overflow ellipsis</a>
			at the end of the affected line box.
			UAs should use the conventions of the
			<a>content language</a>,
			writing system, and
			<a>writing mode</a>
			to determine the most appropriate ellipsis string.

			<wpt>
				line-clamp-with-text-overflow-string-001.html
				line-clamp-with-text-overflow-string-002.html
				line-clamp-with-text-overflow-string-003.html
			</wpt>

		<dt><dfn><<string>></dfn>
		<dd>
			Render the specified string
			as the <a>block overflow ellipsis</a>
			at the end of the affected line box.
			The UA may truncate this string if it is absurdly long.

			When set to the empty string,
			the behavior is identical to the ''no-ellipsis'' value.

			<wpt>
				block-ellipsis-024.html
			</wpt>
	</dl>

	When 'block-ellipsis' is neither ''no-ellipsis'' nor the empty string,
	the [=block overflow ellipsis=] string
	is placed at the end of the line box
	reducing the space
	available to the other contents of the line.

	<wpt>
		block-ellipsis-023.html
		block-ellipsis-024.html
		block-ellipsis-repaint-001.html
		block-ellipsis-repaint-003.html
		block-ellipsis-repaint-004.html
	</wpt>

	More specifically:
	* The [=block overflow ellipsis=]
		is wrapped in an anonymous inline
		whose parent is the [=block container=]’s [=root inline box=].
		This inline is assigned ''unicode-bidi: plaintext''
		and ''line-height: 0''.

		<wpt>
			block-ellipsis-002.html
			block-ellipsis-003.html
			block-ellipsis-004.html
			block-ellipsis-005.html
			block-ellipsis-006.html
			block-ellipsis-010.html
		</wpt>

	* The user agent makes room as necessary of the [=block overflow ellipsis=]
		by displacing content from the end of the line as if wrapping,
		until the last <a>soft wrap opportunity</a> (see [[!CSS-TEXT-3]])
		that would still allow the entire <a>block overflow ellipsis</a> to fit on the line,
		applying [[css-text-4#white-space-rules]] including [[css-text-4#white-space-phase-2]]
		before insertion.

		<wpt>
			block-ellipsis-001.html
			block-ellipsis-028.html
			block-ellipsis-029.html
			block-ellipsis-030.html
			webkit-line-clamp-025.html
		</wpt>

		For this purpose, <a>soft wrap opportunities</a> added by 'overflow-wrap' are ignored,
		as are those inhibited by ''text-wrap-mode: nowrap''.

		<wpt>
			block-ellipsis-013.html
			block-ellipsis-014.html
			block-ellipsis-015.tentative.html
			block-ellipsis-016.html
			block-ellipsis-017.html
			block-ellipsis-027.html
		</wpt>

		If this results in the entire contents of the line box being displaced,
		the line box is considered to contain a [=strut=], as defined in [[CSS2/visudet#leading]].

		<wpt>
			block-ellipsis-016.html
			block-ellipsis-018.html
			block-ellipsis-025.html
		</wpt>

		Displacing content to make room for the [=block overflow ellipsis=]
		can cause the [=logical height=] of line box where it is inserted to shrink.
		This must not cause a reevaluation of the effects of the 'continue' property
		and must not change which line box is the last one before the truncated content.

		<wpt>
			line-clamp-auto-041.html
		</wpt>

	* The anonymous inline of [=block overflow ellipsis=] is placed
		after any remaining content,
		after [[css-text-4#white-space-phase-2]],
		as a direct child of the <a>block container</a>’s <a>root inline box</a>,
		with the appropriate bidi embedding levels
		given its directionality
		and that of its parent.

		<wpt>
			block-ellipsis-004.html
			block-ellipsis-005.html
			block-ellipsis-006.html
			block-ellipsis-026.html
			webkit-line-clamp-014.html
			webkit-line-clamp-032.html
			webkit-line-clamp-035.html
		</wpt>

	Text <a href="https://www.w3.org/TR/css-text-3/#justification">alignment and justification</a>
	occurs after placement,
	and measures the inserted <a>block overflow ellipsis</a>
	together with the rest of the line’s content.

	<wpt>
		webkit-line-clamp-051.html
		webkit-line-clamp-052.html
		webkit-line-clamp-053.html
	</wpt>

	Note: Setting the [=block overflow ellipsis=]'s 'line-height' to ''0''
	makes sure that inserting it cannot cause the line's height to grow,
	which could cause further relayouts and potentially cycles.
	This is almost equivalent to inserting the [=block overflow ellipsis=]
	as a paint-time operation, except that it still participates in alignment and justification.
	The downside is that unusually tall / deep glyphs in the [=block overflow ellipsis=]
	may overflow.

	The [=block overflow ellipsis=] must not be included
	in either the ''::first-letter'' nor the ''::first-line'' pseudo-elements.

	<wpt>
		block-ellipsis-007.html
		block-ellipsis-008.html
		block-ellipsis-009.html
		block-ellipsis-019.html
		block-ellipsis-020.html
		block-ellipsis-021.html
	</wpt>

	If the [=block overflow ellipsis=] is placed before a [=region break=] and
	there is a subsequent <a>fragmentation container</a> in the [=fragmentation context=]
	that would receive subsequent content,
	then the content displaced by the <a>block overflow ellipsis</a>
	must be pushed to that <a>fragmentation container</a>.
	If it is placed before a [=clamp point=],
	then the displaced content must be pushed to the remainder of the [=inline formatting context=].

	The UA must treat the <a>block overflow ellipsis</a> as an unbreakable string,
	If any part of the [=block overflow ellipsis=] overflows,
	it is treated as [=scrollable overflow=],
	and its rendering is affected by the 'text-overflow' property.

	The <a>block overflow ellipsis</a> does not capture events:
	pointer events are dispatched to whatever is underneath it.

	It also has no effect on the intrinsic size of the box:
	its <a lt="min-content size">min-content</a> and <a lt="max-content size">max-content</a> sizes
	are calculated exactly as if 'block-ellipsis' were ''no-ellipsis''.

	Note: Future specifications may extend this feature,
	for example by providing an ''::ellipsis'' pseudo-element
	to style the text,
	or by allowing the selection of a child element of the block
	to use as either an inline-level or block-level indicator
	(in which case, it can capture events).


<h2 id=suppressing-excess oldids=fragmentating-overflow>
Suppressing Excess Content</h2>

<h3 id=line-clamp>
Limiting Visible Lines: the 'line-clamp' shorthand property</h3>

	<pre class="propdef shorthand">
		Name: line-clamp
		Value: none | [<<integer [1,∞]>> || <<'block-ellipsis'>>] ''-webkit-legacy''?
		Initial: none
		Percentages: N/A
	</pre>

	<wpt pathprefix="/css/css-overflow/parsing/">
		line-clamp-valid.html
		line-clamp-invalid.html
	</wpt>

	The 'line-clamp' property is a <a>shorthand</a>
	for the 'max-lines', 'block-ellipsis', and 'continue' properties.

	It allows limiting the contents of a block container
	to the specified number of lines;
	remaining content is fragmented away
	and neither rendered nor measured.
	Optionally, it also allows inserting content into the last line box
	to indicate the continuity of truncated/interrupted content.

	<wpt>
		line-clamp-001.html
		webkit-line-clamp-034.html
	</wpt>

	The values have the following meaning:

	<dl dfn-for=line-clamp dfn-type=value>
		<dt><dfn>none</dfn>
		<dd>Sets 'max-lines' to ''max-lines/none'',
			'continue' to ''continue/auto'',
			and 'block-ellipsis' to ''no-ellipsis''.

			<wpt>
				line-clamp-020.html
				line-clamp-auto-038.html
				webkit-line-clamp-018.html
			</wpt>

		<dt><dfn><<integer [1,∞]>></dfn>
		<dt><dfn><'block-ellipsis'></dfn>
		<dd>

			Sets 'continue' to ''collapse''
			if either or both values are specified,
			unless the ''line-clamp/-webkit-legacy'' keyword is also specified.

			Sets 'max-lines' to the specified <<integer>>
			or to ''max-lines/none'' if omitted,
			and 'block-ellipsis' to other component of the value if specified
			or to ''block-ellipsis/auto'' if omitted.

			<wpt>
				line-clamp-auto-001-crash.html
				line-clamp-auto-002-crash.html
				line-clamp-auto-001.html
			</wpt>

		<dt><dfn>-webkit-legacy</dfn>
		<dd>Sets 'continue' to ''continue/-webkit-legacy''.

	</dl>

	See the corresponding longhand properties for details
	about how this mechanism operates.

	<div class="example">
		In this example, the lead paragraph of each article
		is listed in a shortened menu,
		truncated to fit within 5 lines
		that end with “… (continued on next page)”:

		<xmp highlight=css>
			li {
				line-clamp: 5 "… (continued on next page)";
			}
			strong {
				display: block;
				text-transform: uppercase;
			}
		</xmp>

		<xmp highlight=markup>
			<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>
		</xmp>

		Sample rendering:

		<pre class="figure">
			+---------------------------------------+
			| 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)  |
			+---------------------------------------+
		</pre>
	</div>

<h4 id=webkit-line-clamp>
Legacy compatibility</h4>

	For compatibility with legacy content,
	UAs that support 'line-clamp' must also support the '-webkit-line-clamp' property
	and the additional ''continue/-webkit-legacy'' value for the 'continue' property.

	<pre class="propdef shorthand">
		Name: -webkit-line-clamp
		Value: none | <<integer [1,∞]>>
		Initial: none
		Percentages: N/A
	</pre>

	<wpt>
		webkit-line-clamp-041-crash.html
		webkit-line-clamp-042-crash.html
		webkit-line-clamp-bug-1926732-crash.html
		webkit-line-clamp-049.html
	</wpt>

	<wpt pathprefix="/css/css-overflow/parsing/">
		webkit-line-clamp-valid.html
		webkit-line-clamp-invalid.html
	</wpt>

	<pre class="propdef partial">
		Name: continue
		New Values: -webkit-legacy
	</pre>

	Like 'line-clamp', '-webkit-line-clamp' is a shorthand of 'max-lines', 'block-ellipsis', and 'continue',
	except that:

	<wpt>
		line-clamp-019.html
		line-clamp-034.html
		webkit-line-clamp-005.html
	</wpt>

	* its syntax is ''line-clamp/none'' | <<integer [1,∞]>>
	* it unconditionally sets 'block-ellipsis' to ''block-ellipsis/auto''

		<wpt>
			webkit-line-clamp-003.html
			webkit-line-clamp-004.html
		</wpt>

	* it sets 'continue' to ''continue/-webkit-legacy'' instead of ''collapse''
		when an <<integer [1,∞]>> is specified
		(as if the ''line-clamp/-webkit-legacy'' keyword was set on 'line-clamp')

		<wpt>
			webkit-line-clamp-001.html
			webkit-line-clamp-002.html
			webkit-line-clamp-003.html
			webkit-line-clamp-004.html
		</wpt>

	The <dfn value for=continue>-webkit-legacy</dfn> value behaves identically to ''collapse'',
	except that it only takes effect
	if the [=specified value=] of the 'display' property
	is ''-webkit-box'' or ''-webkit-inline-box''
	and the value of the '-webkit-box-orient' property
	is ''-webkit-box-orient/vertical''.

	<wpt>
		webkit-line-clamp-001.html
		webkit-line-clamp-002.html
		webkit-line-clamp-007.html
		webkit-line-clamp-015.html
		webkit-line-clamp-016.html
		webkit-line-clamp-024.html
		webkit-line-clamp-026.html
		webkit-line-clamp-048.html
	</wpt>

	Note: Implementations of the legacy '-webkit-line-clamp' property
	have not behaved identically to what is specified here.
	The historical behavior is quirky and less robust,
	as documented for example in <a href="https://medium.com/mofed/css-line-clamp-the-good-the-bad-and-the-straight-up-broken-865413f16e5">this blog post</a>.
	The current design learns from the mistakes of that early experiment,
	and is intended to be sufficiently compatible with existing content
	that implementations can eventually be changed to follow to the specified behavior.
	If further adjustments are found to be necessary,
	they will be incorporated to this specification.
	In the meanwhile, authors should be aware that there may be discrepancies.

<h3 id="max-lines">
Forcing a Break After a Set Number of Lines: the 'max-lines' property</h3>

	<pre class=propdef>
		Name: max-lines
		Value: ''none'' | <<integer [1,∞]>>
		Initial: ''none''
		Applies to: <a>block containers</a> which are also either [=line-clamp containers=] or [=fragmentation containers=] that capture [=region breaks=]
		Inherited: no
		Percentages: N/A
		Computed value: the keyword ''max-lines/none'' or an integer
		Animation type: by computed value type
	</pre>

	<wpt pathprefix="/css/css-overflow/parsing/">
		max-lines-valid.html
		max-lines-invalid.html
	</wpt>
	<wpt>
		webkit-line-clamp-030.html
	</wpt>

	If the value of 'max-lines' is not <dfn for=max-lines dfn-type=value>none</dfn>,
	then, given a [=computed value=] of <var>N</var>:

	- If the box is a [=line-clamp container=],
		its [=line-based clamp point=] is set
		to the first possible clamp point after
		its <var>N</var>th
		descendant <a>in-flow</a> <a>line box</a>.
		If fewer than <var>N</var> line boxes exist,
		or if there are no possible clamp points
		after the <var>N</var>th descendant <a>in-flow</a> <a>line box</a>,
		then that line-clamp container has no [=line-based clamp point=].

		<wpt>
			block-ellipsis-022.html
			line-clamp-001.html
			line-clamp-002.html
			line-clamp-003.html
			line-clamp-005.html
			line-clamp-006.html
			line-clamp-030.html
			line-clamp-with-abspos-018.html
			webkit-line-clamp-003.html
			webkit-line-clamp-004.html
			webkit-line-clamp-005.html
			webkit-line-clamp-006.html
			webkit-line-clamp-009.html
			webkit-line-clamp-010.html
			webkit-line-clamp-017.html
			webkit-line-clamp-019.html
			webkit-line-clamp-020.html
			webkit-line-clamp-021.html
			webkit-line-clamp-022.html
			webkit-line-clamp-023.html
			webkit-line-clamp-030.html
			webkit-line-clamp-031.html
			webkit-line-clamp-033.html
			webkit-line-clamp-038.html
			webkit-line-clamp-039.html
			webkit-line-clamp-040.html
			webkit-line-clamp-043.html
			webkit-line-clamp-block-in-inline-001.html
			webkit-line-clamp-dynamic-001.html
			webkit-line-clamp-with-line-height.html
			webkit-line-clamp-with-max-height.html
			line-clamp-content-height-with-dynamic-change.html
		</wpt>

	- If the box is a [=fragmentation container=] that captures [=region breaks=],
		a <a>region break</a>
		is forced after its <var>N</var>th
		descendant <a>in-flow</a> <a>line box</a>.
		If fewer than <var>N</var> line boxes exist,
		then 'max-lines' introduces no <a>region break</a>.

	Only line boxes in the same <a>block formatting context</a>
	are counted:
	the contents of descendants that establish <a>independent formatting contexts</a>
	are skipped over while counting line boxes.

	<wpt>
		line-clamp-006.html
		webkit-line-clamp-011.html
		webkit-line-clamp-012.html
		webkit-line-clamp-013.html
		webkit-line-clamp-027.html
		webkit-line-clamp-029.html
	</wpt>

	Note: This implies that 'max-lines' has no effect when applied to [=multi-column containers=],
	since any line box they contain are nested into [=independent formatting contexts=].

	<wpt>
		discard/discard-multicol-004.html
	</wpt>

	Only positive integers are accepted.
	Zero or negative integers are invalid
	and must cause the declaration to be <a>ignored</a>.

	Note: The 'widows', 'orphans', and 'break-inside' properties
	do not affect the position of the forced <a>region break</a>
	introduced by the 'max-lines' property.

	<div class=note>
		Note: Despite the “region break” name, this is not a dependency on [[CSS-REGIONS-1]].
		The word “region” is only used as a classifier for forced breaks:
		they can be “page breaks” (breaks across pages [[css-page-3]]),
		“column breaks” (breaks across multi-column layout columns [[css-multicol-1]]),
		or “region breaks” (breaks across any other kind of CSS-induced <a>fragmentation containers</a>).

		If an implementation supports neither [[CSS-REGIONS-1]] nor ''continue: discard'',
		then it will have had no occasion yet to run into that kind of breaks,
		and this will be an addition.
		However the addition does not involve bringing over any of the [[CSS-REGIONS-1]] functionality.
		All that is needed is:

		* be able to fragment
		* classify these fragmentation containers as “Category 3”
			(i.e. not pages nor columns)
			for the purpose of forced breaks.
	</div>

<h3 id="continue">
Handling of Excess Content: the 'continue' property</h3>

	<pre class=propdef>
		Name: continue
		Value: auto | discard | collapse
		Initial: ''continue/auto''
		Applies to: [=block containers=] and [=multicol containers=]
		Inherited: no
		Percentages: N/A
		Computed value: specified keyword
		Animation type: discrete
	</pre>

	<wpt pathprefix="/css/css-overflow/parsing/">
		continue-valid.html
		continue-invalid.html
	</wpt>
	<wpt>
		line-clamp-014.html
		line-clamp-015.html
		line-clamp-029.html
	</wpt>

	The 'continue' property gives authors the ability
	to truncate/interrupt the content inside a box,
	either by visually hiding the remaining content,
	or by turning the box into a [=fragmentation container=] (see [[!CSS-BREAK-3]])
	and discarding the content after the [=fragmentation break=].

	<dl dfn-for="continue" dfn-type="value">
		<dt><dfn>auto</dfn>
		<dd>

			If the box has more content than can fit,
			the excess content is handled according to the usual rules.

		<dt><dfn>collapse</dfn>
		<dd>
			If the box is a [=block container=], then it must
			[=establish an independent formatting context=] that also becomes a [=line-clamp container=].
			This causes all content after the [=clamp point=] to be visually hidden, and to not be
			taken into account for the box's [=automatic block size=].

			<wpt>
				line-clamp-004.html
				line-clamp-008.html
				line-clamp-009.html
				line-clamp-013.tentative.html
				line-clamp-031.html
				webkit-line-clamp-006.html
				webkit-line-clamp-040.html
			</wpt>

			If the box is a [=multicol container=],
			the behavior is the same as ''continue/auto''.

		<dt><dfn>discard</dfn>
		<dd>
			The box must [=establish an independent formatting context=]
			and becomes a [=fragmentation container=]
			that captures <a>region breaks</a>,
			if it is not already.
			[[!CSS-BREAK-3]]
			Content after the first [=region break=] is not rendered.

			Note: This [=region break=] might be <a lt="forced break">forced</a>
			(e.g. imposed by 'max-lines' or by another mechanism,
			such as the 'break-before'/'break-after' properties)
			or [=unforced break|unforced=]
			(e.g. if the content would otherwise overflow this [=fragmentation container=]
			due to its size constraints).
			Breaks applying to other [=fragmentation contexts=]
			(such as pagination of this box itself)
			do not cause any content to be discarded.

			See [[#discarding-content]] for further details.

			Issue: ''continue: discard'' is meant to generalize and replace the <code>region-fragment</code> property from [[CSS-REGIONS-1]].
			Once it is sufficiently stable in this specification,
			<code>region-fragment</code> should be removed from the regions specification in favor of this.

			Note: ''continue: discard'' is [=at risk=]:
			it may be removed before advancement to [=Recommendation=]
			if criteria for advancement are not fulfilled.
	</dl>

	<div class=example id=ex-continue-overflow>
		Given,
		 as in the illustration bellow,
		an article with one excessively long overflowing line
		and four more lines in the [=block dimension=] than can fit,
		different renderings are possible based on the combination of the 'overflow' and 'continue' property.

		<figure>
		<img src="images/continue-flow.png" alt="article with one excessively long line and four more that can fit in the block direction">
		</figure>


		<style>
#ex-continue-overflow td { text-align: center; }
#ex-continue-overflow th:not(:first-child) { text-align: center; }
		</style>
		<table class=data>
			<thead>
			<tr>
				<th>
				<th>''continue: collapse'' /
					''continue: discard''
				<th>''continue: auto''

			<tbody>
			<tr>
				<th>''overflow: visible''

				<td style=vertical-align:top><img src="images/continue-discard-visible.png" alt=
				"rendering with continue:discard and overflow:visible"></td>

				<td><img src="images/continue-auto-visible.png"
				alt="rendering with continue:auto and overflow:visible"></td>
			</tr>

			<tr>
				<th>''overflow: hidden''

				<td><img src="images/continue-discard-hidden.png" alt=
				"rendering with continue:discard and overflow:hidden"></td>

				<td><img src="images/continue-auto-hidden.png"
				alt="rendering with continue:auto and overflow:hidden"></td>
			</tr>
		</table>

	</div>

	When 'text-wrap-style' is set to ''text-wrap-style/balance''
	on a block container whose 'continue' has a value other than ''continue/auto'',
	or which participates in the [=block formatting context=]
	established by an element whose 'continue' has a value other than ''continue/auto'',
	layout must first be computed as if 'text-wrap-style' were set to 'text-wrap-style/stable'.
	Then, after any excess content has been truncated
	and after any necessary [=block overflow ellipsis=] has been inserted,
	the remaining content must be rebalanced,
	as per ''text-wrap-style: balance''.
	If this rebalancing would cause the [=logical height=] of the content to grow,
	the cutoff point ([=clamp point=] or [=fragmentation break=]) must be reevaluated,
	and any necessary [=block overflow ellipsis=] reapplied accordingly.
	Whether to rebalance again after that is up to the user agent,
	but if it does so,
	it must always ensure that the constraints
	about the placement of the cutoff point are adhered to,
	no matter how many iterations it choose to make.

	<wpt>
		line-clamp-balance-001.html
		line-clamp-balance-002.html
		line-clamp-balance-003.html
		line-clamp-balance-004.html
		line-clamp-balance-005.html
		line-clamp-balance-006.html
		line-clamp-balance-007.html
		line-clamp-balance-008.html
		line-clamp-balance-009.html
		line-clamp-balance-010.html
		line-clamp-balance-011.html
		line-clamp-balance-012.html
	</wpt>

	For other values of 'text-wrap-style',
	whether to apply them before the effects of the 'continue' property,
	after, or both,
	is undefined in this level.

	Additionally,
	for compatibility (see [[#webkit-line-clamp]]),
	when the [=computed value=] of the 'continue' property is ''collapse'', ''continue/-webkit-legacy'', or ''discard''
	and the [=computed value=] of the '-webkit-box-orient' property is ''vertical'':
	* If the [=specified value=] of the 'display' property is ''-webkit-box'',
		the [=computed value=] becomes ''flow-root'' and
		the box establishes a [=BFC=].

		<wpt>
			line-clamp-016.html
			line-clamp-017.html
			line-clamp-018.html
			webkit-line-clamp-007.html
			webkit-line-clamp-008.html
			webkit-line-clamp-045.html
			webkit-line-clamp-046.html
		</wpt>

	* If the [=specified value=] of the 'display' property is ''-webkit-inline-box'',
		the [=computed value=] becomes ''inline-block'' and
		the box establishes a [=BFC=].

		<wpt>
			webkit-line-clamp-024.html
		</wpt>

	<wpt pathprefix="/css/css-overflow/parsing/">
		webkit-box-computed.html
	</wpt>

	Note: This means that 'line-clamp' (set without ''line-clamp/-webkit-legacy'') will work
	if both or neither of ''-webkit-box-orient: vertical''
	and ''display: -webkit-box'' or ''display: -webkit-inline-box'' are set,
	but not if ''display: -webkit-box'' or ''display: -webkit-inline-box'' is set
	while ''-webkit-box-orient: vertical'' isn't,
	as the box would be a [=flex container=] rather than a [=block container=],
	and thus the 'continue' property would not apply.

	<wpt>
		line-clamp-029.html
	</wpt>

<h4 id=line-clamp-containers>Line-clamp containers</h4>

	A <dfn export>line-clamp container</dfn> is an [=independent formatting context|independent=] [=block formatting context=]
	that additionally follows the rules in this section.
	Line-clamp containers can have a <dfn>clamp point</dfn>,
	which is one of the following block-axis positions inside it:

	- The start of the [=line-clamp container=].

		<wpt>
			line-clamp-auto-011.html
			line-clamp-auto-037.html
		</wpt>

	- A point between two consecutive [=line boxes=]
		in an [=inline formatting context=]
		contained by the line-clamp container's [=block formatting context=].

		<wpt>
			line-clamp-auto-004.html
			line-clamp-auto-005.html
			line-clamp-auto-013.html
			line-clamp-auto-014.html
			line-clamp-auto-016.html
			line-clamp-auto-017.html
			line-clamp-auto-with-ruby-001.html
			line-clamp-auto-with-ruby-002.html
			line-clamp-auto-with-ruby-003.html
			line-clamp-auto-with-ruby-004.html
			webkit-line-clamp-031.html
			webkit-line-clamp-040.html
		</wpt>

	- A point between two [=in-flow=] [=block-level=] sibling boxes
		in the line-clamp container's [=block formatting context=].

		<wpt>
			line-clamp-auto-034.html
			line-clamp-auto-035.html
			line-clamp-auto-036.html
		</wpt>

	<wpt>
		block-ellipsis-011.html
		block-ellipsis-012.html
		line-clamp-003.html
		line-clamp-auto-006.html
		line-clamp-auto-007.html
		line-clamp-auto-008.html
		line-clamp-auto-012.html
		line-clamp-auto-033.html
		webkit-line-clamp-004.html
	</wpt>

	The <dfn>auto clamp point</dfn> will be set to the last possible clamp point
	such that, for it and all previous possible clamp points,
	the line-clamp container's [=automatic block size=]
	(as determined below)
	is not greater than the [=block size=] the box would have
	if its automatic block size were infinite.
	If the [=block size=] would be infinite,
	then there is no [=auto clamp point=].
	Additionally,
	when the [=line-clamp container=]'s [=block formatting context root=]
	has a [=computed value=] of 'max-lines' other than ''max-lines/none'',
	then that property determines the <dfn>line-based clamp point</dfn>.
	The actual [=clamp point=] used is
	either the [=auto clamp point=] or the [=line-based clamp point=],
	choosing the earlier when both exist.

	<wpt>
		line-clamp-011.html
		line-clamp-035.html
		line-clamp-auto-001.html
		line-clamp-auto-004.html
		line-clamp-auto-005.html
		line-clamp-auto-006.html
		line-clamp-auto-007.html
		line-clamp-auto-008.html
		line-clamp-auto-011.html
		line-clamp-auto-012.html
		line-clamp-auto-013.html
		line-clamp-auto-014.html
		line-clamp-auto-016.html
		line-clamp-auto-033.html
		line-clamp-auto-035.html
		line-clamp-auto-036.html
		line-clamp-auto-037.html
		line-clamp-auto-039.html
		line-clamp-auto-040.html
		line-clamp-auto-with-ruby-002.html
		line-clamp-auto-with-ruby-003.html
		line-clamp-auto-with-ruby-004.html
		webkit-line-clamp-006.html
		webkit-line-clamp-031.html
		webkit-line-clamp-040.html
		webkit-line-clamp-with-line-height.html
		webkit-line-clamp-with-max-height.html
	</wpt>

	Within a [=line-clamp container=],
	the following boxes and line boxes become [=invisible boxes=]:

	- Any [=in-flow=] or floating boxes
		that follow the [=clamp point=] in the box tree.
		This includes [=independent formatting contexts=]
		and all of their descendants.

		<wpt>
			line-clamp-008.html
			line-clamp-026.html
			line-clamp-027.html
			line-clamp-028.html
			line-clamp-031.html
			line-clamp-032.html
			line-clamp-033.html
			line-clamp-auto-033.html
			line-clamp-auto-with-ruby-002.html
		</wpt>

	- Any [=line boxes=] that follow the [=clamp point=]
		inside an [=inline formatting context=].

		<wpt>
			line-clamp-010.html
			line-clamp-026.html
			line-clamp-027.html
			line-clamp-028.html
			webkit-line-clamp-040.html
		</wpt>

	- Any [=absolutely positioned box=]
		which has an invisible box within its [=containing block chain=],
		and all of its descendants.

		<wpt>
		line-clamp-with-abspos-001.html
		line-clamp-with-fixed-pos-001.html
		line-clamp-with-abspos-002.html
		line-clamp-with-fixed-pos-002.html
		line-clamp-with-abspos-003.html
		line-clamp-with-fixed-pos-003.html
		line-clamp-with-abspos-004.html
		line-clamp-with-fixed-pos-004.html
		line-clamp-with-abspos-005.html
		line-clamp-with-fixed-pos-005.html
		line-clamp-with-abspos-006.html
		line-clamp-with-fixed-pos-006.html
		line-clamp-with-abspos-007.html
		line-clamp-with-fixed-pos-007.html
		line-clamp-with-abspos-008.html
		line-clamp-with-fixed-pos-008.html
		line-clamp-with-abspos-009.html
		line-clamp-with-fixed-pos-009.html
		line-clamp-with-abspos-010.html
		line-clamp-with-fixed-pos-010.html
		line-clamp-with-abspos-011.html
		line-clamp-with-fixed-pos-011.html
		line-clamp-with-abspos-012.html
		line-clamp-with-fixed-pos-012.html
		line-clamp-with-abspos-013.html
		line-clamp-with-fixed-pos-013.html
		line-clamp-with-abspos-014.html
		line-clamp-with-fixed-pos-014.html
		line-clamp-with-abspos-015.html
		line-clamp-with-fixed-pos-015.html
		line-clamp-with-abspos-016.html
		line-clamp-with-fixed-pos-016.html
		line-clamp-with-abspos-017.html
		line-clamp-with-fixed-pos-017.html
		line-clamp-with-abspos-020.html
		line-clamp-with-abspos-021.html
		line-clamp-with-abspos-022.html
		line-clamp-with-abspos-023.html
		webkit-line-clamp-abspos-001.html
		</wpt>

	Any overflow such invisible boxes and line boxes might have
	is always counted as [=ink overflow=] rather than [=scrollable overflow=].

	<wpt>
		line-clamp-021.html
		line-clamp-with-abspos-019.html
	</wpt>

	NOTE: This differs from the ''display: none''-like behavior
	of not rendered content with ''continue: discard''.

	If a [=block container=] contains a [=clamp point=],
	within itself or in any of its descendants,
	its [=automatic block size=] will not take into account any invisible boxes.
	This also applies for the [=line-clamp container=] itself.

	<wpt>
		line-clamp-004.html
		line-clamp-009.html
		line-clamp-auto-004.html
		line-clamp-auto-005.html
	</wpt>

	NOTE: If there are any floats before the [=clamp point=],
	the [=line-clamp container=]'s automatic size must grow to encompass the clearance,
	just like it would if it were a regular [=block formatting context=] root
	that only contained its contents before the [=clamp point=].
	This is regardless of whether this would cause any content after the [=clamp point=]
	to be within the container's bounds.

<h4 id=discarding-content>Discarding Content</h4>

			Note: ''continue: discard'', and thus this subsection, is [=at risk=]:
			it may be removed before advancement to [=Recommendation=]
			if criteria for advancement are not fulfilled.

	Content that is “not rendered” due to ''continue: discard''
	is discarded, similar to ''display: none'':
		* It is not rendered.
		* It is also not made available for speech rendering.
		* It does not allow user interaction.
		* Issue(2970): Make sure effects on OM are well defined
		* Issue(2971): What about [=positioned=] elements whose static position is in the discarded content are not rendered?
			See also discussions in the <a href="https://lists.w3.org/Archives/Public/www-style/2018Jul/0030.html">Sydney F2F meeting</a>.

	However, since intrinsic sizes are calculated across <a>fragmentation containers</a>,
	this content <em>is</em> taken into account
	for the purpose of finding the box’s
	<a lt="min-content inline size">min-content</a> and <a>max-content</a> <a>inline sizes</a>
	(see [[css-break-3#varying-size-boxes]]).
	<a lt="min-content inline size">Min-content</a> and <a>max-content</a> <a>block sizes</a>
	are calculated based on the content
	from the start of the [=fragmented flow=]
	to the first [=forced break=] if any,
	or to the end of the [=fragmented flow=] if there is no forced break.

<!--
	Calculating intrinsic block sizes to the first forced <em>or unforced</em> break
	would cause intrinsic sizes to depend on layout, which would cause circularities.
-->

	Note: This differs from the ''visibility: hidden''-like behavior
	of content after the [=clamp point=] with ''continue: collapse''.

	Note: In the case of <a href="https://www.w3.org/TR/css-break-3/#parallel-flows">parallel fragmentation flows</a>,
	content occurring after the <a>fragmentation break</a> in the box tree
	could still be rendered,
	if it is laid out above the position
	representing the end of this <a>fragmentation container</a>.

	Additionally,
	if the box is a [=multi-column container=],
	any [=overflow columns=] are also not rendered,
	nor is any subsequent content--
	including any [=out of flow=] content
	whose static position is in or after overflow columns,
	nor is any additional [=multi-column line=] or [=multi-column row=]
	that would be generated to hold such content.

	<wpt>
		discard/discard-multicol-001.html
		discard/discard-multicol-002.html
		discard/discard-multicol-003.html
		discard/discard-multicol-004.html
	</wpt>

	<div class=example id=discard-overflow-column>
		In the absence of the 'continue' property,
		based on [[css-multicol-1 inline]],
		the following markup and associated CSS would be expected
		to render as follows.

		<xmp highlight=markup>
			<div class="multicol">
				<p>Column 1</p>
				<p>Column 2</p>
				<p>Column 3</p>
				<p>Overflow column
					<div class="spanner">Spanner 1</div>
				</p>
				<div class="spanner">Spanner 2</div>
				<p>Following 1</p>
				<p>Following 2</p>
				<p>Following 3</p>
				<div class="spanner">Spanner 3</div>
				<p>Following 4</p>
				<p>Following 5</p>
				<p>Following 6</p>
			</div>
		</xmp>
		<pre><code highlight=css>
			.multicol {
			  columns: 3;
			  border: solid 1px;
			}
			.multicol p {
			  break-after: column;
			  break-inside: avoid;
			}
			.spanner {
			  column-span: all;
			  text-align: center;
			}
		</code></pre>
		<!--
			ommitted because incidental to the example, but needed for an exact rendering:
			p { margin: 0; }
			.multicol {
			  width: 47ch;
			  font-family: monospace;
			  gap: 1ch;
			}
		-->
		<figure>
		<pre id=sample-rendering-overflow-multicolumn-1 style="width: 63ch">
		<div style="border:solid 1px; width: 47ch;">Column 1        Column 2        Column 3        Overflow column
						   Spanner 1
						   Spanner 2
		Following 1     Following 2     Following 3
						   Spanner 3
		Following 4     Following 5     Following 6
		</div></pre>
		</figure>

		There is one overflow column,
		a spanner whose static position is within that overflow column,
		another spanner whose static position is after the overflow column,
		inflow content after the spanners and the overflow column,
		and another spanner whose static position is in this subsequent inflow content.

		If we additionally apply the following style,
		everything starting from and including the overflow column is discarded.

		<pre><code highlight=css>
			.multicol {
			  continue: discard;
			  block-ellipsis: auto;
			}
		</code></pre>
		<figure>
		<pre id=sample-rendering-overflow-multicolumn-2>
		<div style="border:solid 1px; width: 47ch;">Column 1        Column 2        Column 3…</div></pre>
		</figure>
	</div>

<h2 id=sbg-ext class=nonum>
Appendix A: Possible extensions for ''scrollbar-gutter''</h2>

<i>This section is non-normative.</i>

<div class=non-normative>

Issue: This section documents current attempts
at extending the 'scrollbar-gutter' property
to solve additional use cases.
However, it does not currently have consensus.
It is presented here to encourage discussion,
but non-experimental implementation is not recommended.

	<div class=example>
		This example exercises all the additional values of the 'scrollbar-gutter' property:
		* ''scrollbar-gutter: always'' on the scroll container
		* ''scrollbar-gutter: match-parent'' on each row inside the scroll container

		<figure>
			<figcaption>With classic scrollbars</figcaption>
			<img srcset="images/scrollbar-gutter-complex-classic.png 2x">
		</figure>
		<figure>
			<figcaption>With overlay scrollbars</figcaption>
			<img srcset="images/scrollbar-gutter-complex-overlay.png 2x">
		</figure>
	</div>

<pre class="propdef partial">
Name: scrollbar-gutter
New Values: auto | [ [ stable | always ] && both-edges? ] || match-parent
Applies to: all elements
</pre>

For <a>overlay scrollbars</a>,
the precise width of the <a>scrollbar gutter</a>, if present, is UA defined.
However, it must not be 0,
and it must not change based on user interactions with the page or the scrollbar
even if the scrollbar itself changes,
with the expectation that it covers
the width of the overlay scrollbar in its widest form,
to the extent that this is well defined.

The new values of this property have the following meaning:

<dl dfn-for="scrollbar-gutter" dfn-type=value>
	<dt><dfn>always</dfn>
	<dd>
	The <a>scrollbar gutter</a> is always present when
	'overflow' is ''overflow/scroll'', ''overflow/hidden'', or ''overflow/auto'',
	regardless of the type of scrollbar or
	of whether the box is overflowing.

	<div class=example>
		''scrollbar-gutter: always'' can be bused to solve the problem
		of (small) interactive elements near the edge of the element
		getting covered by an appearing overlay scrollbar.
		A representative case would be a basic todo list,
		with each line starting with some text and ending with a right-aligned checkbox.
		With a classic scrollbar, everything is fine,
		but an overlay scrollbar could obscure the check boxes and make them hard to interact with.

		<figure>
			<figcaption>Checkboxes adjacent to a classic scrollbar</figcaption>
			<img
				src=images/todo-classic.png
				alt="
					A scrollable todo list with checkboxes on the right edge,
					adjacent to the scrollbar.
					This situation poses no particular problem.">
		</figure>
		<figure>
			<figcaption>Checkboxes and an overlay scrollbar</figcaption>
			<img
				src=images/todo-overlay.png
				alt="
					A scrollable todo list with checkboxes on the right edge.
					When the overlay scrollbar is hidden,
					the situation poses no particular problem,
					but when it pops in,
					it covers the checkboxes,
					getting in the way of interacting with them.">
		</figure>

		Overlay Scrollbar are typically transient and disappear when not interacted with,
		so the checkboxes they cover are not impossible to use.
		But when the scrollbar is shown it does get in the way,
		and that makes for an awkward interaction.
		The author might try and solve the problem by adding some right padding,
		but (1) how much?,
		and (2) that padding isn't needed in the case of classic scrollbars.
		''scrollbar-gutter: always'' solves this problem,
		yielding an identical result in first case of classic scrollbars,
		but adding the desired gutter with overlay scrollbars:

		<figure>
			<figcaption>Checkboxes and an overlay scrollbar and ''scrollbar-gutter: always''</figcaption>
			<img
				src=images/todo-overlay-always.png
				alt="
					A scrollable todo list with checkboxes on the right edge,
					shifted left by a gutter.
					Whether the overlay scrollbar is hidden or visible,
					the checkboxes remain uncovered,
					and can be interacted with.">
		</figure>
	</div>

	<div class=issue>
		Apple is reluctant to add this value,
		as authors may use it too broadly,
		inserting gutters with overlay scrollbars even when not justified by interactive elements,
		defeating the space-saving advantage of overlay scrollbars.

		An alternative solution has been suggested:
		as the focus is interactive elements,
		maybe we could have a property that applies to the elements
		that needs to avoid being under the scrollbar.
		When turned on, it would enlarge the right or left margin of the element as appropriate
		by just the right value
		to push it out from under an overlay scrollbar if that's where it would end up,
		but would leave the element unchanged otherwise.

		Possibly, an addition toggle would cause the element
		to enlarge both its inline-end and inline-start margins or neither,
		rather than just one.
		This could typically be useful for block-level descendants of the scroller
		with visible borders or background:
		adding space on one side to avoid collisions with the overlay scrollbar
		would make them look off-center when the scrollbar disappears.
		Increasing the margin on both sides avoids that.

		Yet another possibility is to have a choice between growing the margin to protect the element,
		or growing the padding to protect the element's content.

		The syntax could be something like <code>scrollbar-avoid: none | [self | content] && both-edges?</code>.

		An interesting consideration is that this may alleviate the need for ''scrollbar-gutter: match-parent'',
		as it seems that situations that would have been addressed by ''scrollbar-gutter: stable'' or ''scrollbar-gutter: always'' on the parent
		and ''scrollbar-gutter: match-parent'' on the select children
		could instead be addressed by leaving the parent as ''scrollbar-gutter: auto''
		and using <code>scrollbar-avoid: self</code> or <code>scrollbar-avoid: content</code> on the relevant children.
	</div>

	<dt><dfn>match-parent</dfn>
	<dd>
	On a [=block-level=] box whose parent has a [=scrollbar gutter=] (or gutters on both edges),
	this causes the box to have [=scrollbar gutter=]
	on the same side(s) and of the same width as its parent’s gutter(s).
	Moreover,
	that gutter is made to overlap that of the parent box.

	<figure>
		<img
			srcset="images/match-parent.png 2x"
			alt="The gutter of a ''scrollbar-gutter: match-parent'' box overlaps with that of its parent.">
	</figure>

	If the box with ''scrollbar-gutter: match-parent'' has a non-zero border or margin
	on the side where the gutter is expected,
	then the size of that box's gutter is <code>parent.gutter - child.border - child.margin</code>,
	and the gutter+border+margin is what collapses with the parent's gutter.

	If the box with ''scrollbar-gutter/ match-parent'' is itself a [=scroll container=],
	depending on the type of scrollbars,
	on its 'overflow' property,
	and on the other values of the 'scrollbar-gutter' property,
	it may need additional gutter for its own scrollbars.
	This comes in addition to the amount of gutter added for the sake of the ''scrollbar-gutter/match-parent'' value
	and does not collapse with the parent's gutter.

	<div class=example>
		<figure>
			<figcaption>A scroller with an child whose background intrudes into the gutter, thanks to ''scrollbar-gutter/match-parent''</figcaption>
			<img srcset="images/match-parent-ex1.png 4x">
		</figure>
		<figure>
			<figcaption>A ''scrollbar-gutter/match-parent'' box inside a scroll container with classic scrollbars, ''overflow: auto'', and ''scrollbar-gutter: stable''</figcaption>
			<img srcset="images/match-parent-classic.png 2x" alt="The background of the match-parent element is visible in the gutter when the scrollbar isn't there.">
		</figure>
		<figure>
			<figcaption>A scrollable box with ''scrollbar-gutter/match-parent'' inside another scroll container</figcaption>
			<img srcset="images/match-parent-nested.png 2x" alt="The element has a double gutter, one for its own scrollbar, one to match its parent's.">
		</figure>
		<figure>
			<figcaption>A scrollable box with ''scrollbar-gutter/match-parent'' inside another scroll container, with bidi</figcaption>
			<img srcset="images/match-parent-bidi.png 2x" alt="The element has a two gutters, one for its own scrollbar, one to match its parent's, on opposite sides.">
		</figure>
		<figure>
			<figcaption>A scrollable box with ''scrollbar-gutter:match-parent stable'' inside another scroll container, with bidi</figcaption>
			<img srcset="images/match-parent-stable.png 2x" alt="The element has a two gutters, one for its own scrollbar (not shown, as it's not overflowing), one to match its parent's, on opposite sides.">
		</figure>
	</div>
</dl>

<div class=note>
Note: The following table summarizes the interaction of 'overflow' and 'scrollbar-gutter'
for different types of scrollbars,
showing in which case space is reserved for the <a>scrollbar gutter</a>.

<table class="data complex">
	<caption>
		Should space be reserved for the [=scrollbar gutter=]?</caption>
	<thead>
	<tr>
		<th rowspan=2>'overflow'
		<th rowspan=2>'scrollbar-gutter'
		<th colspan=2>Classic scrollbars
		<th rowspan=2>Overlay scrollbars <small>(whether overflowing or not)</small>
	<tr>
		<th>Overflowing
		<th>Not overflowing
	</thead>
	<tr>
		<th rowspan=3>''overflow/scroll''
		<th>''scrollbar-gutter/auto''
		<td>yes
		<td>yes
		<td>
	<tr>
		<th>''scrollbar-gutter/stable''
		<td>yes
		<td>yes
		<td>
	<tr>
		<th>''scrollbar-gutter/always''
		<td>yes
		<td>yes
		<td>yes
	<tr>
		<th rowspan=3>''overflow/auto''
		<th>''scrollbar-gutter/auto''
		<td>yes
		<td>
		<td>
	<tr>
		<th>''scrollbar-gutter/stable''
		<td>yes
		<td>yes
		<td>
	<tr>
		<th>''scrollbar-gutter/always''
		<td>yes
		<td>yes
		<td>yes
	<tr>
		<th rowspan=3>''overflow/hidden''
		<th>''scrollbar-gutter/auto''
		<td>
		<td>
		<td>
	<tr>
		<th>''scrollbar-gutter/stable''
		<td>yes
		<td>yes
		<td>
	<tr>
		<th>''scrollbar-gutter/always''
		<td>yes
		<td>yes
		<td>yes
	<tr>
		<th rowspan=3>''overflow/visible'', ''overflow/clip''
		<th>''scrollbar-gutter/auto''
		<td>
		<td>
		<td>
	<tr>
		<th>''scrollbar-gutter/stable''
		<td>if ''force''
		<td>if ''force''
		<td>
	<tr>
		<th>''scrollbar-gutter/always''
		<td>if ''force''
		<td>if ''force''
		<td>if ''force''
</table>
</div>

</div>

<h2 id=privclass=nonum>
Appendix B: Privacy Considerations</h2>

This specification introduces no new privacy considerations.

<h2 id=sec class=nonum>
Appendix C: Security Considerations</h2>

This specification introduces no new security considerations.


<h2 id="changes" class="no-num">
Changes</h2>

<h3 id="recent-changes">
Recent Changes</h3>

	Significant changes since the <a href="https://www.w3.org/TR/2017/WD-css-overflow-4-20170613/">June 2017 Working Draft</a> include:
	<ul>
		<li>Moved in the definition of 'text-overflow' from [[CSS-UI-4]].
		<li>Moved the core definition of 'scrollbar-gutter' to [[CSS-OVERFLOW-3]]
			(it will be copied back here once this specification is undiffed)
			and shift exploratory 'scrollbar-gutter' extension ideas into an appendix.
		<li>Defined extension of 'overflow' and 'overflow-clip-margin' to apply to [=replaced elements=].
			How exactly this works is still <a href="https://github.com/w3c/csswg-drafts/issues/7144">still under discussion</a>.
			(<a href="https://github.com/w3c/csswg-drafts/issues/7144">Issue 7144</a>)
		<li>Defined [=longhands=] for 'overflow-clip-margin'.
			(<a href="https://github.com/w3c/csswg-drafts/issues/7245">Issue 7245</a>)
		<li>Change the 'line-clamp' shorthand syntax to allow omitting the 'max-lines' value
			(<a href="https://github.com/w3c/csswg-drafts/issues/9368">Issue 9368</a>)
		<li>Dropped the tentative <code>force</code> value for the 'scrollbar-gutter' property.
			(<a href="https://github.com/w3c/csswg-drafts/issues/9815">Issue 9815</a>)
		<li>Establish an Independent Formatting Context when ''continue: discard'' is used.
			(<a href="https://github.com/w3c/csswg-drafts/issues/10323">Issue 10323</a>)
		<li>Blockify elements with <code>(-webkit-)line-clamp</code>,
			<code>display: -webkit-(inline-)box</code>
			and <code>-webkit-box-orient: vertical</code>.
			(<a href="https://github.com/w3c/csswg-drafts/issues/10324">Issue 10324</a>)
	</ul>

<h3 id="changes-l3">
Changes Since Level 3</h3>

	ISSUE: TBD

<h2 class=no-num id="acknowledgments">
Acknowledgments</h2>

	<p>
		Thanks especially to the feedback from
		Rossen Atanassov,
		Bert Bos,
		Andreu Botella,
		Tantek Çelik,
		John Daggett,
		fantasai,
		Daniel Glazman,
		Vincent Hardy,
		H&aring;kon Wium Lie,
		Peter Linss,
		Robert O'Callahan,
		Florian Rivoal,
		Alan Stearns,
		Steve Zilles,
		and all the rest of the
		<a href="http://lists.w3.org/Archives/Public/www-style/">www-style</a> community.