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 CSS Overflow Module Level 3,
	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''

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

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;

WPT Display: closed
WPT Path Prefix: /css/css-overflow/line-clamp/

Introduction

Value Definitions

Module Interactions

Overflow Concepts and Terminology

Scrolling and Clipping Overflow

Managing Overflow: the 'overflow-x', 'overflow-y', and 'overflow' properties

Changing Clipping Bounds: the 'overflow-clip-margin-*' properties

	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: <> || <>
	Initial: ''0px''
	Inherited: no
	Logical property group: overflow-clip-margin
	Applies to: boxes to which 'overflow' applies
	Computed value: the computed <> and a <> keyword
	Animation type: per computed value if the <> values match; otherwise discrete
	

	Name: overflow-clip-margin, overflow-clip-margin-inline, overflow-clip-margin-block
	Value: <> || <>
	Initial: ''0px''
	Inherited: no
	Applies to: boxes to which 'overflow' applies
	

: <> :: 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. : <> :: The specified offset dictates how much the [=overflow clip edge=] is expanded from the specified box edge. Negative values shrink the box, instead. Defaults to zero if omitted.

Automatic Ellipses

Inline Overflow Ellipsis: the 'text-overflow' property

	Name: text-overflow
	Value: [ clip | ellipsis | <> | 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
	

clip

Clip inline content that overflows its block container element. Characters may be only partially rendered.

ellipsis

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.

<>

Render the given string to represent clipped inline content.

fade( [ <> ] )

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 <> 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?

fade

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.

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

ellipsing details

• 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''.
• The ellipsis is styled and baseline-aligned according to the block.
• Ellipsing occurs after relative positioning and other graphical transformations.
• 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).
• For bidi purposes, the ellipsis and string values must be treated as if they were wrapped in an anonymous inline with ''unicode-bidi: isolate'' which inherits ''direction'' from the block. text-overflow-string-006.html text-overflow-string-007.html

user interaction with ellipsis

• 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''.
• 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.

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

				<div>
				CSS IS AWESOME, YES
				</div>
				

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

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

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

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

ellipsis interaction with scrolling interfaces

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

		<div class="crawlbar">
		CSS is awesome, especially when you can scroll
		to see extra text instead of just
		having it overlap other text by default.
		</div>
		

Indicating Block-Axis Overflow: the 'block-ellipsis' property

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

no-ellipsis

The rendering is unaffected. block-ellipsis-023.html

auto

Render an ellipsis character (U+2026)-- or a more typographically-appropriate equivalent-- as the block overflow ellipsis at the end of the affected line box. UAs should use the conventions of the content language, writing system, and writing mode to determine the most appropriate ellipsis string. line-clamp-with-text-overflow-string-001.html line-clamp-with-text-overflow-string-002.html line-clamp-with-text-overflow-string-003.html

<>

Render the specified string as the block overflow ellipsis 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. block-ellipsis-024.html

Suppressing Excess Content

Limiting Visible Lines: the 'line-clamp' shorthand property

		Name: line-clamp
		Value: none | [<> || <<'block-ellipsis'>>] ''-webkit-legacy''?
		Initial: none
		Percentages: N/A
	

none

Sets 'max-lines' to ''max-lines/none'', 'continue' to ''continue/auto'', and 'block-ellipsis' to ''no-ellipsis''. line-clamp-020.html line-clamp-auto-038.html webkit-line-clamp-018.html

<>

<'block-ellipsis'>

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 <> 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. line-clamp-auto-001-crash.html line-clamp-auto-002-crash.html line-clamp-auto-001.html

-webkit-legacy

Sets 'continue' to ''continue/-webkit-legacy''.

			+---------------------------------------+
			| 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)  |
			+---------------------------------------+
		

Legacy compatibility

		Name: -webkit-line-clamp
		Value: none | <>
		Initial: none
		Percentages: N/A
	

		Name: continue
		New Values: -webkit-legacy
	

> * it unconditionally sets 'block-ellipsis' to ''block-ellipsis/auto'' webkit-line-clamp-003.html webkit-line-clamp-004.html * it sets 'continue' to ''continue/-webkit-legacy'' instead of ''collapse'' when an <> is specified (as if the ''line-clamp/-webkit-legacy'' keyword was set on 'line-clamp') webkit-line-clamp-001.html webkit-line-clamp-002.html webkit-line-clamp-003.html webkit-line-clamp-004.html The -webkit-legacy 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''. 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 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 this blog post. 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.

