-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CSS contain-intrinsic-size #437
Comments
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 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 Finally, it seems unusual for an initial value not to be |
Hi, here are some responses to a couple of your points.
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:
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).
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:
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 |
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 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 |
@cbiesinger Thanks for the update! I see the explainer for |
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 ...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! |
Hello TAG!
I'm requesting a TAG review of:
Further details:
We'd prefer the TAG provide feedback as (please select one):
The text was updated successfully, but these errors were encountered: