<!-- FIXME: Regressions from bikeshed conversion: -->

<!-- - Value lines in propdef tables no longer link to #values. -->

<!-- - no longer says "Test suite: none yet" -->

<!-- - Abstract has the most introductory sentence last -->

<!-- FIXME: other bikeshed issues -->

spec:css-transforms-2; type:property; text:transform-style

type: dfn; spec:css-multicol-1; text:overflow column

type: dfn; spec:css-transforms-2; text:3d rendering context

spec:css-writing-modes-4; type:dfn; text:end

spec:css-pseudo-4; type:selector; text:::first-line

spec:css-pseudo-4; type:selector; text:::first-letter

spec:css-display-3; type:property; text:display

spec:css-sizing-3; type:property; text:max-height

spec:css-box-4; type:dfn; text:content area

spec:mediaqueries-3; type:value; text:print

spec:html; type:method; text:focus()

<!-- FIXME: the break-* link doesn't actually work! -->

url: https://www.w3.org/TR/2008/CR-css3-marquee-20081205/#the-overflow-style; type: property; text: overflow-style;

url: https://www.w3.org/TR/CSS22/visuren.html#positioned-element; type: dfn; spec:css2; text:positioned;

url: https://www.w3.org/TR/CSS22/visudet.html#strut-element; type: dfn; spec:css2; text:strut;

.awesome-table td { padding: 5px; }

.awesome-table {

color: #000;

background: #fff;

margin: auto;

}

In CSS Level 1 [[CSS1]], placing more content than would fit

inside an element with a specified size

was generally an authoring error.

Doing so caused the content to extend

outside the bounds of the element,

which would likely cause

that content to overlap with other elements.

CSS Level 2 [[CSS2]] introduced the 'overflow' property,

which allows authors to have overflow be handled by scrolling,

which means it is no longer an authoring error.

It also allows authors to specify

that overflow is handled by clipping,

which makes sense when the author's intent

is that the content not be shown.

This specification introduces the long-standing de-facto 'overflow-x' and 'overflow-y' properties,

adds a ''overflow/clip'' value,

and defines overflow handling more fully.

[Something something 'max-lines'.]

Note: This specification also reproduces the definition of the 'text-overflow' property

previously defined in [[CSS-UI-3]],

with no addition or modification,

in order to present 'text-overflow' and 'block-ellipsis' together.

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.

This module replaces (supersedes) and extends features defined in [[!CSS2]] section

<a href="https://www.w3.org/TR/CSS2/visufx.html#overflow-clipping">11.1 Overflow and clipping</a>

and [[!CSS-UI-3]] section

<a href="https://www.w3.org/TR/css-ui-3/#text-overflow">5.2. Overflow Ellipsis: the text-overflow property</a>.

<!--

████████ ██ ██ ████████ ████████ ██████

██ ██ ██ ██ ██ ██ ██ ██

██ ████ ██ ██ ██ ██

██ ██ ████████ ██████ ██████

██ ██ ██ ██ ██

██ ██ ██ ██ ██ ██

██ ██ ██ ████████ ██████

-->

CSS uses the term <dfn export>overflow</dfn> to describe

the contents of a box

that extend outside one of that box's edges

(i.e., its <i>content edge</i>, <i>padding edge</i>,

<i>border edge</i>, or <i>margin edge</i>).

The term might be interpreted as

elements or features that cause this overflow,

the non-rectangular region occupied by these features,

or, more commonly, as

the minimal rectangle that bounds that region.

A box's overflow is computed based on the layout and styling of the box itself

and of all descendants whose <a>containing block chain</a>

includes the box.

In most cases, <a>overflow</a>

can be computed for any box

from the bounds and properties of that box itself,

plus the <a>overflow</a>

of each of its children.

However, this is not always the case; for example,

when ''transform-style: preserve-3d'' [[CSS3-TRANSFORMS]] is used on