Forcing a Break After a Set Number of Lines: the 'max-lines' property

		Name: max-lines
		Value: ''none'' | <>
		Initial: ''none''
		Applies to: block containers 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
	

max-lines-valid.html max-lines-invalid.html webkit-line-clamp-030.html If the value of 'max-lines' is not none, then, given a [=computed value=] of N: - If the box is a [=line-clamp container=], its line-based clamp point is set to the first possible clamp point after its Nth descendant in-flow line box. If fewer than N line boxes exist, or if there are no possible clamp points after the Nth descendant in-flow line box, then that line-clamp container has no [=line-based clamp point=]. 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 - If the box is a [=fragmentation container=] that captures [=region breaks=], a region break is forced after its Nth descendant in-flow line box. If fewer than N line boxes exist, then 'max-lines' introduces no region break. Only line boxes in the same block formatting context are counted: the contents of descendants that establish independent formatting contexts are skipped over while counting line boxes. 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 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=]. discard/discard-multicol-004.html Only positive integers are accepted. Zero or negative integers are invalid and must cause the declaration to be ignored. Note: The 'widows', 'orphans', and 'break-inside' properties do not affect the position of the forced region break introduced by the 'max-lines' property.

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 fragmentation containers). 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.

Handling of Excess Content: the 'continue' property

		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
	

continue-valid.html continue-invalid.html line-clamp-014.html line-clamp-015.html line-clamp-029.html 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=].

auto

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

collapse

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=]. 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 continue-001.html If the box is a [=multicol container=], the behavior is the same as ''continue/auto''.

discard

The box must [=establish an independent formatting context=] and becomes a [=fragmentation container=] that captures region breaks, if it is not already. [[!CSS-BREAK-3]] Content after the first [=region break=] is not rendered. Note: This [=region break=] might be forced (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 region-fragment property from [[CSS-REGIONS-1]]. Once it is sufficiently stable in this specification, region-fragment 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.

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.

	''continue: collapse'' / ''continue: discard''	''continue: auto''
''overflow: visible''
''overflow: hidden''

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. 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 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=]. 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 * If the [=specified value=] of the 'display' property is ''-webkit-inline-box'', the [=computed value=] becomes ''inline-block'' and the box establishes a [=BFC=]. webkit-line-clamp-024.html webkit-box-computed.html 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. line-clamp-029.html

Line-clamp containers

A line-clamp container is an [=independent formatting context|independent=] [=block formatting context=] that additionally follows the rules in this section. Line-clamp containers can have a clamp point, which is one of the following block-axis positions inside it: - The start of the [=line-clamp container=]. line-clamp-auto-011.html line-clamp-auto-037.html - A point between two consecutive [=line boxes=] in an [=inline formatting context=] contained by the line-clamp container's [=block formatting context=]. 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 For this definition, [=out-of-flow=] boxes between two line boxes don't prevent them from being consecutive. This is the case even if the second line box is pushed down by [=floats=]. Such out-of-flow boxes are considered to be after the clamp point. - A point between two [=in-flow=] [=block-level=] sibling boxes in the line-clamp container's [=block formatting context=]. Any [=out-of-flow=] boxes in between are considered to be after the clamp point. line-clamp-auto-034.html line-clamp-auto-035.html line-clamp-auto-036.html 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 The auto clamp point 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=]. If the [=line-clamp container=]'s [=block formatting context root=] has a [=computed value=] of 'max-lines' set to ''max-lines/none'', then the actual [=clamp point=] is the [=auto clamp point=], if any. Otherwise, the actual clamp point is the [=line-based clamp point=], if any. 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 Issue(12041): Having the actual [=clamp point=] be the earlier of the [=line-based clamp point=] and the [=auto clamp point=], if both exist, is a wanted behavior, but the syntax for it is still being worked out. 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. 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 - Any [=line boxes=] that follow the [=clamp point=] inside an [=inline formatting context=]. line-clamp-010.html line-clamp-026.html line-clamp-027.html line-clamp-028.html webkit-line-clamp-040.html - Any [=absolutely positioned box=] which has an invisible box within its [=containing block chain=], and all of its descendants. 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 Any overflow such invisible boxes and line boxes might have is always counted as [=ink overflow=] rather than [=scrollable overflow=]. line-clamp-021.html line-clamp-with-abspos-019.html NOTE: This differs from the ''display: none''-like behavior of not rendered content with ''continue: discard''. Within a [=line-clamp container=], floats which have not been made into [=invisible boxes=] must be visually clipped to the [=content edge=] of the [=line-clamp container=]. They do not introduce any clearance that would make the [=line-clamp container=] increase its height, and do not contribute to the [=scrollable overflow area=]. 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, nor any clipped float. This also applies for the [=line-clamp container=] itself. line-clamp-004.html line-clamp-009.html line-clamp-auto-004.html line-clamp-auto-005.html

