Adding cnardi@ on CC, who implemented the two values support in  issue #833105 

David is updating the tests in the Firefox bug linked above, which should make this change much more straight-forward :)

FWIW, the Firefox bug landed in nightly(63) builds overnight, and appears to be functioning correctly. Per David, no current plans to uplift to beta/dev(62) as current web exposure is minimal. Overflow shorthand is currently web-unsafe in release(61), but safe in esr(60) where the shorthand is not implemented at all.

Sure would be nice for this chromium bug to be fixed in a timely manner, so that it won't extend this web-unsafe timeframe.

This is stated incorrectly. The CSSWG's resolution is not to change from x/y to y/x, but from x/y to block/inline. In other words, not only swap the order, but also tie to to logical rather than physical directions.

I'm reverting the swap that we made in Firefox in https://bugzilla.mozilla.org/show_bug.cgi?id=1492567, since the behavior the WG wants is way more subtle.

tabatkins@ brought this to my attention. I wanted to understand the web-compat impact better so I ran a query [1] on httparchive to see usage of overflow longhand. [2] is the result for desktop request body data that I put in a spreadsheet to make analysis easier. 

I have not fully analyzed the data but here is some summary:

- 2789 entries matching (total pages: 2789/1,268,373) so this is ~ 0.2% of all pages in the archive which is larger than I expected.
- Below [3] is the top 85% of all matches combined per the request domain. Of these about half use the same value for the property so switching the order does not affect them.
- There is a large amount of those coming from one site vk.com (e.g., https://vk.com/css/al/notifier.css?26331469779) perhaps we can take a closer look and see if it actually breaks if we switch the order and do some reach out.


[2] https://docs.google.com/spreadsheets/d/16D8bDLyjH0FwJ-Jb0fgWvwanuFmPd1Lsg7tOuMX6SSY/edit?usp=sharing
[3] 

Domain	Value	Percentage of total	Breaks
https://vk.com/	overflow:auto hidden;	34.72%	TRUE
http://blog.hatena.ne.jp/	overflow:ellipsis ellipsis;	24.10%	FALSE
https://blog.hatena.ne.jp/	overflow:ellipsis ellipsis;	7.78%	FALSE
https://i.hh.ru/	overflow:hidden auto;	6.46%	TRUE
https://cdn.smugmug.com/	overflow:hidden auto;	4.02%	TRUE
http://pos.baidu.com/	"overflow:hi
dden;"	2.04%	FALSE
https://d29f71cuc8ityh.cloudfront.net/	overflow:hidden scroll;	1.29%	TRUE
https://pos.baidu.com/	"overflow:hi
dden;"	1.00%	FALSE
https://i.hh.ua/	overflow:hidden auto;	0.82%	TRUE
https://static.topixcdn.com/	overflow: hidden scroll;	0.65%	TRUE
https://i.jobs.tut.by/	overflow:hidden auto;	0.39%	TRUE
https://i.hh.kz/	overflow:hidden auto;	0.36%	TRUE
http://shtt.shuqw.com/	"overflow:hi
dden;"	0.25%	FALSE
https://fzb02.qiushibaike.com/	"overflow:hi
dden;"	0.22%	FALSE
http://truelife.vn/	overflow: hidden hidden;	0.22%	FALSE
https://www.etsy.com/	overflow:overlay visible;	0.18%	TRUE
https://www.deviantart.com/	overflow: auto none;	0.11%	FALSE
 	overflow:auto none;	0.07%	FALSE
http://arquidiocesebh.org.br/	overflow:scrol li;	0.18%	FALSE
https://suzukipitstopplus.com/	overflow: hidden hidden;	0.14%	FALSE
https://s.usaa.com/	overflow:visible 9;	0.14%	FALSE
		85.15%	0.4888809182


[1] Query
SELECT 
  bodies.page, REGEXP_EXTRACT(bodies.body, r'(overflow:\s*\w+?\s+\w+?\s*;)') as match, bodies.url 
FROM `httparchive.response_bodies.2018_10_01_desktop` AS bodies
WHERE 
 REGEXP_CONTAINS(bodies.body, r'(overflow:\s*\w+?\s+\w+?\s*;)')

To be clear this is not only about swapping the values, they also need to expand to logical properties.

re #8:  Basically I am assuming if both values are the same the switching from x/y to block/inline does not break anything and if they are not then we that we are breaking compat. I think with this interpretation we are getting an upper-bound** on potential breakage. 


** It is an upper-bound because the latter case may not break if the block is in fact x but I am assuming it breaks anyways.

Yeah, if they're the same there's no impact.

If they're different it's only a change *if* the element is in a horizontal writing mode. (That's likely most, of course.)

Perhaps we can ask Microsoft to break out the stats: how often is the overflow shorthand used with 2 distinct keywords?

Here is Microsoft data on this: https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/overflow/

Unfortunately their crawl data is fairly old (November 22nd, 2017) and dates before the property was implemented in Chrome (and as far as I can tell in firefox). So it does not show any two value usage at all.

I expanded my HttpArchive analysis a bit and included mobile data from the same date. I have added the query result added to the same spreadsheet and here is the summary.

 - Total count of pages that use two value overflow: 3,880 matches. This represents 0.15% of total pages (1,268,369 + 1,260,674).
 - I looked at the largest buckets (compromising 85% of total) and of these about 65% use two different value and may break after change. But the good news is that most of that breakage (50%) is contributed by a single large site usage (vk.com).
 - So my estimate of breakage is 0.1 % of all pages if you include vk.com, or 0.02% of all pages if you exclude vk.com


So the backward breakage seems within the acceptable range specially if we make outreach to vk.com so they change before we ship this.

Notes:
 - We still should at the long tail as well to see how those are affected.
 - I am assuming every usage breaks but this is conservative. In many cases one value is 'auto' so it may not matter, or the css rule may not actually be in use.
 - I am assuming each response body is a unique page but that is conservative.
 - My regex is also catching 'text-overflow' but I have eliminated those as far as I can tell since they have invalid values e.g. ellipsis.
   

bokan@ can you please triage this to someone to take a closer look at my web-compat analysis and perhaps make the change if they agree with the assessment. 

It looks like we don't yet implement overflow-block or overflow-inline, is the idea (for now) that we'd determine whether to set to x or y based on the current writing mode? If so, that's a trivial change I could make sometime next week.

If we want to implement overflow-block and overflow-inline at the same time, that's a larger change that I think belongs with the style team.

I agree with your compat assessment, it should be safe assuming we can reach out to the major existing users and get them to update.

I believe it is the former i.e., just change how the 2-value overflow is parsed. So that it is interpreted logically (as opposed to physically) and then with [block, inline] order instead of [x, y]. So the change is % taking care of the compat issue.

tabatkins@ please correct me if I am wrong.