Intent to Ship: CSS intrinsic-size

120 views
Skip to first unread message

Vladimir Levin

unread,
Nov 6, 2019, 4:35:55 PM11/6/19
to blink-dev, taba...@chromium.org, Chris Harrelson
vmp...@chromium.org,taba...@chromium.org,chri...@chromium.org https://github.com/WICG/display-locking/blob/master/explainer-intrinsic-size.md https://drafts.csswg.org/css-sizing-4/#intrinsic-size-override https://github.com/w3ctag/design-reviews/issues/437 The intrinsic-size property allows developers to specify a placeholder size which would be used instead of sizing based on children. If intrinsic-size is specified, an element ignores children sizes for the purposes of determining its own size. Instead, it uses the size specified by intrinsic-size as the input to the layout algorithm. 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 intrinsic-size property only has an effect when specified, and extends sizing control by allowing content to be sized by the developer. The feature can be used on its own. 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 https://github.com/web-platform-tests/wpt/pull/20094 https://crbug.com/991096 https://wicg.github.io/display-locking/sample-code/intrinsic-size-block-flow-examples.html https://wicg.github.io/display-locking/sample-code/intrinsic-size-flexbox-examples.html https://www.chromestatus.com/feature/5737051062272000

Vladimir Levin

unread,
Nov 6, 2019, 5:04:20 PM11/6/19
to blink-dev, taba...@chromium.org, Chris Harrelson
Please note that the "public support" from other browser vendors is a consequence of the CSSWG discussion of the feature (irc logs in the github issue), which resulted in a resolution for both the name and the values, with some constructive feedback on the feature. If this is insufficient to claim public support, let me know and I'll change the chromestatus entry.

Florian Rivoal

unread,
Nov 6, 2019, 11:22:39 PM11/6/19
to Vladimir Levin, blink-dev, taba...@chromium.org, Chris Harrelson
Hi,

I think this is a nice feature, and I'm glad you're working on it, but I think it is a little premature to ship it.

It's not fully determined yet what it would mean to set the intrinsic size in the way that this property proposes, and this should be clarified before shipping. I'm aware of one issue open on this topic, but there might be more.

To be clear, I don't ask that you passively wait: pushing for these issues being resolved is very much welcome. Implementing while these discussions are ongoing is fine as well. But I wouldn't ship just yet.

Relatedly, the link to the TAG review shows that it's been requested, but that it hasn't happened yet.

All in all, I'm happy with work on this, I just think it needs a little more time to brew before it's ready for prime time.

On a separate note, thanks for the large number of tests submitted to WPT for this feature, it's great to have detailed coverage. I would however have two requests:
* can you move them to (a subfolder of) wpt/css/css-sizing  ? we normally keep things organized by spec.
* The tests don't have an "assert" meta (see https://web-platform-tests.org/writing-tests/css-metadata.html#test-assertions). They're not mandatory, but highly recommended. In particular, Given that this is fairly new, it would not be surprising to see the spec evolve a bit, and without a meta assert, evaluating whether a test is still valid after a spec change or should be updated is a lot more work.

