Re: [csswg-drafts] [css-overflow] Let 'overflow' accept two values

The Working Group just discussed `Let 'overflow' accept two values`, and agreed to the following resolutions:

* `RESOLVED: Allow 2 values on the overflow property in physical x/y order in any existing values.`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Let 'overflow' accept two values<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/2484<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/2484<br>
&lt;dael> Oriel: It only lets you set overflow-x and overflow-y. It would be more convenient if it accepted two values. Then there was the question is the order should be physical or logical. As an example background-position is x and y. It will prserve physical order. There's another issue looking to switch longhand and shorthand into phsycial order.<br>
&lt;dael> florian: Other is issue #1282 which discussed adding logical keyword to all places currently phsycial.<br>
&lt;dael> astearns: Separate from that switch, do we let overflow accept 2 values?<br>
&lt;dael> astearns: Concern about changing this?<br>
&lt;dael> astearns: Weird mistyped decalrations may now have an effect?<br>
&lt;dael> florian: I suggest we presume that's rare and if it's a problem we raise it<br>
&lt;dael> florian: A more consistant system where they all have shorthands and they're physical.<br>
&lt;dael> astearns: Prop: Allow overflow to have two value and for the ordering to be physical.<br>
&lt;dael> iank_: Which order?<br>
&lt;dael> emilio: x and y.<br>
&lt;dael> dbaron: Quesiton: There are sets of values transofrmed into other values. If x is visible and y is scroll we make scroll into auto. Should those combos be syntatically valid for shorthand?<br>
&lt;dael> myles: Related that this shorthand shouldn't allow new functionality<br>
&lt;dael> dbaron: Transofrmation would still happen. I'm thinking a it would be nice if it rejected but b it's not possible because serialization problem. Because then values could not serialize to short hand<br>
&lt;dael> emilio: Happens in a lot of places.<br>
&lt;dael> dbaron: I guess it's not really a serialization problem. Do we want the things that are not going to be valid in the end be parse errors?<br>
&lt;dael> emilio: I think it would be weird if spec shorthand would yield different results.<br>
&lt;dael> myles: You set the shorthand and it's rejected and that's different that if you set the 2 longhands.<br>
&lt;dael> florian: You have a minifier and it takes the 2 longs and puts them to short and that's a parse error.<br>
&lt;dael> astearns: I would prefer let ou set the shorthand to whatever and letting it transform.<br>
&lt;dael> florian: I don't think we gain by forbidding these.<br>
&lt;dael> fantasai: If you serialize out computed values it's valid.<br>
&lt;dael> florian: What do we gain by forbidding?<br>
&lt;dael> dbaron: Reject things that don't makes sense.<br>
&lt;dael> florian: Makes sense when you transform.<br>
&lt;dael> dbaron: CSS ties to reject things that don't make sense.<br>
&lt;dael> fantasai: Would be nice if a validation pool flagged this.<br>
&lt;dbaron> s/ties/tries/<br>
&lt;dbaron> s/pool/tool/<br>
&lt;dael> astearns: Computed value shows something changed.<br>
&lt;dael> fantasai: That always happens.<br>
&lt;dael> emilio: [missed] fantasai Tranforming em to pixel doesn't show you've got a problem in your style sheet.<br>
&lt;dael> astearns: I'm not certain having a transofmr apply implies there's a problem in your stylesheet.<br>
&lt;dael> fantasai: rachelandrew?<br>
&lt;dael> rachelandrew: I don't have an opinion.<br>
&lt;dael> florian: Stylesheet maintenece it's strange.<br>
&lt;dael> myles: Have we never encountered this?<br>
&lt;dael> fantasai: Almost for display but we made all combos invalid. We got rid of the longhand.<br>
&lt;dael> emilio: Outline style stuff which when you have hidden outline and the line-width becomes 0.<br>
&lt;dael> astearns: Anyone have a concern with allowing whatever combo we spec? Anyone object to taking what we get and stransform?<br>
&lt;dael> astearns: Prop: Allow 2 values on the overflow property in physical x/y order in any existing values.<br>
&lt;dael> myles: What a combo authors want with different keywords?<br>
&lt;dael> astearns: hidden x auto in y.<br>
&lt;dael> myles: So only one scroller.<br>
&lt;dael> astearns: People use overflow x and y in various situations and it' sjust that it would be nice to let them use the shorthand for both.<br>
&lt;dael> rune_: If you have visible overflow in x and y you get visible.<br>
&lt;dael> florian: Transformed to auto.<br>
&lt;dael> myles: Hiddena nd auto are okay.<br>
&lt;dael> astearns: Obj<br>
&lt;dael> RESOLVED: Allow 2 values on the overflow property in physical x/y order in any existing values.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2484#issuecomment-380153849 using your GitHub account

Received on Tuesday, 10 April 2018 15:58:29 UTC