Skip to content

Commit

Permalink
[css-sizing-3] Fix up percentage sizing per WG resolution--zero out m…
Browse files Browse the repository at this point in the history 
…argins/paddings/min-width/min-height. w3c#2384 w3c#2297
  • Loading branch information
@fantasai @fergald
fantasai authored and fergald committed May 7, 2018
1 parent 8785065 commit 98813bb
Showing 1 changed file with 61 additions and 44 deletions.
105 changes: 61 additions & 44 deletions css-sizing-3/Overview.bs
View file
Expand Up @@ -841,41 +841,13 @@ Intrinsic Contributions</h3>
that contains only that box,
if that hypothetical float's containing block is zero-sized/infinitely-sized.

If the box is [=non-replaced=],
then the value of any [=sizing property=] specified on it
as an expression containing a percentage
(such as ''10%'' or ''calc(10px + 0%)'')
is treated <em>for the purpose of calculating the box’s intrinsic size contribution only</em>
as that property’s initial value.
For example, given a box with ''width: calc(20px + 50%)'',
its max-content contribution is calculated as if its 'width' were ''width/auto''.
The percentage is honored as usual, however, during the actual sizing of the box itself.

However, in the case of a [=replaced element|replaced=] box with a percentage-based 'width'/'max-width'/'height'/'max-height',
the percentage is resolved to zero
when calculating the <a>min-content contribution</a> in the corresponding axis.
(See [[#min-content-zero]] for a list of which elements in HTML this applies to.)
The UA may additionally floor this size based on UI considerations,
such as ensuring certain UI elements remain visible
(for example, the dropdown arrow on a <{select}>).

<div class=example>
For example,
an <{input}> assigned ''width: calc(50% + 50px)''
has a <a>min-content contribution</a> of ''50px'',
plus any horizontal margin/border/padding.
</div>

Note: We are not 100% sure if zeroing out a percentage 'max-width' on form controls is web-compatible.
See <a href="https://github.com/w3c/csswg-drafts/issues/765">Issue 765</a>.

Note: This specification does not define how to determine these sizes.
Note: This specification does not define precisely how to determine these sizes.
Please refer to [[CSS2]],
the relevant CSS specification for that display type,
the <a href="#percentage-sizing">rules for handling percentages</a> (below),
and/or existing implementations
for further details.


<!--
████████ ██ ██ ████████ ████████ ████ ██ ██ ██████ ████ ██████
██ ██ ██ ██ ██ ██ ██ ███ ██ ██ ██ ██ ██ ██
Expand Down Expand Up @@ -912,11 +884,58 @@ Extrinsic Size Determination</h2>
the <code>&lt;aside></code> would be 30em tall.
</div>

Sometimes the size of a percentage-sized box's containing block
Sometimes the size of a percentage-sized box’s <a>containing block</a>
depends on the intrinsic size contribution of the box itself,
creating a cyclic dependency.
When calculating the containing block's size,
the percentage <a>behaves as auto</a>.
When calculating the <a>intrinsic size contribution</a> of such a box,
a <dfn>cyclic percentage</dfn>--
that is,
a percentage value that would resolve against a containing block size
which itself depends on that percentage--
is resolved specially:


* If the box is [=non-replaced=],
then the entire value of any
[=max size property=] or [=preferred size property=]
('width'/'max-width'/'height'/'max-height')
specified as an expression containing a percentage
(such as ''10%'' or ''calc(10px + 0%)'')
that is <a lt="cyclic percentage">cyclic</a>
is treated
<em>for the purpose of calculating the box’s intrinsic size contribution only</em>
as that property’s [=initial value=].
For example, given a box with ''width: calc(20px + 50%)'',
its max-content contribution is calculated as if its 'width' were ''width/auto''.
(The percentage is honored as usual, however,
during the actual sizing of the box itself; see below.)

* If the box is [=replaced element|replaced=],
a <a>cyclic percentage</a> in the value of any
[=max size property=] or [=preferred size property=]
('width'/'max-width'/'height'/'max-height'),
is resolved against zero
when calculating the <a>min-content contribution</a> in the corresponding axis.
(See [[#min-content-zero]] for a list of which elements in HTML this applies to.)
The UA may additionally floor this size based on UI considerations,
such as ensuring certain UI elements remain visible
(for example, the dropdown arrow on a <{select}>).

<div class=example>
For example,
an <{input}> assigned ''width: calc(50% + 50px)''
has a <a>min-content contribution</a> of ''50px'',
plus any horizontal margin/border/padding.
</div>

Note: We are not 100% sure if zeroing out a percentage 'max-width' on form controls is web-compatible.
See <a href="https://github.com/w3c/csswg-drafts/issues/765">Issue 765</a>.

* For the [=min size properties=],
as well as for margins and paddings,
a <a>cyclic percentage</a> is resolved against zero
for determining the intrinsic size contribution.

Then, unless otherwise specified,
when calculating the used sizes and positions of the containing block’s <em>contents</em>:

Expand All @@ -925,26 +944,23 @@ Extrinsic Size Determination</h2>
that causes it to depend on the size of its contents,
the box’s percentage is not resolved and instead <a>behaves as auto</a>.

Note: <a href="https://www.w3.org/TR/css-grid/">Grid containers</a> (<a href="https://github.com/w3c/csswg-drafts/issues/1679">and flex items?</a>) do allow percentages to resolve in this case.
Note: <a>Grid items</a> and <a>flex items</a>
do allow percentages to resolve in this case.

* Otherwise, the percentage is resolved against the containing block’s size.
(The containing block’s size is not re-resolved based on the resulting size of the box;
the contents might thus overflow or underflow the containing block).

Note: These rules specify the previously-undefined behavior of this cyclic case in <a href="https://www.w3.org/TR/CSS2/visudet.html#the-width-property">CSS2&sect;10.2</a>.
Note: These rules specify the previously-undefined behavior of this cyclic case
in <a href="https://www.w3.org/TR/CSS2/visudet.html#the-width-property">CSS2&sect;10.2</a>,
<a href="https://www.w3.org/TR/CSS2/box.html#margin-properties">CSS2&sect;8.3</a>,
and
<a href="https://www.w3.org/TR/CSS2/box.padding-properties">CSS2&sect;8.4</a>.
Note also, the behavior in <a href="https://www.w3.org/TR/CSS2/visudet.html#the-height-property">CSS2&sect;10.5</a>
is superseded in their respective specifications for layout modes
(such as <a href="http://www.w3.org/TR/css-flexbox/">flex layout</a>)
not described in CSS2.

Similarly, percentage margins and padding behave as zero in such cyclic cases
when calculating the containing block's size,
and then resolve when calculating the used sizes and positions of its content.
(This defines the previously-undefined behavior of this cyclic case in
<a href="https://www.w3.org/TR/CSS2/box.html#margin-properties">CSS2&sect;8.3</a>
and
<a href="https://www.w3.org/TR/CSS2/box.padding-properties">CSS2&sect;8.4</a>.

<div class="example">
For example, in the following markup:

Expand Down Expand Up @@ -984,7 +1000,8 @@ Extrinsic Size Determination</h2>
</div>

<div class=example>
Issue: Letting %s still resolve against a definite 'height'

Issue: Letting percentages still resolve against a definite 'height'
when the min-height is intrinsic is an open issue.
(CSS2 has a general statement about "height depending on contents",
which this technically is,
Expand Down

0 comments on commit 98813bb

Please sign in to comment.