[Hint] Deprecated, removed and/or old versions of APIs

[molant]

Original reported by @alrra in webhintio/hint#30

@molant

@dstorey had a good idea earlier about this. We could use the WebIDL of the different versions of different browsers to track which APIs have been deprecated and removed. This should be more reliable than a manually curated list, should be more automatic (we just need to pull the new version each time), etc.
I won't be trivial but I think it is worth a shot.

@alrra

SGTM.

we just need to pull the new version each time

Note: We can (?) even use Travis CI to pull the data periodically and automatically commit any changes.

@dstorey

The Edge WebIDL files have "extended" (browser specific), "deprecated" (deprecated from the spec) and "interop" (included for interop reasons). Older versions just have the "msDeprecated" tag I think.

I'll need to look into the other browsers to see how they mark things.

For Firefox they're all in one directory like Edge: https://dxr.mozilla.org/mozilla-central/source/dom/webidl
Chrome and Firefox mix theirs in with their implementation such as http://trac.webkit.org/browser/webkit/releases/Apple/Safari%20Technology%20Preview%2028/WebCore/html and https://chromium.googlesource.com/chromium/blink/+/master/Source/core/html

@dstorey

Firefox splits out their deprecated members in their own partial interface like we're doing with Edge, but I don't see a tag so you'll probably need to recognize the URL comment above the partial to know they're deprecated. Chrome doesn't split them out but does have a comment saying obsolete or such. Hopefully those comments are consistent enough to check. In Safari there all mixed together so probably can't pick up any info.

When a feature is dropped, like webkitDropzone, it is removed from the webidl file, so you'll need to keep track of that.

DOM IDL attributes that match the equivalent html attributes are tagged with [Reflect] in most browsers, so should be able to use that to detect html attribute support, I'm not sure about attributes that have different names in HTML vs the IDL interface attribute.

@alrra

@dstorey We had a discussion about this the other day, can you provide more details here? Thanks!

@dstorey

I'm putting together more details on what could be done here.

@antross

We could also expand the scope of this hint to notify users about new APIs which aren't yet available somewhere within their chosen browser support matrix (see #1203 for CSS) and HTML deprecations (see #1204).

We just had a good conversation today with @digitarald and @martinbalfanz from Mozilla and it sounds like the MDN compatibility data would be a good fit to help us build this hint. There's also a Firefox/Chrome DevTools extension called Compat Report which is built on this data we could look at as an example. Currently the MDN data is complete for CSS with work in-progress to finish the rest of the platform APIs.

I'm particularly interested in this space and would be happy to help us move forward on getting this hint started once I wrap up with the VS Code extension.

@dstorey

I'd still like to see WebIDL used to keep the MDN data up to date as it is often incorrect (at least for Edge) or out of date (relies on someone to manually check each release and not miss anything). Having tooling that checks both WebIDL and type mirror to guide updating MDN (if it isn't allowed to be automatic) would be fantastic. E.g. Google's type mirror tool that compares with MDN: https://mdittmer.github.io/mdn-confluence/multi.html and https://github.com/mdittmer/mdn-confluence . Both data sources have their uses as some data is lost with type mirror (including non enumerables, parameters, etc. while sometimes WebIDL may be incorrect (such as if something is off by default or a API is broken somehow)

@antross

I'd still like to see WebIDL used to keep the MDN data up to date

@dstorey Totally agree that figuring out how to use WebIDL to help keep whatever data source we use up-to-date is a good idea. I noticed there is an open issue on the MDN compat data repo about looking into WebIDL for keeping in sync with specifications.

I'd be curious to have @patrickkettner's input too, but it seems like it would be worthwhile to start a discussion or new issue there about also using the WebIDL from browsers?

@dstorey

I think so as it is a good source of thruth for the most part, with all browsers using it to generate code (with some caveats)

@digitarald

I'd still like to see WebIDL used to keep the MDN data up to date as it is often incorrect (at least for Edge) or out of date (relies on someone to manually check each release and not miss anything).

@dstorey is that still the case with the recent involvement from all browsers to keep the data fresh? I wonder if it is on webhint to figure this problem out, since the browser-compat-data seems to be working on improving correctness and reducing the update latency.

@patrickkettner

it is substantially less true than it was previously, but it is still an issue. IDL code will almost always be more accurate than a manually curated list

@digitarald

I can understand the risk of using bad data, its a GIGO risk and it can dissolve the trust in the audit. My expectation would be, and I am happy to take point on driving this, that MDN's data will keep aiming to be the most complete and up to date dataset.

