Adopt browser-compat-data to show compatibility in hover / completion

[octref]

https://github.com/mdn/browser-compat-data

[connorshea]

Here's the pseudo-class coverage for mdn/data vs mdn/browser-compat-data, this list probably isn't complete since all the pseudo-classes are sourced from the data repo, and there may be some missing items.

Unless otherwise noted, the name of the selectors in the data repo can be mapped to the browser-compat-data repo by taking their name, stripping the colon, and prepending css.selectors..

For example:

:active => css.selectors.active
:first => css.selectors.first
:first-child => css.selectors.first-child

Psuedo-class coverage:

• :active
  • ✅data
  • ✅bcd
• :any()
  • ✅data: This is weird because it only has syntax specifically for the -webkit-/-moz- vendor prefixed versions. Also, it should be a function.
  • ❌bcd
• :any-link
  • ✅data
  • ✅bcd
• :checked
  • ✅data
  • ✅bcd
• :default
  • ✅data
  • ✅bcd
• :defined
  • ✅data
  • ✅bcd
• :dir()
  • ✅data
  • ✅bcd
  • Should probably be a function but isn't listed as one, in data it's named :dir and in the bcd it's in dir.json.
• :disabled
  • ✅data
  • ✅bcd
• :empty
  • ✅data
  • ✅bcd
• :enabled
  • ✅data
  • ✅bcd
• :first
  • ✅data
  • ✅bcd
• :first-child
  • ✅data
  • ✅bcd
• :first-of-type
  • ✅data
  • ✅bcd
• :fullscreen
  • ✅data
  • ✅bcd
• :focus
  • ✅data
  • ✅bcd
• :focus-visible
  • ✅data
  • ❌bcd
• :focus-within
  • ✅data
  • ✅bcd
• :host
  • ✅data
  • ✅bcd
• :host()
  • ✅data
  • ✅bcd: Note that this is called hostfunction.json and the data mapping in the bcd repo would be css.selectors.hostfunction, this is probably a bug that should be fixed.
• :host-context
  • ✅data
  • ❌bcd
• :host-context()
  • ✅data
  • ✅bcd: This is just called host-context.json
• :hover
  • ✅data
  • ✅bcd
• :in-range
  • ✅data
  • ✅bcd
• :indeterminate
  • ✅data
  • ✅bcd
• :invalid
  • ✅data
  • ✅bcd
• :lang()
  • ✅data
  • ✅bcd
  • Should probably be a function but isn't listed as one, in data it's named :lang and in the bcd it's in lang.json.
• :last-child
  • ✅data
  • ✅bcd
• :last-of-type
  • ✅data
  • ✅bcd
• :left
  • ✅data
  • ✅bcd
• :link
  • ✅data
  • ✅bcd
• :not()
  • ✅data
  • ✅bcd
  • Should probably be a function but isn't listed as one, in data it's named :not and in the bcd it's in not.json.
• :nth-child()
  • ✅data
  • ✅bcd
  • Should probably be a function but isn't listed as one.
• :nth-last-child
  • ✅data
  • ✅bcd
  • Should probably be a function but isn't listed as one.
• :nth-last-of-type()
  • ✅data
  • ✅bcd
  • Should probably be a function but isn't listed as one.
• :nth-of-type()
  • ✅data
  • ✅bcd
  • Should probably be a function but isn't listed as one.
• :only-child
  • ✅data
  • ✅bcd
• :only-of-type
  • ✅data
  • ✅bcd
• :optional
  • ✅data
  • ✅bcd
• :out-of-range
  • ✅data
  • ✅bcd
• :placeholder-shown
  • ✅data
  • ✅bcd
• :read-only
  • ✅data
  • ✅bcd
• :read-write
  • ✅data
  • ✅bcd
• :required
  • ✅data
  • ✅bcd
• :right
  • ✅data
  • ✅bcd
• :root
  • ✅data
  • ✅bcd
• :scope
  • ✅data
  • ✅bcd
• :target
  • ✅data
  • ✅bcd
• :valid
  • ✅data
  • ✅bcd
• :visited
  • ✅data
  • ✅bcd

[connorshea]

I looked through css-schema.xml and found a few that are missing from both mdn/data and mdn/browser-compat-data:

• :blank
• :corner-present
• :current
• :current()
• :decrement
• :double-button
• :decrement
• :end
• :future
• :horizontal
• :increment
• :local-link
• :local-link()
• :matches()
• :no-button
• :nth-column()
• :nth-last-column()
• :nth-last-match()
• :nth-match()
• :past
• :recto
• :single-button
• :start
• :user-invalid
• :verso
• :vertical
• :window-inactive

Most of these are non-standard. I also excluded quite a few that are vendor prefixed. I doesn't look like any of them have MDN pages either.

I opened an issue to get these added: mdn/data#241

[connorshea]

There is one other consistency, and that's that the bcd data lists :host as css.selectors.host, :host() as css.selectors.hostfunction, :host-context() as css.selectors.host-context, has no entry for :host-context.

For psuedo-class function selectors, there's not much consistency. Just assuming that :host() maps to host won't work in that specific case, unfortunately. This is probably something we should bring up upstream.

[connorshea]

For properties, you can map anything in properties.json to css.properties.property-name in the browser-compat-data repo, at least as far as I can tell.

There are probably a few properties missing from each dataset, but for the most part it should map cleanly.

Examples:

• background in mdn/data => css.properties.background in mdn/browser-compat-data.
• break-before in mdn/data => css.properties.break-before in mdn/browser-compat-data.

[connorshea]

@octref so it looks like things should map between the two datasets pretty well ^_^

[octref]

@connorshea Thanks a lot for your hard work! Those information will definitely come useful when I add support for browser compat data.

As for the nonstandard pseudo selectors, I don't think they should end up in mdn/data because MDN then also need pages dedicated to explaining them. For us we can consider either:

• Removing those completely
• Always rank them (and the vendor-prefixed ones) lower than the standard ones

[octref]

Some notes while studying the data:

• License is CC0
• Some values are inside their standardized alternative. For example, -webkit-animation live inside https://github.com/mdn/browser-compat-data/blob/master/css/properties/animation.json
• Some property values are missing. For example https://github.com/mdn/browser-compat-data/blob/master/css/properties/align-content.json
• browser-compat-data contains far more browser support than us, specifically mobile browser support
• For experimental properties, these data come especially useful. We have no browser compat data for almost all the experimental values.

Ideas

• We should show which browser is NOT supported, for standard properties. For example, grid is NOT supported in only IE.

Thoughts

• We should first study what users want the hover / completion to display regarding browser compatibilities, before rushing to implement something.
• We need to take into consideration of popular build tools such as autoprefixer, which
  • Prefixes a value if it's needed for the targeted browser range
  • Removes a value if it's not needed for the targeted browser range

Actionable

• For all experimental values, we add browser-compat data to show compatibility
• For all other values that don't contain compatibility data, try to look it up in mdn/browser-compat-data and show them

[connorshea]

Also worth noting for the BCD data: there’s an implicit assumption that support data is ordered such that the most recent support data for a browser is at the top (e.g. Chrome 57 is true, then Chrome 55 has the feature behind a flag). So you should be able to parse just the first support entry for each browser, assuming you don’t need any info on prefixes for past versions, etc.

Unfortunately this isn’t enforced in the codebase by any automated tools, though there is an issue to make it happen: mdn/browser-compat-data#1596

[octref]

@aeschli I pushed a WIP PR. See #105

I have some questions regarding the presentation of the browser compat data. I would like to display it this way:

• For status: standard properties
  • If it's supported in all our 6 supported browsers, show nothing
  • If any browser does not support it, show unsupported browsers
• For status: experimental properties: Show both supported and unsupported browsers

I feel the current display is too much noise. Don't believe any user is interested to learn that border is supported from E12,FF1,S1,C1,IE4,O3.5. We should try to highlight which browser don't have support for certain properties.

[aeschli]

I'd rather not make that change.

• no complaints from what I know of
• by having the version number, it gives you an idea of how long the feature has been implemented. The version gets interesting once it has only been recently added.
• switching to 'not supported on xy' requires us to maintain the information constantly. Also, it doesn't tell you about the set of browsers that we talk about. There are more browsers around, in particular, embedded browsers which we don't cover.
  The current way of listing lists a set of facts that we know.

[octref]

@aeschli I'm suggesting that because with the new data, a lot of the "supported in all browsers" properties gets a browsers property. For example:

https://github.com/Microsoft/vscode-css-languageservice/pull/105/files

These will be quite noisy and unhelpful.

[octref]

For verifier: check aed9968 and verify the newly added properties are in the completion documentation.