Browser-compat-data: No support for margin-inline|block and padding-inline|block in Chrome

[fvsch]

Testing with Chrome 79 (stable):

Property | Status | Shown on MDN as
--- | --- | ---
margin-inline | Not supported | Supported (69)
margin-inline-start | Supported | Supported (69)
margin-inline-end | Supported | Supported (69)
margin-block | Not supported | Supported (69)
margin-block-start | Supported | Supported (69)
margin-block-end | Supported | Supported (69)
padding-inline | Not supported | Supported (69)
padding-inline-start | Supported | Supported (69)
padding-inline-end | Supported | Supported (69)
padding-block | Not supported | Supported (69)
padding-block-start | Supported | Supported (69)
padding-block-end | Supported | Supported (69)

Chrome doesn't seem to support the -inline and -block shorthands.

[WebMechanic]

if this was broken in 79 it's apparently fixed in Canary: Chrome/82.0.4057.1; testing it right now live on this page.

[WebMechanic]

I downloaded a PortableApp Version of Cr69.
There's no way to enter margin-inline or padding-block in Devtools. The value doesn't even show up. All I can enter is margin-inline-start, margin-block-end & friends.

[WebMechanic]

Also got my hands on a PortableApp Version of Cr79.
Same behaviour as Ch69: shorthand notation is NOT supported, only individual properties.
MDN data is wrong.

I don't use logical properties offen so I can't tell if this was added in Cr80 or Cr81. It does however work as of Canary/82.

Enjoy

[fvsch]

In Chrome stable (80) the shorthands are supported if you enable the chrome://flags/#enable-experimental-web-platform-features flag.

[WebMechanic]

Alright then! I forgot this could be the source. That's what I always switch on in Canary.
There's a buttload of (unknown) stuff enabled by this single setting, me thinks. I lost track of it...

[jonathantneal]

It appears to me that the shorthand logical property support in Chrome was updated in #3451 with notes about the required flag. These notes were not appended to the Chrome Android versions.

This flag was then removed in #4568 with the following rationale:

In rare cases, the Chrome versions made no sense (e.g. random things still behind a flag, although all other are marked as supported without a flag). I've updated the Chrome data there, but let me know if I should rather split that out in a separate PR.

I believe this gives us the end result of shorthand logical properties appearing to be supported in browsers that do not yet support them.

---

And now for some more opinionated thoughts. I think the data ought to be changed to reflect non-flagged support.

I suspect the false positives on mdn have influenced caniuse, which references the entire logical property feature set as fully implemented in all actively-developed browser engines: https://caniuse.com/#feat=css-logical-props

These false positives trickle from packages like caniuse and mdn-browser-compat-data into packages like the postcss-preset-env and doiuse. PostCSS Preset Env generates CSS fallbacks based on a browser support schema, and doiuse later lints CSS using the same schema. Both tools compare a project’s browser support with caniuse and mdn-browser-compat-data (which caniuse directly imports, sometimes). PostCSS Preset Env is bundled into tools like Create React App and Next.js. At that layer of abstraction, a large number of developers are unaware of this dependency web.

As projects drop support for Internet Explorer 11, they typically find themselves supporting (mostly) evergreen browsers. And those browsers are reported to support shorthand logical properties, which means they are neither linted when used or polyfilled when distributed.

[ddbeck]

@jonathantneal that's some nice detective work on how the mistakes were introduced. Unfortunately, sometimes these things happen. Much of BCD originated as hand-written tables on MDN and we've been doing a lot of work to improve the consistency and accuracyof the data ever since. Large-scale edits (like you saw in #4568) sometimes let errors slip through; we rely on the community for help figuring out where our data is incorrect.

I think the data ought to be changed to reflect non-flagged support.

You're quite right. If you'd be interested in opening a PR, then that would be very welcome. Flagged and unflagged data can coexist, if needed (see the schema docs for details). I'm happy to answer any schema questions you may have. For us, the real difficulty is tracking down all the support information. Pointers to tests or issue tracker links help us merge updates quickly. Let me know if I can be of help on a PR (or putting one together). Thank you!

[jonathantneal]

Thank you, @ddbeck. Some updates:

• The data has been corrected in caniuse, as of 5 days ago (see https://github.com/Fyrd/caniuse/issues/5364).
• There is an open PR to correct the data here, as of 4 days ago (see https://github.com/mdn/browser-compat-data/pull/6004).

I think #6004 likely resolves this issue.

If I understand correctly, the hold up on #6004 is a recommended change to address project-wide consistency, tho unrelated to the data itself. I think it’s a good recommendation. I’ll follow closely, as at times those kinds of requests get discussed and/or neglected _just_ long enough that the affected PR ends up abandoned. But that might also just reflect my own own OSS failures. 😄

[ddbeck]

Thanks for the follow up, @jonathantneal. And yeah, stuff getting abandoned happens—we try to keep on top of data PRs, at least, to make sure they get merged or superseded. Expect to see #6004 wrapped up reasonably soon (though #6009 will probably be a longer time coming)

[ddbeck]

Thanks to everyone who participated on this issue! It seems to be resolved and the changes will be in the next release.