some of the children, any of their descendants with

''transform-style: preserve-3d'' must also be examined.

There are two different types of overflow,

which are used for different purposes by the UA:

<ul>

<li><a>ink overflow</a>

<li><a>scrollable overflow</a>

</ul>

The <dfn export>ink overflow</dfn> of a box

is the part of that box and its contents that

creates a visual effect outside of

the box's border box.

Ink overflow is the overflow of painting effects defined to not affect layout

or otherwise extend the <a>scrollable overflow area</a>,

such as <a href="https://www.w3.org/TR/css-backgrounds/#box-shadow">box shadows</a>,

<a href="">border images</a>,

<a href="https://www.w3.org/TR/css-text-decor-3/">text decoration</a>,

overhanging glyphs (with negative side bearings,

or with ascenders/descenders extending outside the em box),

<a href="https://www.w3.org/TR/css-ui-3/#outline-props">outlines</a>,

etc.

Since some effects in CSS (for example, the blurs in

'text-shadow' [[CSS-TEXT-3]] and 'box-shadow' [[CSS-BACKGROUNDS-3]],

which are theoretically infinite)

do not define what visual extent they cover, the extent

of the <a>ink overflow</a> is undefined.

The <dfn export lt="ink overflow region | ink overflow area">ink overflow area</dfn> is the non-rectangular area

occupied by the <a>ink overflow</a>

of a box and its contents,

and the <dfn export>ink overflow rectangle</dfn> is

the minimal rectangle whose axes are aligned to the box's axes

and that contains the <a>ink overflow area</a>.

Note that the <a>ink overflow rectangle</a> is a rectangle

in the box's coordinate system, but might be non-rectangular

in other coordinate systems due to transforms. [[CSS3-TRANSFORMS]]

Any overflow of [=replaced=] content is always [=ink overflow=]

(as opposed to [=scrollable overflow=]).

The <dfn export>scrollable overflow</dfn> of a box is the

set of things extending outside of that box's padding edge

for which a scrolling mechanism needs to be provided.

The <dfn export lt="scrollable overflow region | scrollable overflow area">scrollable overflow area</dfn> is the non-rectangular region

occupied by the <a>scrollable overflow</a>, and the

<dfn export>scrollable overflow rectangle</dfn> is

the minimal rectangle whose axes are aligned to the box's axes

and that contains the <a>scrollable overflow area</a>.

The <a>scrollable overflow area</a> is the union of:

<ul>

<li>

The [=scroll container=]’s own [=padding box=].

<li>

All [=line boxes=] directly contained by the [=scroll container=].

<li>

The border boxes

of all boxes for which it is the containing block

and whose border boxes are positioned not wholly

in the [=negative scrollable overflow region=],

accounting for transforms by projecting each box onto

the plane of the element that establishes its <a>3D rendering context</a>.

[[!CSS3-TRANSFORMS]]

Issue: Is this description of handling transforms

sufficiently accurate?

Border boxes with zero area

do not affect the [=scrollable overflow area=].

<li>

The margin areas of <a>grid item</a> and <a>flex item</a> boxes

for which the box establishes a containing block.

The UA may <em>additionally</em> include

the margin areas of other boxes

for which the box establishes a containing block;

however,

the conditions under which such margin areas are included

is undefined in this level.

<span class="issue">This needs further testing and investigation;

is therefore deferred in this draft.</span>

<li>

The <a>scrollable overflow areas</a> of all of the above boxes

(including zero-area boxes

and accounting for transforms as described above),

provided they themselves have ''overflow: visible''

(i.e. do not themselves trap the overflow)

and that <a>scrollable overflow</a> is not already clipped

(e.g. by the 'clip' property or the 'contain' property).

Note: The 'mask-*' properties [[!CSS-MASKING-1]]

do not affect the <a>scrollable overflow area</a>.

ISSUE(8607): Need to evaluate what should/should not clip [=scrollable overflow=].