Discarding Content

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 Sydney F2F meeting. However, since intrinsic sizes are calculated across fragmentation containers, this content is taken into account for the purpose of finding the box’s min-content and max-content inline sizes (see [[css-break-3#varying-size-boxes]]). Min-content and max-content block sizes 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. Note: This differs from the ''visibility: hidden''-like behavior of content after the [=clamp point=] with ''continue: collapse''. Note: In the case of parallel fragmentation flows, content occurring after the fragmentation break in the box tree could still be rendered, if it is laid out above the position representing the end of this fragmentation container. 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. discard/discard-multicol-001.html discard/discard-multicol-002.html discard/discard-multicol-003.html discard/discard-multicol-004.html

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. <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>

			.multicol {
			  columns: 3;
			  border: solid 1px;
			}
			.multicol p {
			  break-after: column;
			  break-inside: avoid;
			}
			.spanner {
			  column-span: all;
			  text-align: center;
			}
		

		
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
		

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.

			.multicol {
			  continue: discard;
			  block-ellipsis: auto;
			}
		

		
Column 1        Column 2        Column 3…

Appendix A: Possible extensions for ''scrollbar-gutter''

This section is 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.

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

Name: scrollbar-gutter
New Values: auto | [ [ stable | always ] && both-edges? ] || match-parent
Applies to: all elements

For overlay scrollbars, the precise width of the scrollbar gutter, 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:

always

The scrollbar gutter 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.

''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.

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:

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 scrollbar-avoid: none | [self | content] && both-edges?. 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 scrollbar-avoid: self or scrollbar-avoid: content on the relevant children.

match-parent

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.

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 parent.gutter - child.border - child.margin, 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.

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 scrollbar gutter.

Should space be reserved for the [=scrollbar gutter=]?

'overflow'	'scrollbar-gutter'	Classic scrollbars		Overlay scrollbars (whether overflowing or not)
		Overflowing	Not overflowing
''overflow/scroll''	''scrollbar-gutter/auto''	yes	yes
	''scrollbar-gutter/stable''	yes	yes
	''scrollbar-gutter/always''	yes	yes	yes
''overflow/auto''	''scrollbar-gutter/auto''	yes
	''scrollbar-gutter/stable''	yes	yes
	''scrollbar-gutter/always''	yes	yes	yes
''overflow/hidden''	''scrollbar-gutter/auto''
	''scrollbar-gutter/stable''	yes	yes
	''scrollbar-gutter/always''	yes	yes	yes
''overflow/visible'', ''overflow/clip''	''scrollbar-gutter/auto''
	''scrollbar-gutter/stable''	if ''force''	if ''force''
	''scrollbar-gutter/always''	if ''force''	if ''force''	if ''force''

Appendix B: Privacy Considerations

This specification introduces no new privacy considerations.

Appendix C: Security Considerations

This specification introduces no new security considerations.

Changes

Recent Changes

Significant changes since the June 2017 Working Draft include:

• Moved in the definition of 'text-overflow' from [[CSS-UI-4]].
• 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.
• Defined extension of 'overflow' and 'overflow-clip-margin' to apply to [=replaced elements=]. How exactly this works is still still under discussion. (Issue 7144)
• Defined [=longhands=] for 'overflow-clip-margin'. (Issue 7245)
• Change the 'line-clamp' shorthand syntax to allow omitting the 'max-lines' value (Issue 9368)
• Dropped the tentative force value for the 'scrollbar-gutter' property. (Issue 9815)
• Establish an Independent Formatting Context when ''continue: discard'' is used. (Issue 10323)
• Blockify elements with (-webkit-)line-clamp, display: -webkit-(inline-)box and -webkit-box-orient: vertical. (Issue 10324)

Changes Since Level 3

ISSUE: TBD

Acknowledgments

Thanks especially to the feedback from Rossen Atanassov, Bert Bos, Andreu Botella, Tantek Çelik, John Daggett, fantasai, Daniel Glazman, Vincent Hardy, Håkon Wium Lie, Peter Linss, Robert O'Callahan, Florian Rivoal, Alan Stearns, Steve Zilles, and all the rest of the www-style community.