- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 Dec 2019 17:42:49 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-sizing] intrinsic-size lost the thread :(`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-sizing] intrinsic-size lost the thread :(<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4531<br> <dael> TabAtkins: At TPAC I introduced intrinsic-size proposal. During discussion realized this sounded more generalizable to override intrinisic size. Upon futhre review it means display locking case is much harder to use b/c have to control if intrinsic-size is applied or not<br> <dael> TabAtkins: If the thing has been rendered you don't want to override anymore. You want to override the contain size that comes from async and remove contain state.<br> <dael> TabAtkins: Proposal is we go back to the older idea. WE give a non-0 default size. Other use cases at TPAC around bad intrinisic size for scrollers and virtual scrollbars this wouldn't block them from being addressed separately<br> <dael> TabAtkins: What we agreed at TPAC makes async much more complex for the author. The cases piled on top for a more general intrinisic size aren't worth the increase in complexity<br> <dael> TabAtkins: Want to revert to it changing way contain size works<br> <dael> fantasai: Questions: display locking there's a magic state no reflected in attributes and in some there's contain:size or in all?<br> <dael> TabAtkins: In some of the states<br> <dael> fantasai: And contain:size has to be removed by author?<br> <dael> TabAtkins: Done automatically<br> <dael> fantasai: If there's an intrinsic size the UA doesn't know to remove or not<br> <dael> TabAtkins: yes, exactly<br> <dael> fantasai: Okay, I think I understand what's happening<br> <astearns> s/contain size/contain:size/<br> <dael> fantasai: I'm a little uncomfortable with this being sep b/c it does fundimentally same. One is to explicitly say always and one is for sometimes. i'm a little uncomfortable with them being distinct features that don't relate to each other<br> <dael> fantasai: Not sure I'm happy with a separate property. Seems similar case to aspect ratio where we have use case for explicit which are always in effect and then ones that are only until image is loaded. There's a state dependency.<br> <dael> fantasai: We have this idea where those concepts are in the same property. I think that my preference is we keep it as intrinsic-size property and adda . keyword for if it takes effect or if it's auto<br> <dael> fremy: That's what I was going ot suggest. Say if this is all the time or only sometimes<br> <dael> TabAtkins: My objection is outside of this display locking we hadn't IDed any use cases that needed an explicit size. We can use this to make it say 0 but it doesn't need full power of a size. Other nice thing is make an element always have scrollbars is a nice to have. There's reasonable use cases for this. It's nice, but not very important and I don't want to complexify<br> <dael> TabAtkins: one happy accident with intrinsic-size is when people are doing virtual scrollers you want scrollabr to look the right height. Right now people put a tall invisible element. If we use intrinisic-size argued it could spec the same thing. This element is 10000px intrinsic so you get a large scrollbar<br> <dael> fantasai: Gotcha<br> <dael> TabAtkins: florian disagreed if that should mechanically happen, though<br> <dael> fantasai: I think dbaron has brought up case of setting intrinsic size more explicitly, but I don't remember them<br> <dael> dbaron: I don't either<br> <dael> chrishtr: As part of TAG rview discovered it's not clear [missed]. DIdn't realize until I did more research<br> <dael> chrishtr: Most compelling is a detached layout mode and you don't include until it's detached.<br> <dael> chrishtr: As part of TAG review they pointed out it's not clear what layout modes intrinisic-sizing would make more powerful in ways that matter. Unless it's a way to provide placeholders for things you want to have detached layout for<br> <dael> chrishtr: I second TabAtkins not being sure there are more use cases for this general property. The scrollbar and flexbox algo we can fix more explicitly<br> <dael> TabAtkins: flexbox algo is scrollers get too big<br> <dael> TabAtkins: We can rename the property to be more explicitly about what it does. That would make it clearer if we need intrinsic-size explicit override<br> <dael> AmeliaBR: I'd argue for that even if we don't expect a general intrinsic-size. let's make a name that's containment size or something that's clear<br> <dbaron> +1 to having a more specific name if it has a more specific behavior<br> <fantasai> +1<br> <dael> Rossen_: Agree. Intrinsic-size as a concept is something explict.<br> <dael> Rossen_: Other than the name is this still a property we want to persue<br> <fantasai> Would suggest 'contain-size', sharing a prefix with 'contain' and suffix with 'size' property<br> <fantasai> s/size/-size/<br> <dael> florian: Should spend more time re-thinking. This is an interesting point. If no strong use case for the general TabAtkins proposal makes sense. If we will go there eventually fantasai proposal makes sense. Should see if we remember use cases<br> <fantasai> +1 to florian<br> <dael> fremy: I recalled mine but thinking more they were all better with custom layouts<br> <dael> fremy: I feel like my use cases could be solved with custom layout. It's a better solution. Originally custom layout wasn't there. But now that it is I can't think of one that would be better without the custom layout<br> <dael> chrishtr: If we have more use cases and a general property we would still need a property to switch<br> <dael> florian: Yes, we want a single property with mode switch if there are other cases. If not special property<br> <dbaron> (to apply only when `contain:size` is present<br> <dael> chrishtr: I hope we start witht hat part<br> <dael> fantasai: I agree with florian desc of where we are<br> <dael> TabAtkins: Can we timebox it?<br> <dael> TabAtkins: Sooner is better, we're trying to finish in our impl. It's not must right now, but sooner<br> <dael> fantasai: Timebox of next week or first week of Jan?<br> <dbaron> q+ to mention other use cases for intrinsic size property<br> <dael> TabAtkins: If dbaron had use cases before a week should be enough to remember. Presumably we've discussed in the past.<br> <dael> florian: Difference between next week and early Jan isn't much unless you're trying to ship before Xmas<br> <dael> fremy: And have to keep in mind people are in vacation<br> <dael> dbaron: I wanted to say about use cases is the things I remember use cases for are 2 things. One is to override the behvaior where overflow !=0 causes min-size to be 0. And the others were setting intrinsic size to be 0; don't remember if it's mix or max size<br> <dbaron> s/min-size/min-intrinsic/<br> <dael> AmeliaBR: Sounds like people might want to skim previous issues. Initial proposal had many variations. Different use cases had different situations<br> <dael> TabAtkins: Also intregued that both of dbaron use cases are 0 or not, not about setting a non-0 value<br> <AmeliaBR> Previous discussion where many possible use cases were brought up: https://github.com/w3c/csswg-drafts/issues/4229#issuecomment-531615054<br> <dael> fantasai: Objects which don't have intrinsic size and we default to 300x150 and this could allow a more usable size. Most could be handled by setting a size.<br> <AmeliaBR> s/many variations/many variations, such as whether this applied as a minimum or maximum or both/<br> <dael> iank_: Use case to set to 0 is if something is shrink to fit and available size is smaller then the minimum size and you've got overflow:scroll That float will never be able to shrink to the available size.<br> <iank_> e.g. https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=7541<br> <dael> florian: Another use case is to set the min intrinsic size is larger than natural layout. We have number of layout modes that use min-size to do things but math conclusion of min-soze may be too tight. You want things to work from a slightly larger min. An element with a mutlicol and min-soze goes to shortest word but you know you don't want less than 2 col<br> <dael> florian: This isn't clearly articulated; I'd appriciate more than a week<br> <dael> chrishtr: Let's wait until 1st week in Jan to write use cases and decide then<br> <dael> fantasai: Start a new thread on use cases rather than follow up on this issue?<br> <dael> chrishtr: Sure. I'll make a new issue and link to it from the existing<br> <dael> Rossen_: I think that's all we can say on this issue. chrishtr thanks for making the new issue. We'll take this back in beginning of Jan<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4531#issuecomment-564655162 using your GitHub account
Received on Wednesday, 11 December 2019 17:42:55 UTC