CSS contain-intrinsic-size
vmpstr opened this issue · 20 comments
Hello TAG!
I'm requesting a TAG review of:
- Name: CSS intrinsic-size
- Specification URL: https://wicg.github.io/display-locking/contain-intrinsic-size.html
- Explainer: https://github.com/WICG/display-locking/blob/master/explainer-contain-intrinsic-size.md
- Tests: will be css/css-intrinsic-size, but currently not yet implemented
- Primary contacts: @vmpstr @tabatkins @chrishtr (authors)
Further details:
- Relevant time constraints or deadlines: None
- I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
- I have reviewed the TAG's API Design Principles
- The group where the work on this specification is: csswg
We'd prefer the TAG provide feedback as (please select one):
- open issues in our GitHub repo for each point of feedback
- open a single issue in our GitHub repo for the entire review
- leave review feedback as a comment in this issue and @-notify primary contacts
Just a quick process question: why is this explainer in the WICG and the work is going on in CSS? Thanks.
This feature was initially a part of display-locking, which is a WICG project. We've decided that it made sense on its own, as part of CSSWG. However, the explainer remained in display-locking WICG repo. Hopefully that's not an issue.
I think from a TAG perspective this is fine. I was a little concerned that the early proposals were too narrow (and creating a new CSS property for something very specific when it could have been more general), but what is now specified is now more general as I was hoping.
I did give some additional feedback from my perspective as a CSS WG participant, but I don't think of that as an issue that the TAG should be concerned about.
We discussed briefly on today's call. Will try to close in 2 weeks at our f2f.
I had a chat with @dbaron and @plinss about this, and spent some time looking at the spec, explainer and examples.
Firstly, the explainer seems to be out of date compared to the spec: there is no mention of intrinsic-block-size, intrinsic-inline-size, intrinsic-height or intrinsic-width, nor the legacy or auto value keywords.
Secondly, even looking at the spec, explainer and examples, I had trouble following what problem this proposal is solving. In particular, it was very unclear to me (even after looking at the examples) why the existing properties mentioned in the "Alternatives Considered" section weren't sufficient.
It would be very helpful to have a clear explanation/demonstration of what the precise problem is, and how the existing options behave incorrectly. The examples assert that the behaviour is incorrect, but without a clear explanation of what the desired behaviour is in each case it doesn't actually help in understanding the issue.
I would also like to understand why we have, for example, both inline-block-size and inline-width - under what circumstances would authors choose one over the other?
Finally, it seems unusual for an initial value not to be auto when an auto value exists. Could you provide some insight into that choice?
Hi, here are some responses to a couple of your points.
Secondly, even looking at the spec, explainer and examples, I had trouble following what problem this proposal is solving. In particular, it was very unclear to me (even after looking at the examples) why the existing properties mentioned in the "Alternatives Considered" section weren't sufficient.
Hmm. The explainer addresses each of these directly. Perhaps there was something missed, or the explanation could be improved.
The primary motivating use case is representing estimated placeholder sizing of a DOM subtree, to avoid layout instability and preserve scroll sizing. The browser may not have done the work for multiple reasons, some of which include:
- Subtree content is not yet loaded
- Subtree content was not committed, or fully committed, from VDOM or some other script-internal state
- Subtree content has display:none
- Root of subtree uses rendersubtree (the other part of the overall display locking proposal), and the browser skipped doing this work
There are other use cases that may arise because now the developer can specify the intrinsic sizing inputs to layout algorithms directly. One potential such use case involving control of scrollbars was brought up at TPAC (by another CSSWG member).
It would be very helpful to have a clear explanation/demonstration of what the precise problem is, and how the existing options behave incorrectly. The examples assert that the behaviour is incorrect, but without a clear explanation of what the desired behaviour is in each case it doesn't actually help in understanding the issue.
I'll try to state it as succinctly as possible: *representing estimated placeholder sizing of a DOM subtree which will be loaded and/or rendered later.
With that statement I hope it's clear why the examples state that the alternative approaches are incorrect. In those examples, the desired behavior is that a DOM subtree which has an actual sizing exactly equal to the intrinsic sizing CSS property should have exactly the same layout impact on the rest of the document. In other words: once the content has loaded and rendered, layout should remain stable.
The "existing options" don't have that behavior on the described examples.
All the explainer says about the alternatives is:
Elements can already be sized by width, min-width, and various other sizing CSS properties. However, these properties fall short, because they all affect not just intrinsic sizing, but other layout inputs as well. The examples section gives several examples of this.
It doesn't give examples of where using the existing properties [Edit to add: or doing nothing at all] would do something other than what the author wants. The two examples then just say "Notice layout result is not as desired." without saying what was desired or how the result is different. (Note that the examples don't currently work, even in up-to-date Chrome 78 with experimental web platform features enabled, so it's hard to understand what was intended.) For example, I think I just figured out the intent of the first example in the block-flow examples, but it required that I view source and spend five minutes thinking about what you wanted to happen in that case.
In the first example in the block-flow examples, the example is showing that while you want the element to report a 300px intrinsic width, you still want to allow it to shrink smaller than that size if its container is smaller than that size. It would be good to state that explicitly for the first example, and whatever the equivalent is for the other examples, so that the explainer actually says what it is that this property can do that the existing properties can't, rather than requiring the reader to re-derive that from the examples. Even then, the example still doesn't show why reporting the 300px intrinsic width is useful; it doesn't show it doing anything. Showing that seems to require the example be developed a little further.
Perhaps there was something missed, or the explanation could be improved.
Yes, I'm asking that the explainer (and examples) be improved. Thank you.
Hi,
Vlad and I reviewed the examples links from the explainer, and did see a few errors there. We also agree that those examples don't in the end show obviously compelling use-cases, especially as compared to using min-width and min-height directly.
We're going to follow up on the CSSWG issue and propose some changes to be re-discussed there in the WG. Once that is resolved one way or the other I'll come back here and give a status update on the proposal.
Thanks for reading the explainer and examples in depth.
Thanks for the update. I'm going to mark this as pending external feedback until we hear back from you.
Sounds good. I appreciate your reviews!
CSSWG has approved some changes to this property: w3c/csswg-drafts#4531
It is now named contain-intrinsic-size and only applies if contain:size is set.
@cbiesinger Thanks for the update!
I see the explainer for intrinsic-size has been removed, presumably due to that change. It's a bit hard to follow the current set of use cases for contain-intrinsic-size from that issue thread - is someone able to comment with what you had in mind when designing it?
The explainer for contain-intrinsic-size is now here and the spec draft is here. Please note that we're still working on some motivating examples to go along with the explainer.
The motivation for the change stemmed from the responses to this thread. They made us take a closer look at the value that we were providing, and realize that we inadvertently moved away from size-containment and thus moved away from much of the usefuless of the feature. Some more context is here. The change to move back to size-containment restored the use for our original use case: to act as a placeholder size when child sizing information may not be available (due to, for example, subtree-visibility).
Apologies, the explainer got renamed: https://github.com/WICG/display-locking/blob/master/explainer-contain-intrinsic-size.md
The basic use case is for an element that changes from having contain: size applied to not having it, e.g. because of display locking, but can be useful elsewhere (virtual scrollers, perhaps) -- in such a case, it can be useful to specify a size that only applies while contained (otherwise it would be 0x0), whereas when not contained, you want it to just size based on its content.
...I see vlad responded while I was writing, oh well.
Hehe, thanks for the explanations! We'll reschedule this for a later breakout session.
@alice, @torgo and myself did another pass of this. The overall progress and shape of the feature is satisfactory from the point of view of the TAG. What used to be a fairly narrow use case and solution is now evolving in a more useful feature for the broader CSS.
One request - you should update the explainer by adding motivational use cases and examples of how your solution address it. This is of course need for developer documentation such as MDN.
There are now examples in https://wicg.github.io/display-locking/sample-code/contain-intrinsic-size-examples.html, linked from the explainer. Thanks for the update!
In particular example 4 is a motivating real-world example
Great to see that @cbiesinger! Thanks for the update!