Intent to Ship: CSS contain-intrinsic-size

135 views
Skip to first unread message

Christian Biesinger

unread,
Feb 13, 2020, 5:20:28 PM2/13/20
to blink-dev
vmp...@chromium.org,taba...@chromium.org,chri...@chromium.org,cbies...@chromium.org https://github.com/WICG/display-locking/blob/master/explainer-contain-intrinsic-size.md https://drafts.csswg.org/css-sizing-4/#intrinsic-size-override (will be updated per the CSSWG resolution in https://github.com/w3c/csswg-drafts/issues/4531) 
https://github.com/w3ctag/design-reviews/issues/437 The contain-intrinsic-size property allows developers to specify a placeholder size which would be used while contain: size is applied. With contain-intrinsic-size specified, elements lay out as if they had a single child with fixed size (specified by contain-intrinsic-size) unless they have an explicit width/height. This is helpful when size containment may be dynamically added/removed so that there is a fallback size during size containment but a content-based size during regular sizing. https://groups.google.com/a/chromium.org/d/msg/blink-dev/RMCpsWaqds0/_H9hTQ5tAgAJ
This is a feature detectable CSS property, which can be approximated with other sizing information. This minimizes the risk of interoperability problems. Firefox: Public support (https://github.com/w3c/csswg-drafts/issues/4229) Note that the issue has 2 IRC logs from CSSWG discussing the feature and resolving on names/values. Edge: Public support (https://github.com/w3c/csswg-drafts/issues/4229) Note that the issue has 2 IRC logs from CSSWG discussing the feature and resolving on names/values. Safari: Public support (https://github.com/w3c/csswg-drafts/issues/4229) Note that the issue has 2 IRC logs from CSSWG discussing the feature and resolving on names/values. Web developers: Positive (https://github.com/w3c/csswg-drafts/issues/4229) Note that the issue has 2 IRC logs from CSSWG discussing the feature and resolving on names/values. The contain-intrinsic-size property only has an effect when specified, and extends sizing control by allowing content to be sized by the developer when contain: size is applied. The feature can be used with contain: size (already shipped). It does not introduce any inefficiencies or new constraints to Blink / Chromium. It should be straight-forward for developers to use this feature. The effect of this feature can be approximated by other sizing functionality (width/height/min-width/min-height etc), so polyfills should not be necessary. None
This feature should be debuggable by inspecting style / computed style in devtools. Yes Yes Currently in wpt_internal/css/css-sizing/intrinsic-size, will move to wpt shortly (https://crrev.com/c/2055740) https://crbug.com/991096 https://chromestatus.com/feature/5737051062272000
This intent message was generated by Chrome Platform Status.

Manuel Rego Casasnovas

unread,
Feb 13, 2020, 5:59:28 PM2/13/20
to blin...@chromium.org

On 13/02/2020 23:19, Christian Biesinger wrote:
> /Firefox/: Public support
> (https://github.com/w3c/csswg-drafts/issues/4229) Note that the issue
> has 2 IRC logs from CSSWG discussing the feature and resolving on
> names/values.

It'd be nice to report a bug at Firefox bugzilla about this property, as
Firefox is also shipping css-contain.

Also maybe it'd be nice to clarify in the chreomstatus entry that this
is not only a new shorthand contain-intrinsic-size, but also the
longhands contain-intrinsic-{block,inline,height,width}-size.

My 2 cents,
Rego

Christian Biesinger

unread,
Feb 13, 2020, 6:15:14 PM2/13/20
to Manuel Rego Casasnovas, blink-dev
On Thu, Feb 13, 2020 at 4:59 PM Manuel Rego Casasnovas <re...@igalia.com> wrote:
>
>
> On 13/02/2020 23:19, Christian Biesinger wrote:
> > /Firefox/: Public support
> > (https://github.com/w3c/csswg-drafts/issues/4229) Note that the issue
> > has 2 IRC logs from CSSWG discussing the feature and resolving on
> > names/values.
>
> It'd be nice to report a bug at Firefox bugzilla about this property, as
> Firefox is also shipping css-contain.

It looks like there was already a bug filed:
https://bugzilla.mozilla.org/show_bug.cgi?id=1597529
I've updated it per the new name.

> Also maybe it'd be nice to clarify in the chreomstatus entry that this
> is not only a new shorthand contain-intrinsic-size, but also the
> longhands contain-intrinsic-{block,inline,height,width}-size.

No, the longhands are no longer part of the plan for shipping, as
agreed at the CSSWG. There is only contain-intrinsic-size: auto |
<length> | <length> <length>

Christian

Manuel Rego Casasnovas

unread,
Feb 14, 2020, 3:06:31 AM2/14/20
to Christian Biesinger, blink-dev


On 14/02/2020 00:14, Christian Biesinger wrote:
> On Thu, Feb 13, 2020 at 4:59 PM Manuel Rego Casasnovas <re...@igalia.com> wrote:
>>
>>
>> On 13/02/2020 23:19, Christian Biesinger wrote:
>>> /Firefox/: Public support
>>> (https://github.com/w3c/csswg-drafts/issues/4229) Note that the issue
>>> has 2 IRC logs from CSSWG discussing the feature and resolving on
>>> names/values.
>>
>> It'd be nice to report a bug at Firefox bugzilla about this property, as
>> Firefox is also shipping css-contain.
>
> It looks like there was already a bug filed:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1597529
> I've updated it per the new name.

Great.

>> Also maybe it'd be nice to clarify in the chreomstatus entry that this
>> is not only a new shorthand contain-intrinsic-size, but also the
>> longhands contain-intrinsic-{block,inline,height,width}-size.
>
> No, the longhands are no longer part of the plan for shipping, as
> agreed at the CSSWG. There is only contain-intrinsic-size: auto |
> <length> | <length> <length>

Ok, thanks for the clarification. It needs the spec needs a bunch of edits.

Bye,
Rego

Yoav Weiss

unread,
Feb 20, 2020, 2:36:46 PM2/20/20
to Christian Biesinger, blink-dev
On Thu, Feb 13, 2020 at 11:20 PM Christian Biesinger <cbies...@chromium.org> wrote:
vmp...@chromium.org,taba...@chromium.org,chri...@chromium.org,cbies...@chromium.org https://github.com/WICG/display-locking/blob/master/explainer-contain-intrinsic-size.md https://drafts.csswg.org/css-sizing-4/#intrinsic-size-override (will be updated per the CSSWG resolution in https://github.com/w3c/csswg-drafts/issues/4531) 
https://github.com/w3ctag/design-reviews/issues/437 The contain-intrinsic-size property allows developers to specify a placeholder size which would be used while contain: size is applied. With contain-intrinsic-size specified, elements lay out as if they had a single child with fixed size (specified by contain-intrinsic-size) unless they have an explicit width/height. This is helpful when size containment may be dynamically added/removed so that there is a fallback size during size containment but a content-based size during regular sizing. https://groups.google.com/a/chromium.org/d/msg/blink-dev/RMCpsWaqds0/_H9hTQ5tAgAJ
This is a feature detectable CSS property, which can be approximated with other sizing information. This minimizes the risk of interoperability problems. Firefox: Public support (https://github.com/w3c/csswg-drafts/issues/4229) Note that the issue has 2 IRC logs from CSSWG discussing the feature and resolving on names/values. Edge: Public support (https://github.com/w3c/csswg-drafts/issues/4229) Note that the issue has 2 IRC logs from CSSWG discussing the feature and resolving on names/values. Safari: Public support (https://github.com/w3c/csswg-drafts/issues/4229) Note that the issue has 2 IRC logs from CSSWG discussing the feature and resolving on names/values. Web developers: Positive (https://github.com/w3c/csswg-drafts/issues/4229) Note that the issue has 2 IRC logs from CSSWG discussing the feature and resolving on names/values.

Can you point to specific statements in those IRC logs referring to said support? Do we know something about plans for implementation?
 
The contain-intrinsic-size property only has an effect when specified, and extends sizing control by allowing content to be sized by the developer when contain: size is applied. The feature can be used with contain: size (already shipped). It does not introduce any inefficiencies or new constraints to Blink / Chromium. It should be straight-forward for developers to use this feature. The effect of this feature can be approximated by other sizing functionality (width/height/min-width/min-height etc), so polyfills should not be necessary. None
This feature should be debuggable by inspecting style / computed style in devtools. Yes Yes Currently in wpt_internal/css/css-sizing/intrinsic-size, will move to wpt shortly (https://crrev.com/c/2055740) https://crbug.com/991096 https://chromestatus.com/feature/5737051062272000
This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XFA14%2Bnyb4yjf1aChPTy%2ByzYrLaPmVUc69hhwpTk4vO6g%40mail.gmail.com.

Daniel Bratell

unread,
Feb 25, 2020, 10:43:37 AM2/25/20
to Yoav Weiss, Christian Biesinger, blink-dev

@cbiesinger, did you have a look at Yoav's questions? This look fairly natural to me but I've been waiting to see if you or Yoav found something that needed further work.

/Daniel

Christian Biesinger

unread,
Feb 25, 2020, 1:45:38 PM2/25/20
to Yoav Weiss, blink-dev
On Thu, Feb 20, 2020 at 1:36 PM Yoav Weiss <yo...@yoav.ws> wrote:
>
>
>
> On Thu, Feb 13, 2020 at 11:20 PM Christian Biesinger <cbies...@chromium.org> wrote:
>>
>> Contact emails vmp...@chromium.org,taba...@chromium.org,chri...@chromium.org,cbies...@chromium.org Explainer https://github.com/WICG/display-locking/blob/master/explainer-contain-intrinsic-size.md Spec https://drafts.csswg.org/css-sizing-4/#intrinsic-size-override (will be updated per the CSSWG resolution in https://github.com/w3c/csswg-drafts/issues/4531)
>>
>> TAG review https://github.com/w3ctag/design-reviews/issues/437 Summary The contain-intrinsic-size property allows developers to specify a placeholder size which would be used while contain: size is applied. With contain-intrinsic-size specified, elements lay out as if they had a single child with fixed size (specified by contain-intrinsic-size) unless they have an explicit width/height. This is helpful when size containment may be dynamically added/removed so that there is a fallback size during size containment but a content-based size during regular sizing. Link to “Intent to Prototype” blink-dev discussion https://groups.google.com/a/chromium.org/d/msg/blink-dev/RMCpsWaqds0/_H9hTQ5tAgAJ Risks
>> Interoperability and Compatibility This is a feature detectable CSS property, which can be approximated with other sizing information. This minimizes the risk of interoperability problems. Firefox: Public support (https://github.com/w3c/csswg-drafts/issues/4229) Note that the issue has 2 IRC logs from CSSWG discussing the feature and resolving on names/values. Edge: Public support (https://github.com/w3c/csswg-drafts/issues/4229) Note that the issue has 2 IRC logs from CSSWG discussing the feature and resolving on names/values. Safari: Public support (https://github.com/w3c/csswg-drafts/issues/4229) Note that the issue has 2 IRC logs from CSSWG discussing the feature and resolving on names/values. Web developers: Positive (https://github.com/w3c/csswg-drafts/issues/4229) Note that the issue has 2 IRC logs from CSSWG discussing the feature and resolving on names/values.
>
>
> Can you point to specific statements in those IRC logs referring to said support? Do we know something about plans for implementation?

Sorry for the late response, I was OOO last week. I was mainly
referring to the "RESOLVED" lines -- these were transcripts from
phone/in person meetings and there were no objections. I do not know
about implementation plans.

Yoav Weiss

unread,
Feb 27, 2020, 5:10:37 PM2/27/20
to Christian Biesinger, blink-dev
LGTM1

Reasoning below...

On Tue, Feb 25, 2020 at 7:45 PM Christian Biesinger <cbies...@chromium.org> wrote:
On Thu, Feb 20, 2020 at 1:36 PM Yoav Weiss <yo...@yoav.ws> wrote:
>
>
>
> On Thu, Feb 13, 2020 at 11:20 PM Christian Biesinger <cbies...@chromium.org> wrote:
>>
>> Contact emails vmp...@chromium.org,taba...@chromium.org,chri...@chromium.org,cbies...@chromium.org Explainer https://github.com/WICG/display-locking/blob/master/explainer-contain-intrinsic-size.md Spec https://drafts.csswg.org/css-sizing-4/#intrinsic-size-override (will be updated per the CSSWG resolution in https://github.com/w3c/csswg-drafts/issues/4531)
>>
>> TAG review https://github.com/w3ctag/design-reviews/issues/437 Summary The contain-intrinsic-size property allows developers to specify a placeholder size which would be used while contain: size is applied. With contain-intrinsic-size specified, elements lay out as if they had a single child with fixed size (specified by contain-intrinsic-size) unless they have an explicit width/height. This is helpful when size containment may be dynamically added/removed so that there is a fallback size during size containment but a content-based size during regular sizing. Link to “Intent to Prototype” blink-dev discussion https://groups.google.com/a/chromium.org/d/msg/blink-dev/RMCpsWaqds0/_H9hTQ5tAgAJ Risks
>> Interoperability and Compatibility This is a feature detectable CSS property, which can be approximated with other sizing information. This minimizes the risk of interoperability problems. Firefox: Public support (https://github.com/w3c/csswg-drafts/issues/4229) Note that the issue has 2 IRC logs from CSSWG discussing the feature and resolving on names/values. Edge: Public support (https://github.com/w3c/csswg-drafts/issues/4229) Note that the issue has 2 IRC logs from CSSWG discussing the feature and resolving on names/values. Safari: Public support (https://github.com/w3c/csswg-drafts/issues/4229) Note that the issue has 2 IRC logs from CSSWG discussing the feature and resolving on names/values. Web developers: Positive (https://github.com/w3c/csswg-drafts/issues/4229) Note that the issue has 2 IRC logs from CSSWG discussing the feature and resolving on names/values.
>
>
> Can you point to specific statements in those IRC logs referring to said support? Do we know something about plans for implementation?

Sorry for the late response, I was OOO last week. I was mainly
referring to the "RESOLVED" lines -- these were transcripts from
phone/in person meetings and there were no objections. I do not know
about implementation plans.

While no objections is certainly not a negative signal, and the fact that dbaron was involved in discussions on both CSSWG and TAG is encouraging, I don't think the CSSWG decision can actually count as "public support" from the vendors themselves.

With that said, the design was thoroughly debated, the scope is fairly narrow, and it's my understanding that developers that are likely to use this can do so in a defensive way, so that their content doesn't break in non-supporting browsers. So this seems good to ship.

Daniel Bratell

unread,
Feb 28, 2020, 12:45:12 PM2/28/20
to Yoav Weiss, Christian Biesinger, blink-dev

LGTM2

/Daniel

Mike West

unread,
Mar 4, 2020, 4:12:46 PM3/4/20
to Daniel Bratell, Yoav Weiss, Christian Biesinger, blink-dev
LGTM3.

-mike


To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b5b3c523-262d-2f14-37d0-9c495973353b%40gmail.com.

Christian Biesinger

unread,
Mar 5, 2020, 2:12:26 PM3/5/20
to Mike West, Daniel Bratell, Yoav Weiss, blink-dev
Thanks, enabling in https://crrev.com/c/2090019

Christian

sligh...@chromium.org

unread,
Mar 5, 2020, 5:15:56 PM3/5/20
to blink-dev, mk...@chromium.org, brat...@gmail.com, yo...@yoav.ws
We've got 3 LGTMs so mine isn't necessary, but I wanted to thank the team for being responsive to TAG feedback and improving the explainer.


On Thursday, March 5, 2020 at 11:12:26 AM UTC-8, Christian Biesinger wrote:
Thanks, enabling in https://crrev.com/c/2090019

Christian

On Wed, Mar 4, 2020 at 3:12 PM Mike West <mk...@chromium.org> wrote:
>
> LGTM3.
>
> -mike
>
>
> On Fri, Feb 28, 2020 at 6:45 PM Daniel Bratell <brat...@gmail.com> wrote:
>>
>> LGTM2
>>
>> /Daniel
>>
>> On 2020-02-27 23:10, Yoav Weiss wrote:
>>
>> LGTM1
>>
>> Reasoning below...
>>
>> On Tue, Feb 25, 2020 at 7:45 PM Christian Biesinger <cbies...@chromium.org> wrote:
>>>
>>> On Thu, Feb 20, 2020 at 1:36 PM Yoav Weiss <yo...@yoav.ws> wrote:
>>> >
>>> >
>>> >
>>> > On Thu, Feb 13, 2020 at 11:20 PM Christian Biesinger <cbies...@chromium.org> wrote:
>>> >>
>>> >>
>>> >> TAG review https://github.com/w3ctag/design-reviews/issues/437 Summary The contain-intrinsic-size property allows developers to specify a placeholder size which would be used while contain: size is applied. With contain-intrinsic-size specified, elements lay out as if they had a single child with fixed size (specified by contain-intrinsic-size) unless they have an explicit width/height. This is helpful when size containment may be dynamically added/removed so that there is a fallback size during size containment but a content-based size during regular sizing. Link to “Intent to Prototype” blink-dev discussion https://groups.google.com/a/chromium.org/d/msg/blink-dev/RMCpsWaqds0/_H9hTQ5tAgAJ Risks
>>> >> Interoperability and Compatibility This is a feature detectable CSS property, which can be approximated with other sizing information. This minimizes the risk of interoperability problems. Firefox: Public support (https://github.com/w3c/csswg-drafts/issues/4229) Note that the issue has 2 IRC logs from CSSWG discussing the feature and resolving on names/values. Edge: Public support (https://github.com/w3c/csswg-drafts/issues/4229) Note that the issue has 2 IRC logs from CSSWG discussing the feature and resolving on names/values. Safari: Public support (https://github.com/w3c/csswg-drafts/issues/4229) Note that the issue has 2 IRC logs from CSSWG discussing the feature and resolving on names/values. Web developers: Positive (https://github.com/w3c/csswg-drafts/issues/4229) Note that the issue has 2 IRC logs from CSSWG discussing the feature and resolving on names/values.
>>> >
>>> >
>>> > Can you point to specific statements in those IRC logs referring to said support? Do we know something about plans for implementation?
>>>
>>> Sorry for the late response, I was OOO last week. I was mainly
>>> referring to the "RESOLVED" lines -- these were transcripts from
>>> phone/in person meetings and there were no objections. I do not know
>>> about implementation plans.
>>
>>
>> While no objections is certainly not a negative signal, and the fact that dbaron was involved in discussions on both CSSWG and TAG is encouraging, I don't think the CSSWG decision can actually count as "public support" from the vendors themselves.
>>
>> With that said, the design was thoroughly debated, the scope is fairly narrow, and it's my understanding that developers that are likely to use this can do so in a defensive way, so that their content doesn't break in non-supporting browsers. So this seems good to ship.
>>
>>>
>>> >
>>> >>
>>> >> Ergonomics The contain-intrinsic-size property only has an effect when specified, and extends sizing control by allowing content to be sized by the developer when contain: size is applied. The feature can be used with contain: size (already shipped). It does not introduce any inefficiencies or new constraints to Blink / Chromium. Activation It should be straight-forward for developers to use this feature. The effect of this feature can be approximated by other sizing functionality (width/height/min-width/min-height etc), so polyfills should not be necessary. Security None
>>> >> Debuggability This feature should be debuggable by inspecting style / computed style in devtools. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests? Yes Currently in wpt_internal/css/css-sizing/intrinsic-size, will move to wpt shortly (https://crrev.com/c/2055740) Tracking bug https://crbug.com/991096 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5737051062272000
>>> >> This intent message was generated by Chrome Platform Status.
>>> >>
>>> >> --
>>> >> You received this message because you are subscribed to the Google Groups "blink-dev" group.
>>> >> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
>>> >> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XFA14%2Bnyb4yjf1aChPTy%2ByzYrLaPmVUc69hhwpTk4vO6g%40mail.gmail.com.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
>> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhGg8k%2BiHhUmGcLGC4ZzWojHzmodTPT5hD3RKnUmmDnCA%40mail.gmail.com.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Reply all
Reply to author
Forward
0 new messages