<li>

Additional padding added

to the [=end=]-side of the [=scrollable overflow rectangle=]

as necessary to enable a scroll position

that satisfies the requirements of ''place-content: end'' alignment.

Note: This padding represents,

within the [=scrollable overflow rectangle=],

the box’s own padding

so that when its content is scrolled to the end,

there is padding between the end-edge of its in-flow (or floated) content

and the border edge of the box.

It typically ends up being exactly the same size as the box's own padding,

except in a few cases--

such as when an out-of-flow positioned element,

or the visible overflow of a descendent,

has already increased the size of the [=scrollable overflow rectangle=]

outside the conceptual “content edge” of the [=scroll container=]’s content.

<figure>

<img src="images/scroll-align-padding.jpg">

<figcaption>

Issue: Replace this image with a proper SVG.

</figcaption>

</figure>

</ul>

Additionally, due to Web-compatibility constraints

(caused by authors exploiting legacy bugs to surreptitiously hide content from visual readers but not search engines and/or speech output),

UAs must clip any content in the [=negative scrollable overflow region=]

(thereby behaving as if they had no <a>scrollable overflow</a>

on the wrong side of the [=scroll origin=]).

<!--

Considerations:

* floats

* relpos

* margins that collapsed through to the edge of the scrollable area

* inline-side margins on both blocks and inlines

Notes:

The reasoning for only including border boxes is to minimize the cases

in which overflow scrolling is triggered; however once overflow is triggered,

excluding margins creates tight, uncomfortable edges

because the margin has been effectively truncated.

Testcase:

http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%20%20div%20%7B%20height%3A%2050px%3B%20overflow%3A%20scroll%3B%20border%3A%20solid%3B%20position%3A%20relative%3B%7D%0A%20%20p%20%7B%20margin%3A%2025px%3B%20background%3A%20red%3B%20%7D%0A%20%20q%20%7B%20position%3A%20absolute%3B%20background%3A%20blue%3B%20top%3A%2025px%3B%20margin%3A%2025px%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cdiv%3E%0A%20%20%3Cp%3ETest%20%3Cq%3ETest2%0A%3C%2Fdiv%3E

-->

Note: The <a>scrollable overflow rectangle</a> is always a rectangle

in the box's own coordinate system, but might be non-rectangular

in other coordinate systems due to transforms [[CSS3-TRANSFORMS]].

This means scrollbars can sometimes appear when not actually necessary.

A box’s [=overflow=] can be visible or clipped.

CSS also allows a box to be a <dfn export>scroll container</dfn>

that allows clipped parts of its [=scrollable overflow area=]

to be scrolled into view.

The visual “viewport” of a <a>scroll container</a>

(through which the <a>scrollable overflow area</a> can be viewed)

coincides with its padding box,

and is called the <dfn export>scrollport</dfn>.

A box’s <dfn export>nearest scrollport</dfn>

is the [=scrollport=] of its nearest [=scroll container=] ancestor.

Scrolling operations can be initiated by the user

(for example, by manipulating a scrollbar, swiping a touchscreen, or using keyboard controls)

or by script

(<span class=non-normative>for example, by the {{scrollIntoView()}} or {{focus()}} APIs</span>).

The initial position of the [=scrollable overflow rectangle=] within the [=scrollport=]

before any scrolling operations take effect is the <dfn export>initial scroll position</dfn>.

The [=initial scroll position=]

is typically dependent on the [=scroll container=]’s [=writing mode=],

and, unless otherwise specified,

coincides with its [=scroll origin position=].

However, the 'align-content' and 'justify-content' properties [[!CSS-ALIGN-3]] as well as the

'scroll-start-target' property [[!CSS-SCROLL-SNAP-2]] can be used to change the [=initial scroll position=],

