[css-overflow] Let 'overflow' accept two values

[Loirooriol]

From #2000 (comment). overflow is a shorthand property of overflow-x and overflow-y, but it can only set them to the same value. It would be more convenient if the syntax was

[ visible | hidden | clip | scroll | auto ]{1,2}

The two values specify the behavior in the horizontal and vertical direction, respectively. If only one value is specified, the second value defaults to the same value. For example,

overflow: hidden auto; /* overflow-x: hidden; overflow-y: auto */

Then if #1282 introduces a flow-relative syntax for shorthands, it could apply to overflow, e.g.

overflow: hidden auto !relative; /* overflow-inline: hidden; overflow-block: auto */

[frivoal]

I don't know how urgent this is, but it seems reasonable to me.

[fantasai]

Agreed with @frivoal’s comment, but there's the additional question of: should the ordering be physical or logical?

[Loirooriol]

There is the precedent of e.g. background-position-x and background-position-y which are physically ordered in background-position. So if #1282 is going to add an easy way to switch shorthands to logical order, I prefer physical order for consistency.

[css-meeting-bot]

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.

The full IRC log of that discussion

<dael> Topic: Let 'overflow' accept two values
<fantasai> github: https://github.com//issues/2484
<dael> github: https://github.com//issues/2484
<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.
<dael> florian: Other is issue #1282 which discussed adding logical keyword to all places currently phsycial.
<dael> astearns: Separate from that switch, do we let overflow accept 2 values?
<dael> astearns: Concern about changing this?
<dael> astearns: Weird mistyped decalrations may now have an effect?
<dael> florian: I suggest we presume that's rare and if it's a problem we raise it
<dael> florian: A more consistant system where they all have shorthands and they're physical.
<dael> astearns: Prop: Allow overflow to have two value and for the ordering to be physical.
<dael> iank_: Which order?
<dael> emilio: x and y.
<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?
<dael> myles: Related that this shorthand shouldn't allow new functionality
<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
<dael> emilio: Happens in a lot of places.
<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?
<dael> emilio: I think it would be weird if spec shorthand would yield different results.
<dael> myles: You set the shorthand and it's rejected and that's different that if you set the 2 longhands.
<dael> florian: You have a minifier and it takes the 2 longs and puts them to short and that's a parse error.
<dael> astearns: I would prefer let ou set the shorthand to whatever and letting it transform.
<dael> florian: I don't think we gain by forbidding these.
<dael> fantasai: If you serialize out computed values it's valid.
<dael> florian: What do we gain by forbidding?
<dael> dbaron: Reject things that don't makes sense.
<dael> florian: Makes sense when you transform.
<dael> dbaron: CSS ties to reject things that don't make sense.
<dael> fantasai: Would be nice if a validation pool flagged this.
<dbaron> s/ties/tries/
<dbaron> s/pool/tool/
<dael> astearns: Computed value shows something changed.
<dael> fantasai: That always happens.
<dael> emilio: [missed] fantasai Tranforming em to pixel doesn't show you've got a problem in your style sheet.
<dael> astearns: I'm not certain having a transofmr apply implies there's a problem in your stylesheet.
<dael> fantasai: rachelandrew?
<dael> rachelandrew: I don't have an opinion.
<dael> florian: Stylesheet maintenece it's strange.
<dael> myles: Have we never encountered this?
<dael> fantasai: Almost for display but we made all combos invalid. We got rid of the longhand.
<dael> emilio: Outline style stuff which when you have hidden outline and the line-width becomes 0.
<dael> astearns: Anyone have a concern with allowing whatever combo we spec? Anyone object to taking what we get and stransform?
<dael> astearns: Prop: Allow 2 values on the overflow property in physical x/y order in any existing values.
<dael> myles: What a combo authors want with different keywords?
<dael> astearns: hidden x auto in y.
<dael> myles: So only one scroller.
<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.
<dael> rune_: If you have visible overflow in x and y you get visible.
<dael> florian: Transformed to auto.
<dael> myles: Hiddena nd auto are okay.
<dael> astearns: Obj
<dael> RESOLVED: Allow 2 values on the overflow property in physical x/y order in any existing values.

[CarterLi]

Just noticed this in chromestatus

Can this new syntax allows `overflow-x: visible; overflow-y: hidden'?

eg. overflow: visible hidden won't be interpreted as overflow: auto hidden.

I think the old behavior was a design flaw and made no sense. Now it's a chance to (partially) fix the mistake, because it's a new syntax and won't cause compatibility issues.

https://stackoverflow.com/questions/6421966/css-overflow-x-visible-and-overflow-y-hidden-causing-scrollbar-issue#answer-6433475

[emilio]

There's no change to the valid or invalid combinations of overflow-x/y.

[emilio]

The reason for it, is because the normal overflow-x / overflow-y adjustment doesn't (can't) happen at parse time, so there's no way to differentiate this syntax from the other at that stage unfortunately.

[fantasai]

I'm a bit concerned that this is not consistent with scroll-snap-align, which is also two-valued, and is much more closely related to overflow than background-position is.