As perfection will be never achieved with this kind of aggregated date, what level of accuracy do we expect in the data that powers the audits? Or more specific, what is good enough to unblock this discussion?

[molant]

@digitarald think we should start with the CSS data. From what you say it should be fairly updated and we go from there. IMO it's better than having nothing and we can always flag it as "experimental" until we all feel confident. Does this seem reasonable to everyone?

[digitarald]

@molant agreed, we also got prior art from https://addons.mozilla.org/en-US/firefox/addon/compat-report/ to learn from.

Would it make sense to extend this issue to general API support (old and new). Interop is probably more impacted by sites using new features vs dependencies on old features. Or is the detection meant to highlight an overlap of both scenarios by finding outdated prefixed spec use?

[molant]

The idea is to cover new and old APIs. Users can set browserslist in their configuration and based on that information and the one coming from the compat table we can figure out if they are going to have any issues with any API.

[CKGrafico]

We are starting with the CSS APIs for this hint, do you prefer to put all the APIs in the same hint and name it something like hint-compat-api or do you prefer to split each APi and name it something like hint-compat-api-css ?

[molant]

I personally would like to have a single hint to check for deprecated APIs. I think there's going to be quite a lot of duplicated code and the data source is probably going to be always the same. Maybe we can add some type of configuration overtime so the user can decide if they want hints for CSS, JS, etc.?

[sarvaje]

Maybe we can add some type of configuration overtime so the user can decide if they want hints for CSS, JS, etc.?

Maybe we can use a "multi-hints" hint like hint-typescript-config.

[molant]

Maybe we can use a "multi-hints" hint like hint-typescript-config.

That's a great idea. It will only have one for now but it allow us to expand.

@antross, @alrra, @digitarald, what do you think?

[antross]

The multi-hint approach sounds good to me if we're organizing by programming language (CSS, JS, HTML).

If we're going this route I'd also encourage a split between deprecated and not broadly supported APIs (some APIs may be both). Personally I tend to care more about getting notified of APIs that aren't supported everywhere (are broken today) than ones that work everywhere, but have been deprecated (may be broken tomorrow). I could easily see wanting errors for the former and warnings for the latter for instance.

[antross]

Also when we're running against the filesystem (e.g. with extension-vscode via connector-local), we'll need some thought to avoid false-positives for unprefixed APIs which require prefixing in some supported browsers. This may be as simple as checking the local package.json for a known autoprefixer.

[CKGrafico]

I'm working on this branch, https://github.com/CKGrafico/hint/tree/feature/hint-compat-api-css/packages/hint-compat-api if you want to doublecheck the structure before the PR could help me because is my first multihint

structure purpose:

packages/
 |- hint-compat-api
     |- src
         |-compat-api-css (deprecated css)
         |-compat-api-css-next (not broadly supported css)
         |-compat-api-js (deprecated js)
         |-compat-api-js-next (not broadly supported js)
         |-compat-api-html (deprecated css)
         |-compat-api-html-next (not broadly supported html)

[molant]

@CKGrafico the structure looks fine, it follows what we are doing in other multihint packages.

Also, we aim to have near 100% coverage in the tests in case you want to add it to your list.

API is deprecated for IE but the user configured hint only for Chrome

You probably want to take look at change-feedback-based-on-browser-support in the contributor guide first. Anything that isn't clear please open an issue with the docs tag so we can improve it.

Thanks!

[CKGrafico]

@molant If I'm not wrong we've talked that we will create a specific hint for Flex box, does that mean that we can ignore flexbox here?

[molant]

Not exactly. We want to detect when someone is doing something with flexbox that will render incorrectly in some browsers. You should still detect for flexbox in this rule and we can decide later if we try to detect the quirks in here or a separate one. @antross i think we wanted it in the same hint but aren't 100% sure.

…