(I can open separate issues in wpt for these two points if you want, but I thought I'd start by mentioning it here).

—Florian

-- 
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/CADsXd2P8Nd-ZNqnUF96_H05gvn39-idfeQxHGRs1GqLEZuAjBQ%40mail.gmail.com.

Vladimir Levin

unread,
Nov 7, 2019, 8:42:51 AM11/7/19
to Florian Rivoal, blink-dev, taba...@chromium.org, Chris Harrelson
Hey, thanks for the detailed feedback!


On Wed., Nov. 6, 2019, 23:22 Florian Rivoal, <flo...@rivoal.net> wrote:
Hi,

I think this is a nice feature, and I'm glad you're working on it, but I think it is a little premature to ship it.

It's not fully determined yet what it would mean to set the intrinsic size in the way that this property proposes, and this should be clarified before shipping. I'm aware of one issue open on this topic, but there might be more.

To be clear, I don't ask that you passively wait: pushing for these issues being resolved is very much welcome. Implementing while these discussions are ongoing is fine as well. But I wouldn't ship just yet.

Sounds good. I'll try and find out if there are more issues to resolve here


Relatedly, the link to the TAG review shows that it's been requested, but that it hasn't happened yet.

All in all, I'm happy with work on this, I just think it needs a little more time to brew before it's ready for prime time.

On a separate note, thanks for the large number of tests submitted to WPT for this feature, it's great to have detailed coverage. I would however have two requests:
* can you move them to (a subfolder of) wpt/css/css-sizing  ? we normally keep things organized by spec.
* The tests don't have an "assert" meta (see https://web-platform-tests.org/writing-tests/css-metadata.html#test-assertions). They're not mandatory, but highly recommended. In particular, Given that this is fairly new, it would not be surprising to see the spec evolve a bit, and without a meta assert, evaluating whether a test is still valid after a spec change or should be updated is a lot more work.

(I can open separate issues in wpt for these two points if you want, but I thought I'd start by mentioning it here).

Both of these makes sense. I'll update the tests and locations. 


—Florian

On Nov 7, 2019, at 7:02, Vladimir Levin <vmp...@chromium.org> wrote:

Please note that the "public support" from other browser vendors is a consequence of the CSSWG discussion of the feature (irc logs in the github issue), which resulted in a resolution for both the name and the values, with some constructive feedback on the feature. If this is insufficient to claim public support, let me know and I'll change the chromestatus entry.

On Wed, Nov 6, 2019 at 4:35 PM Vladimir Levin <vmp...@chromium.org> wrote:
vmp...@chromium.org,taba...@chromium.org,chri...@chromium.org https://github.com/WICG/display-locking/blob/master/explainer-intrinsic-size.md https://drafts.csswg.org/css-sizing-4/#intrinsic-size-override https://github.com/w3ctag/design-reviews/issues/437 The intrinsic-size property allows developers to specify a placeholder size which would be used instead of sizing based on children. If intrinsic-size is specified, an element ignores children sizes for the purposes of determining its own size. Instead, it uses the size specified by intrinsic-size as the input to the layout algorithm. 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 intrinsic-size property only has an effect when specified, and extends sizing control by allowing content to be sized by the developer. The feature can be used on its own. 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 https://github.com/web-platform-tests/wpt/pull/20094 https://crbug.com/991096 https://wicg.github.io/display-locking/sample-code/intrinsic-size-block-flow-examples.html https://wicg.github.io/display-locking/sample-code/intrinsic-size-flexbox-examples.html https://www.chromestatus.com/feature/5737051062272000

-- 
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/CADsXd2P8Nd-ZNqnUF96_H05gvn39-idfeQxHGRs1GqLEZuAjBQ%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+...@chromium.org.

Manuel Rego Casasnovas

unread,
Nov 12, 2019, 10:50:30 AM11/12/19
to Vladimir Levin, blink-dev, taba...@chromium.org, Chris Harrelson
Hi,

On 06/11/2019 22:35, Vladimir Levin wrote:
> Spec
> https://drafts.csswg.org/css-sizing-4/#intrinsic-size-override

The current spec has a warning "Not Ready For Implementation", it might
be good to have a note in the spec explaining that this part is stable
and can be implemented and shipped.

For example we have a similar thing for CSS Logical Properties:
https://drafts.csswg.org/css-logical/#issue-3d880eb1
The issue in that spec says:
"features in § 2 Flow-Relative Values: block-start, block-end,
inline-start, inline-end and § 4 Flow-Relative Box Model Properties are
approved for shipping".

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

I'm not sure if the fact that it was discussed in the CSSWG implies that
everyone is supporting the feature. But in any case I agree that's a
good sign.
Have we reported bugs in the respective bug trackers (Mozilla and WebKit
mainly)?

> Is this feature fully tested by web-platform-tests?
> Yes
> https://github.com/web-platform-tests/wpt/pull/20094

We have a good set of tests, still I think we could add a few more.
Some ideas:
* More dynamic tests: So far we only have one intrinsic-size-013.html
It might be good to add more cases and also how dynamic changes work
in other cases like replaced elements or scrollbars.
* Apart from parsing, intrisic-height|block only has one test.
A clear example would be to test it with vertical writing modes.
* Interactions between intrinsic-width and min-width and max-width
are only tested for grid containers.
* Does intrinsic-size applies to other elements like buttons, tables,
...? Do we need tests for these cases?

My 2 cents,
Rego

Vladimir Levin

unread,
Nov 13, 2019, 4:04:37 PM11/13/19
to Manuel Rego Casasnovas, blink-dev, taba...@chromium.org, Chris Harrelson
Hey, thanks for the feedback! I haven't had the chance to address it yet, but I will respond inline below.

On Tue, Nov 12, 2019 at 10:50 AM Manuel Rego Casasnovas <re...@igalia.com> wrote:
Hi,

On 06/11/2019 22:35, Vladimir Levin wrote:
> Spec
> https://drafts.csswg.org/css-sizing-4/#intrinsic-size-override

The current spec has a warning "Not Ready For Implementation", it might
be good to have a note in the spec explaining that this part is stable
and can be implemented and shipped.

I think that's a good idea!
Yep, I agree. I wish there was an option between "no signal" and "public support" that would indicate something like this.
 
Have we reported bugs in the respective bug trackers (Mozilla and WebKit
mainly)?

I will do that.
 

> Is this feature fully tested by web-platform-tests?
> Yes
> https://github.com/web-platform-tests/wpt/pull/20094

We have a good set of tests, still I think we could add a few more.
Some ideas:
* More dynamic tests: So far we only have one intrinsic-size-013.html
  It might be good to add more cases and also how dynamic changes work
  in other cases like replaced elements or scrollbars.
* Apart from parsing, intrisic-height|block only has one test.
  A clear example would be to test it with vertical writing modes.
* Interactions between intrinsic-width and min-width and max-width
  are only tested for grid containers.
* Does intrinsic-size applies to other elements like buttons, tables,
  ...? Do we need tests for these cases?

I think these are all good suggestions, and I will add more tests.
 

My 2 cents,
  Rego

Vladimir Levin

unread,
Nov 25, 2019, 10:51:44 AM11/25/19
to Manuel Rego Casasnovas, blink-dev, taba...@chromium.org, Chris Harrelson
Due to some discussions that we had, I'd like to retract this intent for now.

You can see the reasons, and discussion of this feature here: https://github.com/w3c/csswg-drafts/issues/4531
Reply all
Reply to author
Forward
0 new messages