[css-overflow-3] 'overflow' 2-value syntax is in wrong order

[tabatkins]

Currently the 'overflow' 2-value syntax is parsed to be horizontal-vertical (to be precise, the first value maps to overflow-x, the second to overflow-y).

When possible, for any new 2-axis properties we're trying to map them to the logical longhands instead, so this is currently wrong. As well, for horizontal writing modes, the x/y ordering is opposite the logical ordering we've settled on, which is block/inline (to match what 4-value syntaxes do when you specify only two values).

As the two-value syntax is new, this should still be fixable - two values should map to overflow in the block and inline axises, in that order.

[fantasai]

It's especially important to keep scroll-snap-align and overflow consistent since they will often be used together.

[css-meeting-bot]

The Working Group just discussed 'overflow' 2-value syntax is in wrong order, and agreed to the following:

• RESOLVED: Match the block followed by inline ordering of 2 value pairs for the overflow-x and overflow-y shorthand to be consistent

The full IRC log of that discussion

<dael> Topic: 'overflow' 2-value syntax is in wrong order
<dael> github: https://github.com//issues/2988
<dael> Rossen_: This is value ordering and we try to do x then y, but all logical properties are block and then inline. What is the proposal here?
<dael> fantasai: Proposal is to use the logical order, block then inline. Overflow prop do have logicial shorthands. Also pretty important to make sure ordering matches with scroll-snap-align. Having them opposite is fairly confusing
<dael> Rossen_: This would apply to...a handful or properties
<dael> fantasai: Just overflow shorthand property. I don't know of any others, though they might exist
<dael> Rossen_: Do we keep consistency for position properties?
<dbaron> how many engines implement 2-value overflow? Gecko does.
<dael> fantasai: Once in logical coord are block first inline second. All the 4 values are block first inline second
<dael> fantasai: Logicial 2 value coord is mainly background-position and that's a rough WD with logical positioning values
<dael> fantasai: Physical are x then y
<dael> dbaron: How many engines impl?
<dael> fantasai: Just mozilla b/c we jsut added in April
<dael> Rossen_: We've had overflow-x and -y since IE 6
<dael> fantasai: We won't change that.
<bradk> When did we resolve on doing block first? That seems wrong to me.
<rego> Chromium has it in M68 I believe
<dael> Rossen_: Sorry, though you were talking about long hand
<rego> https://www.chromestatus.com/feature/5090725653905408
<dael> Rossen_: So that means compat risk is fairly small
<dael> fantasai: Yeah
<fantasai> bradk, awhile back ... when we were working on css-grid
<dael> Rossen_: dbaron would you guys be okay with this?
<dael> dbaron: Yeah
<dael> Rossen_: Prop: Match the block followed by inline ordering of 2 value pairs for the overflow-x and overflow-y shorthand to be consistent
<dael> Rossen_: Objections?
<fantasai> bradk, I'm not entirely convinced it was a good idea, there were good arguments in both directions... but we should be consistent here
<dael> RESOLVED: Match the block followed by inline ordering of 2 value pairs for the overflow-x and overflow-y shorthand to be consistent

[dbaron]

I filed Mozilla bug 1481866 to change this.

[emilio]

Blink also implemented (https://bugs.chromium.org/p/chromium/issues/detail?id=833105 is fixed), so I filed https://bugs.chromium.org/p/chromium/issues/detail?id=872356 for them.

[bradkemper]

Currently, the 2-axis starts-with-horizontal rule, and the up-to-four-compass-directions starts-with-top rule is understandable and mostly internally consistent. Having some values that follow those rules and others that don’t is going to be horribly confusing and hard to remember. I should have said so in the call.

[tabatkins]

Right, but it'll be confusing no matter what, as we have several properties already doing 2-axis in the logical order. The physical order is more or less just a legacy mistake at this point.

[frivoal]

I was about to patch the spec, but now I'm confused: is the shorthand supposed to be overflow-block then overflow-inline (logical longhands), or overflow-y then overflow-x (physical longhands)? The resolution sounds like the former (especially since @fantasai invokes consistency with scroll-snap-align as a rationale), but as far as I can tell the code change by Mozilla and the request in Chrome's bug tracker to match the resolution are the later.

It seems to me that they're wrong, but I wasn't there during the call, so I may be missing something. Which is it?

[Loirooriol]

All shorthands that don't contain block or inline in their name seem to correspond to physical longhands, even if they are new like inset. But probably the same can be said about the order (scroll-snap-align is not a shorthand).

[frivoal]

that seems to contradict what @tabatkins and @fantasai were saying thought.

for any new 2-axis properties we're trying to map them to the logical longhands

important to keep scroll-snap-align and overflow consistent

[tabatkins]

Yes, our entire argument, and the resolution, was to have the order be "block, then inline", not "x, then y". (The resolution is... confusingly written, since it refers to "the overflow-x and overflow-y shorthand" rather than... the "overflow" property, which predates either.

All shorthands that don't contain block or inline in their name seem to correspond to physical shorthands

Incorrect (see any of the Grid properties). And doesn't make a ton of sense, since a property that applies to both axises wouldn't specialize its name with "block" or "inline" - that's for sub-properties that are doing a single axis.

[frivoal]

Ok, so I'll fix the spec per the resolution (i.e. in terms of logical directions), and have pinged Chrome and Mozilla in their relevant bugs about the misunderstanding.

[emilio]

I think that's way riskier than what we interpreted. For example, code like this will stop working:

  document.body.style.overflow = "hidden";
  document.body.style.overflowX // Will start returning "", but returned "hidden" up until now.

I'm not sure that's totally acceptable...