Re: [csswg-drafts] [css-sizing] intrinsic-size lost the thread 🙁 (#4531)

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'`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-sizing] intrinsic-size lost the thread<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/4531<br>
&lt;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<br>
&lt;TabAtkins> https://github.com/w3c/csswg-drafts/issues/4531#issuecomment-585321048<br>
&lt;dael> TabAtkins: List ^<br>
&lt;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<br>
&lt;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<br>
&lt;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<br>
&lt;dael> TabAtkins: List is split between offset and sizes. Properties that are bg like agree so let's do it. Size is physical.<br>
&lt;dael> Rossen_: Last time we called for objections you were the only one. Objections now?<br>
&lt;dael> AmeliaBR: What's the resolution?<br>
&lt;dael> TabAtkins: Syntax order is physical for intrinsic size<br>
&lt;dael> Rossen_: width and height<br>
&lt;dael> RESOLVED: Syntax order is physical for intrinsic-size<br>
&lt;dael> cbiesinger: One other thing, I think we need intiial value as a keyword that is auto. Thoughts on that?<br>
&lt;dael> florian: Agree<br>
&lt;dael> fantasai: Why need?<br>
&lt;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<br>
&lt;dael> fantasai: How if don't know number of items?<br>
&lt;dael> florian: hard coded quantity of columns<br>
&lt;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<br>
&lt;dael> AmeliaBR: Agree auto is better b/c none easy to confuse<br>
&lt;dael> cbiesinger: Agree<br>
&lt;fantasai> +1 to Amelia's reasoning<br>
&lt;dael> Rossen_: Objections to switching initial keyword from 'none' to 'auto'?<br>
&lt;AmeliaBR> s/to confuse/to confuse with 0/<br>
&lt;dael> RESOLVED: switching initial keyword from 'none' to 'auto'<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-585331794 using your GitHub account

Received on Wednesday, 12 February 2020 17:50:39 UTC