- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Tue, 19 Nov 2024 19:24:09 +0000
- To: public-css-archive@w3.org
So I think we need these edits: ```diff diff --git a/css-sizing-4/Overview.bs b/css-sizing-4/Overview.bs index be943838f..b994bbcbf 100644 --- a/css-sizing-4/Overview.bs +++ b/css-sizing-4/Overview.bs @@ -836,32 +836,52 @@ Stretch-fit Sizing: filling the containing block</h3> to make its outer size as close to filling the [=containing block=] as possible while still respecting the constraints imposed by min-height/min-width/max-height/max-width. - Formally, its behavior is the same as specifying an [=automatic size=] + In [=formatting contexts=] and axises + where the relevant [=self-alignment property=] applies, + it gives the element the same size + as specifying an [=automatic size=] together with a [=self-alignment property=] value of ''width/stretch'' - (in the relevant axis), - except that the resulting box, - which can end up not exactly fitting its [=alignment container=], - can be subsequently aligned by its actual [=self-alignment property=] value. + (in the relevant axis). + <span class=note>(The element can then be aligned as normal + by its actual [=self-alignment property=] value + if it ends up still not exactly fitting its [=alignment container=].)</span> - Additionally, - in [=formatting contexts=] and axes in which the relevant [=self-alignment property=] does not apply + In [=formatting contexts=] and axises + where the relevant [=self-alignment property=] <em>does not</em> apply (such as the block axis in Block Layout, or the main axis in Flex Layout), - in cases where a percentage size in that axis would resolve to a definite value, + but a percentage size in that axis would resolve to a definite value, a [=stretch-fit size=] causes the box to attempt to fill its containing block-- behaving as ''100%'' but applying the resulting size to its margin box instead of the box indicated by 'box-sizing'. For this purpose, ''margin/auto'' margins are treated as zero, - and furthermore, for [=block-level boxes=] in particular, - if its block-start/block-end [=margin=] - would be adjoining to its parent's block-start/block-end [=margin=] - if its parent’s [=sizing properties=] all had their [=initial values=], - then its block-start/block-end [=margin=] is treated as zero. + and if either of its margins in that axis are + [=adjoining its parent for stretch-fit purposes=], + then that margin is treated as zero. + <span class=note>(This causes it to size + as if its margin had collapsed with is parent's margin, + tho it does not actually change margin-collapsing behavior.)</span> - Note: Consequently, if neither ''align-self/stretch'' alignment applies - nor percentage sizing can resolve, - then the box will resolve to its [=automatic size=]. + <div algorithm> + A box's margin is + <dfn export>adjoining its parent for stretch-fit purposes</dfn> + if all of the following are true: + + * it is a [=block-level box=] + * the margin would be [=adjoining=] its parent's matching margin, + assuming the parent's [=sizing properties=] all had their [=initial values=] + * the box does not have any preceding/following (as appropriate) + [=in-flow=] sibling elements or [=text runs=], + except [=collapsed white space=] + * if the box is a [=block formatting context=], + the box does not have any preceding/following (as appropriate) [=floating=] sibling elements + </div> + + In all other cases + (when neither ''align-self/stretch'' alignment applies + nor percentage sizing can resolve), + the box resolves to its [=automatic size=]. <div class="example"> For example, given the following HTML representing two [=block boxes=]: ``` @fantasai, does this look reasonable? -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11044#issuecomment-2486567449 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 19 November 2024 19:24:10 UTC