[css-sizing] definite sizes and shrink-wrapping

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[css-sizing] definite sizes and shrink-wrapping

Christian Biesinger-3
Hi there,

this is sort of an extension of Rego's recent email
(https://lists.w3.org/Archives/Public/www-style/2016May/0026.html) and
based on IRC conversation with dbaron.

This is the relevant part of css-sizing:
https://drafts.csswg.org/css-sizing/#definite

It says "A size that can be determined without measuring content"

Clearly shrinkwrapped elements' size does require measuring content,
by definition.

But per David, and per interoperable implementations, widths are
always definite, even when shrinkwrapping. Now, the spec as written
allows for shrinkwrapping of abspos (though I believe earlier advice
on this list was that this should be limited to abspos that specifies
size in some way). But it does not address floats, which also
shrinkwrap, or flex items, or I'm sure other cases.

Can we clarify this part of the spec?

(CSS2.1 explicitly leaves this case undefined)

Thanks!
-Christian

Reply | Threaded
Open this post in threaded view
|

Re: [css-sizing] definite sizes and shrink-wrapping

fantasai
On 05/05/2016 12:02 PM, Christian Biesinger wrote:

> Hi there,
>
> this is sort of an extension of Rego's recent email
> (https://lists.w3.org/Archives/Public/www-style/2016May/0026.html) and
> based on IRC conversation with dbaron.
>
> This is the relevant part of css-sizing:
> https://drafts.csswg.org/css-sizing/#definite
>
> It says "A size that can be determined without measuring content"
>
> Clearly shrinkwrapped elements' size does require measuring content,
> by definition.
>
> But per David, and per interoperable implementations, widths are
> always definite, even when shrinkwrapping. Now, the spec as written
> allows for shrinkwrapping of abspos (though I believe earlier advice
> on this list was that this should be limited to abspos that specifies
> size in some way). But it does not address floats, which also
> shrinkwrap, or flex items, or I'm sure other cases.
>
> Can we clarify this part of the spec?
>
> (CSS2.1 explicitly leaves this case undefined)

The CSSWG discussed this last week and decided to update the definition
of definite/indefinite so that intrinsic sizes are considered definite:
   https://www.w3.org/2016/05/09-css-irc#T21-51-29

I'm not 100% sure what exactly this means, but we tried to make edits
to CSS Sizing to match the resolution:
   https://hg.csswg.org/drafts/rev/b7b26d2bc943
and added a clarification to Sizing L4
   https://hg.csswg.org/drafts/rev/1c734ff12cc4

We'd appreciate it if people reviewed the change and let us know if
   a) It's correct
   b) There are further edits that need to be made, either to Sizing
      or Flexbox or Grid or anything else
   c) If we should copy the second changeset to Sizing 3, given it
      defines intrinsic sizes like this:
        https://www.w3.org/TR/css-sizing-3/#intrinsic-contribution
   d) If there's anything else that needs fixing

~fantasai and TJ

Reply | Threaded
Open this post in threaded view
|

Re: [css-sizing] definite sizes and shrink-wrapping

Christian Biesinger-3
On Tue, May 17, 2016 at 2:57 PM, fantasai <[hidden email]> wrote:

> On 05/05/2016 12:02 PM, Christian Biesinger wrote:
>>
>> Hi there,
>>
>> this is sort of an extension of Rego's recent email
>> (https://lists.w3.org/Archives/Public/www-style/2016May/0026.html) and
>> based on IRC conversation with dbaron.
>>
>> This is the relevant part of css-sizing:
>> https://drafts.csswg.org/css-sizing/#definite
>>
>> It says "A size that can be determined without measuring content"
>>
>> Clearly shrinkwrapped elements' size does require measuring content,
>> by definition.
>>
>> But per David, and per interoperable implementations, widths are
>> always definite, even when shrinkwrapping. Now, the spec as written
>> allows for shrinkwrapping of abspos (though I believe earlier advice
>> on this list was that this should be limited to abspos that specifies
>> size in some way). But it does not address floats, which also
>> shrinkwrap, or flex items, or I'm sure other cases.
>>
>> Can we clarify this part of the spec?
>>
>> (CSS2.1 explicitly leaves this case undefined)
>
>
> The CSSWG discussed this last week and decided to update the definition
> of definite/indefinite so that intrinsic sizes are considered definite:
>   https://www.w3.org/2016/05/09-css-irc#T21-51-29
>
> I'm not 100% sure what exactly this means, but we tried to make edits
> to CSS Sizing to match the resolution:
>   https://hg.csswg.org/drafts/rev/b7b26d2bc943
> and added a clarification to Sizing L4
>   https://hg.csswg.org/drafts/rev/1c734ff12cc4
>
> We'd appreciate it if people reviewed the change and let us know if
>   a) It's correct

