This was my thinking exactly!
I put together this repository with that proof-of-concept I talked about. At the moment, it only works with CSS. Please note it’s still very rough, as I haven’t spent more than a few hours on it. I just wanted to see how something like this could work.
In a nutshell, here’s what it does:
- there’s a JSON file with compatibility data from caniuse.com;
- it has a list of triggers, in JSON format, which match CSS declarations against caniuse rules;
- it reads and parses a CSS file and tries to match every selector/declaration against the available triggers;
- a list of matches (issues) is compiled and the compatibility report is generated using the greatest common denominator (e.g. if rule A is IE8+ and rule B is IE10+, then the style sheet is IE10+).
This is indeed the biggest challenge. It’s a big project, especially if we want to provide compatibility information for CSS and JavaScript. In terms of scope, I think my approach would be to pick one of these to begin with (I’d say CSS) and slowly start integrating compatibility information into existing parts of DevTools (e.g. the Style Editor).
The next step could be moving to JavaScript, and only after that iteration work on making the engines smarter, like detecting and suggesting fallbacks/polyfills.
I suppose this would also need to involve a conversation with MDN/WebCompat people, to understand how we can interact with their data:
- Would it consist of a flat file, similar to what I’ve done with caniuse.com data, that we’d consume in the tool? Or would it be some form of centralised API?
- We’d need to establish a strategy for matching code against their compatibility data, similarly to what I’ve done with “triggers” in my proof-of-concept.
I’d love to be involved as much as I can (bearing in mind my time constraints), so if this goes forward let me know how I can help!
Thanks again.