________________________________ From: Quique Fdez Guerra <notifications@github.com> Sent: Thursday, October 18, 2018 03:10 To: webhintio/rfcs Cc: Antón Molleda; Mention Subject: Re: [webhintio/rfcs] [Hint] Deprecated, removed and/or old versions of APIs (#10) @molant<https://github.com/molant> If I'm not wrong we've talked that we will create a specific hint for Flex box, does that mean that we can ignore flexbox here? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#10 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAlBgkLFDaacXMYwJSt2MNwMmcjXJOyHks5umFOUgaJpZM4WdzsT>.

[antross]

i think we wanted it in the same hint but aren't 100% sure.

Let’s focus this hint on API support for now and leave quirks for separate, dedicated hints. As @molant said, that still means we should test for flexbox support here, even if we create a separate hint for flexbox quirks.

To my knowledge there’s no existing structured data source we can get quirks from in a way that can be generically tested, so we’re going to have to hand-roll these when we want them anyway. May as well keep the code separate since it won’t be related to the MDN data.

[antross]

Types like attr() should show up in declaration values. Not sure if that will be true for all of them until we look at more examples, though (some may be at-rule params).

[CKGrafico]

To do for CSS part of this task:

Check this link: webhintio/hint#1443

Some information after investigating about this:

From mdn we have this kind of information (mdn-browser-compat-data):

• at-rules (ex: media) ----------------- [1]
• properties (ex: background) -------- [2]
• selectors (ex: nth-child) --------------[3]
• types (ex: attr) ------------------------[?]

And from CSS Parser (using walk method from PostCSS):

• declaration:
  • property (ex: background) ------- [2]
  • value (ex: red)
• rule:
  • selector (ex: #myDiv:nth-child() -- [3]
  • nodes (declaration[])
• at-rule
  • name (ex: media) ---------------- [1]
  • params (ex: max-width))
  • nodes (rule[])

Thats what we have by the moment (we will update this comment in the future).
Numbers are related topics between the libraries and question marks [?] are things that we still don't know how to check or if are necessary to check.

There are some things that we are still investigating and we don't know, some of them are in webhint docs but we are listing to search later:

• How two check if something is deprecated or is 'next'
• What to do with MDN types list
• Not sure if we have to check at-rules params
• Doublecheck if .walk() give children rules and declarations
• If we need to clean selectors like #myDiv:nth-child() to be compatible with MDN
• How to filter by browser from config

Diagram of the flow (will be edited meanwhile we work on this)

[CKGrafico]

We had a problem today, inside some of the "terms" (background, color, clip-path) sometimes we can find more information, like this example:

But this information seems "extra" I mean, we cannot dynamically understand it, and its different for each "term".

For example:
If we open the CSS property 'color' there is more info like the compatibility o transparent color, that we can probably understand (more or less) because transparent is going to be in some properties.

But this seems a lot of extra work and no 100% accurate results. A part of that there is a lot of non-understandable keys like "space_separated_funcional_notation", "floats_in_rgb_rba" that the only way to understand is to have all of them in our side.

Purpose:
Can we (at least for the first version) ignore these "extra" values? and check only the compatibility of standard properties "color", "background" @media, etc?

PS: These other values are in the table of this page, easy for a human understand but difficult for us to test https://developer.mozilla.org/en-US/docs/Web/CSS/color#Browser_compatibility

[antross]

Can we (at least for the first version) ignore these "extra" values?

@CKGrafico Let's move forward ignoring these for now. After we get the rest of this working we can decide if we still want to dig deeper for this PR or if we want to track going deeper on these properties as a separate enhancement.

That said, I wouldn't mind poking around these values a bit more myself. Is there an easy way for me to take a look?

[CKGrafico]

Can we (at least for the first version) ignore these "extra" values?

@CKGrafico Let's move forward ignoring these for now. After we get the rest of this working we can decide if we still want to dig deeper for this PR or if we want to track going deeper on these properties as a separate enhancement.

That said, I wouldn't mind poking around these values a bit more myself. Is there an easy way for me to take a look?

@antross yes! luckily all the values are in this npm package https://github.com/mdn/browser-compat-data if you install it you can find in:

const bcd = require('mdn-browser-compat-data');
const ast = bcd.css;

or just in github code https://github.com/mdn/browser-compat-data/blob/master/css/properties/color.json

[isabellachen]

@antross @molant compat-report talks about the problem of how to deal with sub-features (transform/translate transform/rotate). compat-report identifies the sub-features in the CSS block by hard-coding the features in and looking for them in the mdn-compat-data. Example.. The problem is that this is not dynamic and if the mdn data changes we won't have the updated data. Any ideas on what would be the preferred way to do this?

[antross]

I’m thinking we may want to try updating the MDN data itself here. That way we avoid creating our own hard-coded table on the side and potentially help other tools consume this data more easily in the future.

Specifically I think adding a regular expression to the data for matching values which signal the use of a particular sub-feature would do the trick. I’m not sure who the right contact would be to start this conversation, but maybe @digitarald knows.