Thanks for making the change! I'm not sure that "without consideration
of line wrapping" is correct since computing the preferred with *does*
take line wrapping into account for max-content, no?

Also, I'm not sure on this, but what about replaced elements with an
intrinsic size? Their contribution to their parents preferred size is
not really "measuring text" but the size should still be considered
definite, right?

I wonder if explicitly saying "max-content, min-content and
fit-content are definite" would be clearer?

-Christian

Reply | Threaded
Open this post in threaded view
|

Re: [css-sizing] definite sizes and shrink-wrapping

Manuel Rego Casasnovas
In reply to this post by fantasai
Hi,

On 17/05/16 20:57, fantasai wrote:
> The CSSWG discussed this last week and decided to update the definition
> of definite/indefinite so that intrinsic sizes are considered definite:
>   https://www.w3.org/2016/05/09-css-irc#T21-51-29
>
> I'm not 100% sure what exactly this means, but we tried to make edits
> to CSS Sizing to match the resolution:
>   https://hg.csswg.org/drafts/rev/b7b26d2bc943
> and added a clarification to Sizing L4
>   https://hg.csswg.org/drafts/rev/1c734ff12cc4

I've been trying to understand the CSS WG resolution and how it affects
CSS Grid Layout.
It seems a good way to try to follow what browsers do to resolve
percentages on regular blocks.
I'll try to use different examples to explain my thoughts on this topic.

First, the very simple case that originated the discussion:
  <div style="display: grid; font: 25px/1 Ahem; float: left;
grid-template-columns: 50%;">
    <div>XX X</div>
  </div>

If I'm understanding the new resolution properly, the sizes should be:
* Grid container's width: 100px
* Column: 50px

This is because first we compute the intrinsic sizes of the grid
container, during that process we use "auto" for the percentage columns,
so we've 100px as max-content size and 50px as min-content size. In this
case we use the max-content size to determine the width of the grid
container, so it's 100px.
Then during the actual layout, we use that size to resolve the 50%
percentage, so we've a 50px column.

This shows that the inline size is never indefinite during layout phase,
it's only indefinite while we're computing the intrinsic sizes, but once
we've calculated it, all the inline sizes would be definite.

Testing different examples using min|max-content will show that this is
true:
  <div style="display: grid; font: 25px/1 Ahem; width: max-content;
grid-template-columns: 50%;">
    <div>XX X</div>
  </div>

Sizes:
* Grid container's width: 100px
* Column: 50px

The intrinsic sizes of the grid container are the same (max-content:
100px & min-content: 50px). In this case we'll use 100px as we're under
a max-content constraint. And then we use it to resolve the percentage.

The min-content case:
  <div style="display: grid; font: 25px/1 Ahem; width: min-content;
grid-template-columns: 50%;">
    <div>XX X</div>
  </div>

Sizes:
* Grid container's width: 50px
* Column: 25px

Here, we'd use the min-content size of the grid container, which is
50px. Again the percentage is resolved against that size calculated before.

So, I cannot find any situation where the inline size of the grid
container is indefinite during layout. It'd be indefinite while we're
computing the intrinsic sizes but not later on when we're calculating
the final size of the tracks.
Maybe it might be worth to clarify the following sentence on the spec
[1], to explain that for the inline size this only happens during
intrinsic sizes computation:
"If the inline or block size of the grid container is indefinite,
 <percentage> values relative to that size are treated as auto."

Thanks,
  Rego

[1]
https://drafts.csswg.org/css-grid/#valdef-grid-template-columns-percentage