[css-sizing] intrinsic-size lost the thread 🙁

[tabatkins]

At the last f2f, when we discussed the proposal to allow an async-layout element to specify a "default" size while it's not actually laying out its contents (effectively contain:size), over the course of the conversation we ended up redefining it into a more general ability to manually set the intrinsic size of an element.

As we've experimented with implementation, tho, we've come to realize that this generalization accidentally significantly broke the usability of the feature for its original use-case.

• With the original (attribute-based) proposal, previously authors could set the "default size" property on all async-layout elements, and it would only trigger when needed (when the element wasn't displaying its children); it would stop affecting anything once full layout started working. With this change, authors instead have to carefully target their rules so that 'intrinsic-size' stops applying when full layout starts, or else lingering effects of the property can produce confusing layout artifacts.
• With our exploration into an alternative CSS-based async layout, you can't even target things carefully anymore; you instead have to track "is locked/unlocked" separately with script and rely on that to apply/unapply 'intrinsic-size', breaking all the elegant simplicity.

Regarding the additional use-cases we ended up addressing with the revised "applies all the time" property:

• Per dbaron's comment, the auto/legacy usecase that partially justified the expansion of the concept needs some more thought anyway, and should maybe be a separate feature.
• The "generate appropriate scrollbars for virtual scrollers" use-case ([css-sizing-4] Scrollbars when intrinsic-width is > width? #4415) was just a nice freebie feature; it's not an important feature to preserve right now, and can be easily hacked with a fake element at the moment.

So after discussion with @vmpstr and @chrishtr, we'd like to change tactics: we want to withdraw the general intrinsic-size property for now, and return to the earlier concept of something that solely provides a non-zero size for contents solely when size containment is applying.

Name is up for grabs; it just needs to be something other than 'intrinsic-size', since it's explicitly not setting that general concept.

---

And then separately we'll still want to figure out a good solution to the auto/legacy use-case, but need to review dbaron's feedback.

[chrishtr]

• previously authors could set the "default size" property on all async-layout elements, and it would only trigger when needed

This was possible with CSS by using an attribute selector such as:

[rendersubtree*="invisible"] {
  intrinsic-size: 300px 400px
}

As Tab mentioned, in the past few weeks we have prototyped a CSS implementation of rendersubtree, in response to partner feedback and some feedback from the previous F2F that this would be more ergonomic for developers.

But if rendersubtree is in CSS, you can't observe it via CSS or else there would be a circularity of CSS depending on CSS.

Due to the UA activation/async-rendering feature of rendersubtree, the value may change outside of developer control, and therefore we need a way to have placeholder sizing constraints apply only when the content is invisible; this is where the restriction to contain:size came from, since contain:size detaches subtree layout constraints from affecting outer layout.

Here are two ideas:

1. Augment containment syntax, via something like: contain: size 300px 400px
2. Choose a new name, such as: contain-size-sizing: 300px 400px (I didn't give this much thought, maybe there is a good name?)

[tabatkins]

I don't like adding this to the contain property directly; it feels like it's building too much orthogonal functionality into the property.

But I don't have a good name for the independent property either. ^_^

[vmpstr]

1. Augment containment syntax, via something like: contain: size 300px 400px

I don't really like this, since it doesn't quite solve the case described. IOW, presumably that would also apply size containment and put in this size. What we would really like is to specify which size to apply if containment is specified, without specifying the containment itself.

2. Choose a new name, such as: contain-size-sizing: 300px 400px (I didn't give this much thought, maybe there is a good name?)

Yeah I think we need something like this, but I'm not really good at naming this. size-containment-placeholder-size or something like that is my best idea, but it feels a bit verbose.

[cbiesinger]

This change also makes me more comfortable with implementing aspect-ratio, because otherwise that was fairly close to intrinsic-size (in that aspect ratio could just be inferred from intrinsic-size, if set)

[emilio]

WICG/intrinsicsize-attribute#16

Hm? How is that link related to this?

[fantasai]

We already have a similar "when things are loaded, use the real size, in the meantime use this explicit value" concept for aspect-ratio. It would make sense to be consistent in how we express that concept.

I really don't want to have separate properties for "explicit size that always wins" and "explicit size that's only used under certain conditions". It gets confusing from an author-learning perspective to have too many properties that are doing nearly identical things (in this case, identical things taking effect under slightly different conditions). And it's also not great from a cascading perspective to do that either.

[vmpstr]

I really don't want to have separate properties for "explicit size that always wins" and "explicit size that's only used under certain conditions".

I kind of think of size containment as already putting in a 0x0 for its intrinsic size (which of course only applies if contain: size is present). This is due to the fact that it has to lay out as if it had no children, and also replaced elements get intrinsic width and height as 0. This proposed property would just allow the developer to specify something other than 0x0 under the same conditions.

In terms of the cascade or what wins when, I would imagine the same rules as size containment apply. In other words, if size containment is specified then instead of laying out as if empty, the element lays out as if it has a single child box of specified size or something along those lines.

Edit: That single child case might be more problematic with layouts like grid that position their elements in particular cells, so I mean that as an example for regular block layout, not as final spec for everything

[chrishtr]

We already have a similar "when things are loaded, use the real size, in the meantime use this explicit value" concept for aspect-ratio. It would make sense to be consistent in how we express that concept.

I agree about things being consistent in this regard. Could you link to the spec text you're referring to so I can study it?

[chrishtr]

Hi @fantasai, ping on above question..

[fantasai]

@chrishtr Spec is at https://drafts.csswg.org/css-sizing-4/#aspect-ratio but it hasn't incorporated the "use actual value, fall back to this other value" behavior yet. So concern is less "let's be consistent with this existing thing" and more "let's make sure we design these two things together so they end up consistent".

[css-meeting-bot]

The CSS Working Group just discussed [css-sizing] intrinsic-size lost the thread :(.

The full IRC log of that discussion

<dael> Topic: [css-sizing] intrinsic-size lost the thread :(
<dael> github: https://github.com//issues/4531
<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
<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.
<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
<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
<dael> TabAtkins: Want to revert to it changing way contain size works
<dael> fantasai: Questions: display locking there's a magic state no reflected in attributes and in some there's contain:size or in all?
<dael> TabAtkins: In some of the states
<dael> fantasai: And contain:size has to be removed by author?
<dael> TabAtkins: Done automatically
<dael> fantasai: If there's an intrinsic size the UA doesn't know to remove or not
<dael> TabAtkins: yes, exactly
<dael> fantasai: Okay, I think I understand what's happening
<astearns> s/contain size/contain:size/
<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
<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.
<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
<dael> fremy: That's what I was going ot suggest. Say if this is all the time or only sometimes
<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
<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
<dael> fantasai: Gotcha
<dael> TabAtkins: florian disagreed if that should mechanically happen, though
<dael> fantasai: I think dbaron has brought up case of setting intrinsic size more explicitly, but I don't remember them
<dael> dbaron: I don't either
<dael> chrishtr: As part of TAG rview discovered it's not clear [missed]. DIdn't realize until I did more research
<dael> chrishtr: Most compelling is a detached layout mode and you don't include until it's detached.
<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
<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
<dael> TabAtkins: flexbox algo is scrollers get too big
<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
<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
<dbaron> +1 to having a more specific name if it has a more specific behavior
<fantasai> +1
<dael> Rossen_: Agree. Intrinsic-size as a concept is something explict.
<dael> Rossen_: Other than the name is this still a property we want to persue
<fantasai> Would suggest 'contain-size', sharing a prefix with 'contain' and suffix with 'size' property
<fantasai> s/size/-size/
<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
<fantasai> +1 to florian
<dael> fremy: I recalled mine but thinking more they were all better with custom layouts
<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
<dael> chrishtr: If we have more use cases and a general property we would still need a property to switch
<dael> florian: Yes, we want a single property with mode switch if there are other cases. If not special property
<dbaron> (to apply only when `contain:size` is present
<dael> chrishtr: I hope we start witht hat part
<dael> fantasai: I agree with florian desc of where we are
<dael> TabAtkins: Can we timebox it?
<dael> TabAtkins: Sooner is better, we're trying to finish in our impl. It's not must right now, but sooner
<dael> fantasai: Timebox of next week or first week of Jan?
<dbaron> q+ to mention other use cases for intrinsic size property
<dael> TabAtkins: If dbaron had use cases before a week should be enough to remember. Presumably we've discussed in the past.
<dael> florian: Difference between next week and early Jan isn't much unless you're trying to ship before Xmas
<dael> fremy: And have to keep in mind people are in vacation
<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
<dbaron> s/min-size/min-intrinsic/
<dael> AmeliaBR: Sounds like people might want to skim previous issues. Initial proposal had many variations. Different use cases had different situations
<dael> TabAtkins: Also intregued that both of dbaron use cases are 0 or not, not about setting a non-0 value
<AmeliaBR> Previous discussion where many possible use cases were brought up: https://github.com//issues/4229#issuecomment-531615054
<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.
<AmeliaBR> s/many variations/many variations, such as whether this applied as a minimum or maximum or both/
<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.
<iank_> e.g. https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=7541
<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
<dael> florian: This isn't clearly articulated; I'd appriciate more than a week
<dael> chrishtr: Let's wait until 1st week in Jan to write use cases and decide then
<dael> fantasai: Start a new thread on use cases rather than follow up on this issue?
<dael> chrishtr: Sure. I'll make a new issue and link to it from the existing
<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

[fantasai]

Created an issue to collect use cases for explicit intrinsic sizes at #4585

[chrishtr]

Per decisions made at last month's CSSWG, and given there were no use cases raised for intrinsic sizing, we should go with a specification of a new CSS property that applies only when contain:size is also specified. The new CSS property allows choosing a value other than 0x0 as the placeholder sizing of the subtree.

I suggest content-placeholder-size as the name of the property.

This is almost the same as the original name proposed at TPAC (see issue #4229) of content-size, but more clearly indicates that it has to do with sizing when the layout of the subtree is not known/skipped.

[chrishtr]

Also, since the setting much simpler now we should remove all the extra keywords, and only support fixed lengths (no percentages/keywords), since there is nothing to be percentage relative to. Also, the initial value should be 0, to correspond to the meaning of contain:size without specifying any intrinsic sizing.

(Ref to current spec before edits: https://drafts.csswg.org/css-sizing-4/#intrinsic-size-override)

[css-meeting-bot]

The CSS Working Group just discussed [css-sizing] intrinsic-size lost the thread.

The full IRC log of that discussion

<dael> Topic: [css-sizing] intrinsic-size lost the thread
<dael> github: https://github.com//issues/4531
<dael> TabAtkins: Given there's no additional suggestions our current proposal is revert back to a property with a default size for a contain:size element. Proposed name is content-placeholder-size. Happy to bikeshed. Makes it clear that it's a special case
<dael> TabAtkins: Objections or additional ideas on use cases with expanded form of content size please say so.
<dael> fantasai: I think if specific to contain it should be prefixed with contain.
<dael> TabAtkins: contain-placeholder is fine
<dael> myles: Placeholder a term of art for inputs?
<dael> fantasai: It's used for placeholder in inputs. I'm hesitant to use the word
<dael> TabAtkins: Where is placeholder in css?
<fantasai> ::placeholder and :placeholder-shown
<dael> dbaron: pseudo element and pseudo class
<dael> TabAtkins: Yeah, forgot about that one
<dbaron> ::placeholder and :placeholder-shown, I think
<dael> fantasai: contain-size unless you've got a good word in the middle
<dael> astearns: contain-initial-size
<dael> TabAtkins: initial or default seems reasonable
<dael> fantasai: If it's a flex item stretched it won't size to that size. contain-content-size maybe. Initial may not make sense
<dbaron> (it wasn't minuted, but I did say above that I wasn't aware of https://github.com//issues/4585 until it was mentioned today)
<dael> fantasai: I would prefer a word that clarifies in the middle
<dael> TabAtkins: contain-size sure
<dael> astearns: issues with contain-size?
<dael> astearns: Prop: Change the current contain:size to contain-size as its own property
<fantasai> dbaron, you could have posted suggestions into the original issue? But either way if you come up with something to add I'm sure we can reconsider.
<dael> chrishtr: it's a param to contain:size
<dael> chrishtr: contain-size is a param to contain:size that indicates non-zero
<dael> ??: Rename intrinsit-size to contain-size
<cbiesinger> s/??/cbiesinger/
<cbiesinger> s/intrinsit/intrinsic/
<dael> chrishtr: If contain:size is on an eleemnt we look to see if contain-size is set and then set placeholder sizing
<dael> TabAtkins: Contain-size is none or lengths
<dael> fantasai: contain-intrinsic-size?
<dael> astearns: Prop: Add contain-intrinsic-size property with an initial value of 0 that takes a pair of length
<dael> cbiesinger: Remain intrinisc-size to contain-intrinisic-size
<cbiesinger> s/remain/rename/
<dael> chrishtr: And conditioned on contain:size being present
<dael> astearns: Prop: Have a contain-intrinsic-size property
<dael> dbaron: I missed the request for examples. I'd like to try and do that next week and get examples in the past
<dael> fantasai: Let's say if we do in this direction we'll do this and waiting on dbaron examples
<tantek> is confused trying to follow this and can't offer a specific opinion. :/ examples would help.
<dael> florian: We mentioned initial value. For contain-size it's 0 for non-replaces which isn't always 0. Does initial value =0 and adds size or is it auto?
<dael> TabAtkins: Initial value of none. If you spec size it'll intercept
<dael> florian: Initial size of 0 it replaces?
<dael> TabAtkins: Yeah
<dael> astearns: TabAtkins can you commit to specing this out so we can have all the details and dbaron examples and see if it fits?
<dael> TabAtkins: Yes
<dael> fantasai: TabAtkins maybe spec both and we'll delete the one we don't select
<dael> astearns: Let's get proposal and examples together and we'll look next week

[cbiesinger]

@vmpstr and I just discussed this update in person:

• There should an initial value "none" different from 0
• It would be nice if the spec had a non-normative note explaining this, something like:

'none' is different from 0 because some layout modes can have a nonzero intrinsic size even without contents; for example columns can have a column gap specified, or grids can have nonzero grid tracks. If an explicit contain-intrinsic-size: 0 is specified in such a case, and the box is in a shrink-to-fit context, the box will be laid out just like a zero width were specified explicitly (e.g. width: 0)

[cbiesinger]

@frivoal see also my comment above

[frivoal]

@cbiesinger I agree we need the none value as you described. That said, depending on how we write its normative description, we might not need the note.

[css-meeting-bot]

The CSS Working Group just discussed intrinsic-size, and agreed to the following:

• RESOLVED: add a property called contain-intrinsic-size

The full IRC log of that discussion

<TabAtkins> Topic: intrinsic-size
<astearns> github: https://github.com//issues/4531
<emilio> ScribeNick: emilio
<emilio> chrishtr: in december we discussed and concluded that if we couldn't find other use cases we should add a property specific to the size-contained case
<emilio> ... since then dbaron has come up with some use-cases related to scrolling
<emilio> ... so now the question is what to do with this information
<emilio> ... whether adding two separate properties (which I'd recommend), or just one
<emilio> dbaron: I would've preferred one property, but if you found a decent name for the contain-specific one I'm ok with two
<emilio> astearns: what's the name of that?
<emilio> chrishtr: contain-intrinsic-size, credit to fantasai
<fantasai> If there are two properties, what's the interaction?
<emilio> TabAtkins: none or two lengths
<emilio> (or one)
<fantasai> should be a shorthand for the various sizing longhands
<emilio> TabAtkins: re. interaction: This only interact iff the element is size-contained
<fantasai> right, but that could happen
<emilio> ... so I think the most consistent behavior would be that the contain-specific one wins, as contain: size already prevents a lot of other sizing-related calculations
<fantasai> it doesn't prevent 'width' and 'height' from doing things
<emilio> astearns: fantasai also asked about it being a shorthand for the sizing props
<fantasai> so I'm not convinced about that
<emilio> TabAtkins: definitely disagree with it being a shorthand
<fantasai> e.g. contain-intrinsic-width
<TabAtkins> specifically, since our use-cases want the "general" to do things like cause scrollbars, which is similar to it having a big child, and contain:size alreayd ignores children, I think it's most consistent to have contain:size cause that to be ignored.
<emilio> TabAtkins: ah, ok, sure...
<fantasai> ?
<emilio> fantasai: (about the shorthand thing)
<smfr> do we need contain-intrinsic-aspect-ratio too?
<emilio> dbaron: do we also want logical versions?
<fantasai> smfr, no
<emilio> TabAtkins: I guess so, we'd all all of them
<fantasai> smfr, aspect-ratio already exists, why would we need contain-intrinsic-aspect-ratio?
<emilio> chrishtr: what happens if you only specify one of them? The current proposal doesn't allow that
<emilio> Rossen: auto?
<emilio> TabAtkins: there's no auto
<fantasai> chrishtr, same in that dimension as if you didn't specify the property?
<emilio> TabAtkins: given we need 4 longhands and such, can we skip it for now and see if it's necessary later?
<emilio> chrishtr: I don't see downsides with that
<fantasai> as long as the shorthand is consistent with the size shorthand ...
<fantasai> which we still don't have
<emilio> TabAtkins: we have good behavior turning something into a longhand later
<emilio> into a shorthand*
<fantasai> There's also an issue around what order the values go in, if there are two of them
<emilio> astearns: issues, concerns?
<TabAtkins> fantasai, yes, I imagine it'll be consistent.
<fantasai> @page { size: width height; } is currently the order there
<TabAtkins> fantasai: and yes indeed, we'll discuss which order to put the things in
<fantasai> which puts us inconsistent with grid shorthand and alignment ...
<emilio> RESOLVED: add a property called contain-intrinsic-size
<fantasai> which is a mess, because we didn't listen to bradkemper
<chris_> rrsagent, here
<RRSAgent> See https://www.w3.org/2020/01/24-css-irc#T16-55-26
<emilio> TabAtkins: we should try to decide the order between the values
<emilio> ... I think we should do block/inline
<fantasai> I think we should do width/height
<fantasai> because all of our shorthands are physical
<fantasai> because 'size' is already physical in paged media
<fantasai> and it's width/height
<fantasai> and physical shorthands with two axes are width/height
<fantasai> not height/width
<emilio> emilio: I think I agree with fantasai
<emilio> TabAtkins: we're going to be inconsistent with some amount of properties regardless
<emilio> ... because we have examples of both
<fantasai> Not really
<fantasai> Everything with physical longhands is consistent
<fantasai> everything that doesn't is consistent
<fantasai> the two sets are inconsistent
<fantasai> and size has physical longhands
<fantasai> so it goes in the first category
<emilio> TabAtkins: we can defer this to the next meeting and discuss in the issue with now
<emilio> emilio: should we discuss now the other use cases that dbaron brought?
<emilio> TabAtkins: if dbaron wants, sure
<fantasai> My 2nd worst mistake in CSS is definitely the ordering of the grid shorthand
<emilio> dbaron: not sure we need to right now
<emilio> TabAtkins: ok, we mostly wanted to see whether these concepts were separable

[astearns]

Agenda+ to determine the order of the values

[css-meeting-bot]

The CSS Working Group just discussed [css-sizing] determine order of intrinsic-size values.

The full IRC log of that discussion

<dael> Topic: [css-sizing] determine order of intrinsic-size values
<dael> github: https://github.com//issues/4531#issuecomment-578214370
<dael> astearns: TabAtkins wanted to defer but suggested to start so we can get some discussion in the issue
<dael> Rossen_: In addition to existing resolution?
<dael> astearns: Yes
<dael> fantasai: Order of values ties into broader CSS problem with ordering of values. Got a solid set of ording for box sides. For here it's 2 value one per axis.
<dael> fantasai: We have 2 sets of conventions in place. We have logic properties like grid shorthand and scroll-snap-align which we went vertical axis first. y first x second. Older physical are x first y second.
<dael> fantasai: Question is which convention for size. Block then inline or width then height or something different?
<dael> fantasai: That's the basic question and not very simple. There is size for page that is physical. Width then height. basckground-size is also phsycial. I think we should do width followed by height.
<dael> cbiesinger: Agree. Two length version of margins has height first
<dael> fantasai: That's why when went logical we did height first. Reviewing I think that's a mistake but it's too late to fix. Physical are width height and logical are block inline.
<dael> Rossen_: Let's not repeat mistake. Let's keep width and height
<dael> florian: Agree
<dael> astearns: Fairly convincing to be consistent with other size properties.
<dael> s/florian/??
<dael> astearns: Height and width was suggested last time we talked
<dael> cbiesinger: Wasn't it block and inline suggested?
<dael> astearns: Fair, yeah.
<dael> astearns: Can anyone capture argument for block then inline?
<dael> fantasai: Main argument is we're moving toward logical coordinates in syntax design. Why grid and flex and scrollsnap are logical. But there's a large list of phsycial and sizing and boxes are in that category. This is a size property it should prob slot into that grouping.
<dael> fantasai: That's what I feel. But we can argue we don't have a size shorthand so we could make it be logical.
<dael> fantasai: Problem is we have background-size and size in paged media. We don't have a shorthand for box-size but we have sizes elsewhere in CSS.
<dael> fantasai: Nice to shift ot logical but I think more inconsistent
<dael> fantasai: Once we figure out how to switch shorthand between logical and physical we can switch this too. That's an open issue on CSS Logical
<dael> fantasai: THis issue seems minor but ties into a systemic problem that's not solved
<dael> cbiesinger: Shouldn't block property on solving systemic issue
<dael> astearns: People on call are in consensus on width and height. We have an impl that agrees and wants to get it implemented.
<dael> astearns: COuld resolve knowing people want to revisit. Should we resolve or wait?
<dael> Rossen_: Resolve. We can always revisit. We've spent 10 minutes and are fairly convinced
<dael> fantasai: Anyone on the call with a different opinion?
<TabAtkins> I'm unhappy with this being inconsistent with the existing two-value logicla properties. Can we just record this as a conversation and not resolve yet?
<dael> astearns: Only TabAtkins who is reading IRC. Not sure if Chris H had a strong opinion. Don't think he did
<dael> astearns: [Read TabAtkins ]
<dael> astearns: Let's take to the issue for another week and resolve next week
<fantasai> TabAtkins, yeah, but if we make it logical, it'd end up being inconsistent with background-size and page-size

[cbiesinger]

We may also want to discuss what the initial value should be (auto/none)

[tabatkins]

Posting this for the aid of the telcon discussion.

I did a quick rundown of all the properties in CSS, finding those that take a pair of size values and whether they're physical or logical:

physical

• aspect-ratio
• background-*
• box-shadow
• device-aspect-ratio
• fill-*
• stroke-*
• mask-*
• object-position
• overflow
• overscroll-behavior
• perspective-origin
• transform-*

logical

• gap
• grid-*
• place-*
• scroll-snap-*

So the pattern is fairly clear: things @fantasai and I have worked on in the past few years are logical, everything else (both legacy, and newer things worked on by people other than us) are physical.

I'm sad about the overall inconsistency, but I don't think this is easily resolveable. We have to bite this bullet one way or the other, and I guess I'm fine with deferring to the larger numbers and history behind "default to physical". We'll just have a couple of specs that are inconsistent.

[css-meeting-bot]

The CSS Working Group just discussed [css-sizing] intrinsic-size lost the thread, and agreed to the following:

• RESOLVED: Syntax order is physical for intrinsic-size
• RESOLVED: switching initial keyword from 'none' to 'auto'

The full IRC log of that discussion

<dael> Topic: [css-sizing] intrinsic-size lost the thread
<dael> github: https://github.com//issues/4531
<dael> TabAtkins: Weither intrinsic size should order sizes in logical or physical. I objected to phsyical ordering on idea that we've been doing logical lately. fantasai leaned physical. I went through list of css properties that take 2 lengths and categorized
<TabAtkins> https://github.com//issues/4531#issuecomment-585321048
<dael> TabAtkins: List ^
<dael> TabAtkins: Pattern is clear. There are 4 properties that are logical and they're all spec fantasai and I have done in last few years. All others are phsycial. More physical then logical
<dael> TabAtkins: Unhappy about overall split but if fantasai is thinking we should stick with physical I think data agrees and we should switch to phsycial where we can
<dael> fantasai: Agree with conclusion, though not all details leading to it. Usefult o switch to logical for layout. Block first was a mistake. I think size property close align to properties that bg size that are phsycial. All box sizing is phsycial. So this should fall into that category
<dael> TabAtkins: List is split between offset and sizes. Properties that are bg like agree so let's do it. Size is physical.
<dael> Rossen_: Last time we called for objections you were the only one. Objections now?
<dael> AmeliaBR: What's the resolution?
<dael> TabAtkins: Syntax order is physical for intrinsic size
<dael> Rossen_: width and height
<dael> RESOLVED: Syntax order is physical for intrinsic-size
<dael> cbiesinger: One other thing, I think we need intiial value as a keyword that is auto. Thoughts on that?
<dael> florian: Agree
<dael> fantasai: Why need?
<dael> cbiesinger: Because 0 isn't always the default. If have flexbox with gaps initial value would take gaps into account so 0 can't be initial
<dael> fantasai: How if don't know number of items?
<dael> florian: hard coded quantity of columns
<dael> TabAtkins: Initial value that's a keyword is decided with examples. Question is if keyword name should be auto or none. I think spec is none but fine to switch to auto
<dael> AmeliaBR: Agree auto is better b/c none easy to confuse
<dael> cbiesinger: Agree
<fantasai> +1 to Amelia's reasoning
<dael> Rossen_: Objections to switching initial keyword from 'none' to 'auto'?
<AmeliaBR> s/to confuse/to confuse with 0/
<dael> RESOLVED: switching initial keyword from 'none' to 'auto'

[tabatkins]

@cbiesinger @chrishtr All right, 'contain-intrinsic-size' is committed at https://drafts.csswg.org/css-sizing-4/#intrinsic-size-override; would y'all mind reviewing?

In particular, check that the definition of "explicit intrinsic inner size" matches what y'all think it should be: "pretend you've done layout on your contents and got back these sizes as the result". I think that hits exactly on the behavior we want.