see [[css-align-3#overflow-scroll-position]].

A <dfn export>scroll position</dfn> is a particular alignment

of the [=scrollable overflow rectangle=]

within its [=scrollport=].

It is associated with a <dfn export>scroll offset</dfn>

which is its distance from the [=scroll origin=].

The <dfn export>scroll origin</dfn> is the anchor coordinate of the [=scrollable overflow rectangle=],

from which the [=scrollable overflow rectangle=] expands.

Unless otherwise specified,

it is the [=block-start=] [=inline-start=] corner of the [=scrollable overflow rectangle=].

(For example, in a [=flex container=] it is the [=main-start=] [=cross-start=] corner.)

The area beyond the [=scroll origin=] in either axis

is considered the <dfn export>negative scrollable overflow region</dfn>:

content rendered here is not accessible to the reader,

see [[#scrollable]].

A [=scroll container=] is said to be scrolled to its [=scroll origin=]

when its [=scroll origin=] coincides with the corresponding corner of its [=scrollport=].

This [=scroll position=], the <dfn export>scroll origin position</dfn>,

usually, but not always,

coincides with the [=initial scroll position=].

<div class="example">

For example,

the 'align-content' and 'justify-content' properties [[CSS-ALIGN-3]]

and [=scroll snapping=] [[CSS-SCROLL-SNAP-1]]

can change the [=initial scroll position=]

away from the [=scroll origin position=].

</div>

ISSUE: Check whether things like [=baseline alignment=]

depend on the [=initial scroll position=] or the [=scroll origin position=].

ISSUE: This doesn't define a coordinate system for [=scroll offsets=].

Whether they increase downward/rightward,

block/inline-axis endward,

or away from the [=scroll origin=] is not defined.

Should each API define its coordinate model?

The root viewport, which scrolls the page [=canvas=],

uses the <a>principal writing mode</a> for determining

its [=scroll origin=] and [=initial scroll position=].

Note: In the case where a [=scroll container=] (or one of its ancestors)

is the target of a graphical transform,

the UA might need to take this transform into account

when mapping user inputs to scrolling operations.

For instance, on a touch screen where the user scrolls

by directly dragging the content,

the transform would be expected to be taken into account

to match the direction of scrolling to the gesture.

On the other hand, other user inputs

(such as the Page Down key, or a 1D scroll wheel)

might be more naturally interpreted ignoring the transform.

Choosing the appropriate behavior for each scrolling mechanism

is the responsibility of the UA.

<!--

███████ ██ ██ ████████ ████████ ████████ ██ ███████ ██ ██

██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██

██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██

██ ██ ██ ██ ██████ ████████ ██████ ██ ██ ██ ██ ██ ██ ███████ █████████

██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██

██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██

███████ ███ ████████ ██ ██ ██ ████████ ███████ ███ ███

-->

These properties specify whether a box’s [=overflow=] is clipped,

and if so,

whether it is a [=scroll container=].

<pre class=propdef>

The 'overflow-x' property specifies

the handling of <a>overflow</a> in the horizontal axis

(i.e., overflow from the left and right sides of the box),

and the 'overflow-y' property specifies the handling

of <a>overflow</a> in the vertical axis

(i.e., overflow from the top and bottom sides of the box).

The 'overflow-block' and 'overflow-inline' properties likewise

specify the handling of [=overflow=]

in the [=block axis|block=] and [=inline axis|inline=] axis, respectively

These four properties form a [=logical property group=]

together with the 'overflow' [=shorthand=],

and interact as defined in [[css-logical-1#box]].

<pre class="propdef shorthand">

The 'overflow' property is a [=shorthand property=]

that sets the specified values of 'overflow-x' and 'overflow-y' in that order.

If the second value is omitted, it is copied from the first.

Values have the following meanings:

<dl dfn-for="overflow, overflow-x, overflow-y" dfn-type="value">

<dt><dfn>visible</dfn>

<dd>

There is no special handling of overflow, that is,

the box’s content is rendered outside the box if positioned there.

The box is not a <a>scroll container</a>.

<dt><dfn>hidden</dfn>

<dd>

This value indicates that

the box’s content is clipped to its [=padding box=]

and that the UA must not provide any scrolling user interface

to view the content outside the clipping region,

nor allow scrolling by direct intervention of the user,

such as dragging on a touch screen

or using the scrolling wheel on a mouse.

However, the content must still be scrollable programmatically,

for example using the mechanisms defined in [[CSSOM-VIEW]],

and the box is therefore still a <a>scroll container</a>.

<dt><dfn>clip</dfn>

<dd>

This value indicates that

the box’s content is clipped to its [=overflow clip edge=]

and that no scrolling user interface should be provided by the UA

to view the content outside the clipping region.

In addition, unlike ''overflow: hidden''

which still allows programmatic scrolling,

''overflow: clip'' forbids scrolling entirely,

through any mechanism,

and therefore the box is not a <a>scroll container</a>.

Unlike ''hidden'', this value <strong>does not</strong> cause

the element to establish a new formatting context.

Note: Authors who also want the box to establish a formatting context

may use ''display: flow-root'' together with ''overflow: clip''.

<dt><dfn>scroll</dfn>

<dd>

This value indicates that

the content is clipped to the [=padding box=],

but can be scrolled into view

(and therefore the box is a <a>scroll container</a>).

Furthermore, if the user agent uses a scrolling mechanism

that is visible on the screen (such as a scroll bar or a panner),

that mechanism should be displayed

whether or not any of its content is clipped.

This avoids any problem with scrollbars appearing

and disappearing in a dynamic environment.

When the target medium is ''@media/print'',

overflowing content may be printed;

it is not defined where it may be printed.

<dt><dfn>auto</dfn>

<dd>

Like ''overflow/scroll'' when the box has <a>scrollable overflow</a>;

like ''overflow/hidden'' otherwise.

Thus, if the user agent uses a scrolling mechanism

that is visible on the screen (such as a scroll bar or a panner),

that mechanism will only be displayed

if there is overflow.

</dl>

The ''visible''/''overflow/clip'' values of 'overflow'

compute to ''overflow/auto''/''hidden'' (respectively)

if one of 'overflow-x' or 'overflow-y' is neither ''visible'' nor ''overflow/clip''.

If the computed value of 'overflow' on a <a>block box</a>

is neither ''overflow/visible'' nor ''overflow/clip'' nor a combination thereof,

it [=establishes an independent formatting context=] for its contents.

User agents must also support

the <dfn value for="overflow, overflow-x, overflow-y, overflow-block, overflow-inline">overlay</dfn> keyword

as a [=legacy value alias=] of ''overflow/auto''.

If the computed value of the 'visibility' property is ''visibility/hidden''

(or ''visibility/collapse'' when it has the same effect as ''visibility/hidden''),

and 'overflow' is either ''overflow/scroll'' or ''overflow/auto'',

then:

* The user agent must not make any scrolling mechanism visible.

To the extent that the scrolling mechanism that would normally be visible

in the absence of ''visibility: hidden'' affects layout,

it continues to do so, but is not painted.

* As would be the case with ''overflow: hidden'',

scrolling directly triggered by user interactions is disabled,

but programmatic scrolling continues to take effect.

* The lack of interactive direct scrolling is enforced

even if the user interacts (e.g. with a mouse scrolling wheel)

with a descendent of the ''visibility: hidden'' [=scroll container=]

that is itself set to ''visibility: visible''.

As mentioned in [[css-backgrounds-3#corner-clipping]],

the clipping region established by 'overflow' can be rounded:

* When 'overflow-x' and 'overflow-y' compute to

''overflow/hidden'', ''overflow/scroll'', or ''overflow/auto'',

the clipping region is rounded

based on the border radius,

adjusted to the [=padding edge=],

as described in [[css-backgrounds-3#corner-shaping]].

* When both 'overflow-x' and 'overflow-y' compute to ''overflow/clip'',

the clipping region is rounded as described in [[#overflow-clip-margin]].

* However, when one of 'overflow-x' or 'overflow-y' computes to ''overflow/clip''

and the other computes to ''overflow/visible'',

the clipping region is not rounded.

<p class="advisement">

Since scrolling is not possible in static media

(such as print)

authors should be careful to make content accessible in such media,

for example by using ''@media print, (update: none) { &hellip; }''

to adjust layout such that all relevant content

is simultaneously visible.

On <a>scroll containers</a> in non-interactive media

with an 'overflow' value of ''overflow/auto'' or ''overflow/scroll''

(but not ''overflow/hidden'')

UAs may display an indication of any scrollable overflow,

such as by displaying scrollbars

or an ellipsis.

Note: Not all [=paged media=] is non-interactive:

for example, e-book readers paginate content,

but are interactive.

<pre class=propdef>

This property defines 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=].

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

: <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=].

UAs must apply the 'overflow-*' values

set on the root element to the <a>viewport</a>

when the root element’s 'display' value is not ''display/none''.

However,

when the root element is an [[!HTML]] <{html}> element

(including <a href="https://html.spec.whatwg.org/multipage/introduction.html#html-vs-xhtml">XML syntax for HTML</a>)

whose 'overflow' value is ''overflow/visible'' (in both axes),

and that element has as a child

a <{body}> element whose 'display' value is also not ''display/none'',

user agents must instead apply the 'overflow-*' values

of the first such child element to the viewport.

The element from which the value is propagated must then have

a used 'overflow' value of ''overflow/visible''.

Note: Using [=containment=] on the HTML <{html}> or <{body}> elements disables

this special handling of the HTML <{body}> element.

See the [[CSS-CONTAIN-1#contain-property]] for details.

Note: ''overflow: hidden'' on the root element

might not clip everything outside the [=Initial Containing Block=]

if the ICB is smaller than the viewport,

which can happen on mobile.

If ''overflow/visible'' is applied to the viewport,

it must be interpreted as ''overflow/auto''.

If ''overflow/clip'' is applied to the viewport,

it must be interpreted as ''overflow/hidden''.

<pre class=propdef>

The 'scroll-behavior' property specifies the scrolling behavior for a [=scroll container=],

when scrolling happens due to navigation,

scrolling APIs [[!CSSOM-VIEW]],

or scroll snapping operations not initiated by the user [[!CSS-SCROLL-SNAP-1]].

Any other scrolls, e.g. those that are performed by the user, are not affected by this property.

When this property is specified on the root element, it applies to the <a>viewport</a> instead.

Note: The 'scroll-behavior' property of the HTML <{body}> element is <em>not</em> propagated to the viewport.

<dl dfn-type=value dfn-for=scroll-behavior>

<dt><dfn>auto</dfn>

<dd>

The [=scroll container=] is scrolled in an <a spec=cssom-view lt="instant scroll">instant</a> fashion.

<dt><dfn>smooth</dfn>

<dd>

The [=scroll container=] is scrolled in a <a spec=cssom-view lt="smooth scroll">smooth</a> fashion

using a user-agent-defined timing function over a user-agent-defined period of time.

User agents should follow platform conventions, if any. <!--fingerprint-->

</dl>

User agents may ignore this property. <!--fingerprint-->

When reserving space for a scrollbar placed at the edge of an element's box,

the reserved space is inserted between the inner border edge

and the outer padding edge.

For the purpose of the <a spec=css-backgrounds>background positioning area</a> and <a spec=css-backgrounds>background painting area</a> however,

this reserved space is considered to be part of the [=padding box=].

<div class="example">

In the following document fragment,

both an absolutely-positioned element

and a background image

are positioned to the top right of the box.

<xmp highlight=html>

<style>

article {

background: top right no-repeat url(circle.png);

position: relative;

overflow: auto; }

aside { position: absolute; top: 0; right: 0; }

</style>

<article>

<aside>×</aside>

</article>

</xmp>

If no scrollbars are present on <code>&lt;article></code>,

they will both coincide in the top right padding edge corner.

However, if scrollbars are present

then <code>&lt;aside></code> will be completely visible,

on the right padding-box edge adjacent to the scrollbars;

whereas the background image will be tucked underneath the scrollbars,

in the top right corner of the scrollbar-extended <a spec=css-backgrounds>background positioning area</a>.

</div>

When the box is intrinsically sized,

this reserved space is added to the size of its contents.

It is otherwise subtracted from space allotted to the [=content area=].

To the extent that the presence of scrollbars can affect sizing,

UAs must start with the assumption that no scrollbars are needed,

and recalculate sizes if it turns out they are.

<div class="example">

In the following document fragment,

the outer <code>&lt;article></code> has ''height: auto'', but ''max-height: 5em''.

The inner <code>&lt;section></code> has large margins and would normally just fit:

<xmp highlight=html>

...

article { overflow: auto; max-height: 5em; width: max-content; }

section { margin: 2em; line-height: 1 }

...

<article>

<section>

This section has big margins.

</section>

</article>

</xmp>

If we assumed that <code>&lt;article></code> needed scrollbars,

then the height of <code>&lt;section></code>,

including the single line of text and twice 2em of margins,

adds up to 5em plus a scrollbar.

Since that is greater than 5em, the maximum allowed height,

it seems we made the right assumption and d1 indeed needs scrollbars.

However, we should have started by assuming that no scrollbars are needed.

In that case the content height of <code>&lt;article></code>

is exactly the maximum height of 5em,

proving that the assumption was correct

and <code>&lt;article></code> indeed should not have scrollbars.

</div>

The space between the inner border edge and the outer padding edge

which user agents may reserve to display the scrollbar

is called the <dfn export>scrollbar gutter</dfn>.

The 'scrollbar-gutter' property gives control to the author

over the presence of <a>scrollbar gutters</a>

separately from the ability to control the presence of scrollbars

provided by the 'overflow' property.

<pre class="propdef">

This property affects the presence of <a>scrollbar gutters</a>

placed at the <a>inline start</a> edge or <a>inline end</a> edge of the box.

The presence of a <a>scrollbar gutter</a>

at the <a>block start</a> edge and <a>block end</a> edge of the box

cannot be controlled in this level,

and is determined the same way as the presence of <a>scrollbar gutters</a>

placed at the <a>inline start</a> edge or <a>inline end</a> edge of the box

when 'scrollbar-gutter' is ''scrollbar-gutter/auto''.

Scrollbars which by default are placed over the content box

and do not cause <a>scrollbar gutters</a> to be created

are called <dfn export>overlay scrollbars</dfn>.

Such scrollbars are usually partially transparent, revealing the content behind them if any.

Their appearance and size may vary

based on whether and how the user is interacting with them.

Scrollbars which are always placed in a <a>scrollbar gutter</a>,

consuming space when present,

are called <dfn export>classic scrollbars</dfn>.

Such scrollbars are usually opaque.

Whether <a>classic scrollbars</a> or <a>overlay scrollbars</a> are used,

the appearance and size of the scrollbar,

and whether scrollbars appear on the start or end edge of the box,

is UA defined.

Note: Which side a scrollbar appears on may depend on

operating system conventions,

[=bidirectionality=],

or other ergonomic considerations.

In the case of <a>classic scrollbars</a>,

the width of the <a>scrollbar gutter</a>,

if present (see below),

is the same as the width of the scrollbar.

In the case of <a>overlay scrollbars</a>,

no <a>scrollbar gutter</a> is present.

Note: There are known use cases that could be addressed

by enabling <a>scrollbar gutters</a>

for <a>overlay scrollbars</a>,

but no satisfactory design has been agreed to so far.

This could be addressed by future extensions of this property.

See [[css-overflow-4#sbg-ext]].

The values of this property have the following meaning:

<dl dfn-for="scrollbar-gutter" dfn-type=value>

<dt><dfn>auto</dfn>

<dd><a>Classic scrollbars</a> consume space by creating a <a>scrollbar gutter</a>

when 'overflow' is ''overflow/scroll'',

or when 'overflow' is ''overflow/auto'' and the box is overflowing.

<a>Overlay scrollbars</a> do not consume space.

<dt><dfn>stable</dfn>

<dd>The <a>scrollbar gutter</a> is present

for <a>classic scrollbars</a>

when 'overflow' is ''overflow/hidden'', ''overflow/scroll'', or ''overflow/auto'',

regardless of whether the box is actually overflowing.

<a>Overlay scrollbars</a> do not consume space.

Note: This does not change whether the scrollbar itself is visible,

only the presence of a gutter is affected.

<dt><dfn>both-edges</dfn>

<dd>If a <a>scrollbar gutter</a> would be present

on one of the inline start edge or the inline end edge of the box,

another <a>scrollbar gutter</a> must be present on the opposite edge as well.

</dl>

When the <a>scrollbar gutter</a> is present but the scrollbar is not,

or the scrollbar is transparent or otherwise does not fully obscure the <a>scrollbar gutter</a>,

the background of the <a>scrollbar gutter</a> must be painted as an extension of the padding.

As for the 'overflow' property,

when 'scrollbar-gutter' is set on the root element,

the user agent must apply it to the viewport instead,

and the used value on the root element itself is ''scrollbar-gutter: auto''.

However, unlike the 'overflow' property,

the user agent must not propagate 'scrollbar-gutter' from the HTML <{body}> element.

<div class=note>

Note: The following table summarizes the interaction of 'overflow' and 'scrollbar-gutter'

showing in which case space is reserved for a <a>classic scrollbar</a>'s <a>scrollbar gutter</a>.

<style>

.data.complex tbody th:last-of-type {

border-right: solid black 2px;

}

.data.complex tbody tr:nth-of-type(2n) td,

.data.complex tbody tr:nth-of-type(2n) th:not([rowspan]) {

background: rgba(127, 127, 127, 0.25);

}

</style>

<table class="data complex">

<caption>

Should a <a>classic scrollbar</a>'s <a>scrollbar gutter</a> be present?</caption>

<thead>

<tr>

<th>'overflow'

<th>'scrollbar-gutter'

<th>Overflowing

<th>Not overflowing

</thead>

<tr>

<th rowspan=2>''overflow/scroll''

<th>''scrollbar-gutter/auto''

<td>yes

<td>yes

<tr>

<th>''scrollbar-gutter/stable''

<td>yes

<td>yes

<tr>

<th rowspan=2>''overflow/auto''

<th>''scrollbar-gutter/auto''

<td>yes

<td>

<tr>

<th>''scrollbar-gutter/stable''

<td>yes

<td>yes

<tr>

<th rowspan=2>''overflow/hidden''

<th>''scrollbar-gutter/auto''

<td>

<td>

<tr>

<th>''scrollbar-gutter/stable''

<td>yes

<td>yes

<tr>

<th rowspan=2>''overflow/visible'', ''overflow/clip''

<th>''scrollbar-gutter/auto''

<td>

<td>

<tr>

<th>''scrollbar-gutter/stable''

<td>

<td>

</table>

</div>

<pre class="propdef">

This property specifies rendering when inline content overflows

its <a>end</a> line box edge

in the inline progression direction of its block container element ("the block")

that has 'overflow'

other than ''visible''.

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 data-dfn-for="text-overflow" class="valuedef">

<dt><dfn id=overflow-clip dfn-type=value>clip</dfn>

<dd>