Browser compatibility tool

[fscholz]

Hi!

Exciting to see that you plan to make more use of MDN’s information. I totally love this and it’s indeed a big win for both MDN and DevTools.

The current plan for https://github.com/mdn/browser-compat-data is to migrate more data (I’m focusing on ECMAScript compat data atm, but CSS is definitely next on the list). Migrating means that we translate the current static tables that we have in the MDN wiki pages into a a JSON format for which we agreed on a schema a while back.

Another repository we’re trying to populate more is https://github.com/mdn/data, which contains general data about open web technologies (so not just compat data). In the last few months, we have focused on CSS data, so there is data about CSS properties and selectors and so forth. This might be useful for your “triggers” I guess.

Because MDN wiki pages itself will consume the data of both repositories, we are not duplicating information, and the current community that cares about updating MDN pages, continues to care about this over on GitHub. However, we are still in the transition phase, so I wouldn’t call the formats and all processes stable yet.

[sheppy (Eric Shepherd)]

I think striving to ensure that the browser-compat and mdn/data projects (the latter probably needs a more descriptive name, by the way ) are thorough and easy-to-use is a great start to making it easy to build a wide variety of tools, from dev tools that provide helpful information in-context while debugging to linting tools, syntax highlighting assistants, and even code completion – and probably tons of others I can’t even imagine.

I hope we can get lots of people on board to help us build out the data stores themselves, since they’re key.

On top of that, it might be useful if there were some libraries to help work with these data stores. Tools to do the fetching of data, interpreting it in likely-commonly-used ways, and so forth. For instance, JavaScript, Node and Python libraries that take as input a term and return the appropriate data about it. Or, possibly more interestingly yet, take a term, browser name(s), and version number (or min/max versions) and simply reports if that feature works in that version of the specified browser(s).

If we could also add release dates for the browser versions to the data somewhere, you gain the ability to say “Hey, does this feature work in this set of browsers as of the specified date?” Wow, that’d be awesome handy if you’re working on a project required to work with browsers up to two years old or whatever.

Eric Shepherd
Senior Technical Writer
Mozilla

Mozilla Developer Network

Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy

[nachtigall]

FWIW and maybe inspiration, for vscode there are some extensions showing the caniuse information, see

Chris Heilmann (codepo8)

and https://marketplace.visualstudio.com/search?term=caniuse&target=VSCode&category=All%20categories&sortBy=Relevance

I think this would be most valuable for the CSS Ruleview of the Inspector (as the JS Debugger is not editable). But when testing out CSS, this compat info would valuable.

[eduardoboucas (Eduardo Bouças)]

Thanks for your thoughts @fscholz and @sheppy. I’ll do some more research around the MDN repositories.

@nachtigall that’s super relevant, thank you! I think the power of having something like this in DevTools would be that, unlike text editors, it will have a view of the bigger picture of the site being edited (e.g. all the style sheets being loaded).

Text editors can only go as far as displaying compatibility information next to a line that contains a particular CSS feature, whereas we could analyse every rule of every style sheet attached and say things like “your site requires IE10+ because of Flexbox [click here for suggested polyfill] and iOS Safari 9.2+ because it’s missing browser prefixes for CSS transforms”.

I think that being able to provide this broader compatibility information would be tremendously powerful and useful to developers of all skill levels.

[nachtigall]

“your site requires IE10+ because of Flexbox [click here for suggested polyfill] and iOS Safari 9.2+ because it’s missing browser prefixes for CSS transforms”.

I think that being able to provide this broader compatibility information would be tremendously powerful and useful to developers of all skill levels.

Hmm, well, yes. I push all my CSS through autoprefixer in all projects these days which let’s you define the list of supported browser versions upfront (again using caniuse information). So CSS gets compatible automatically.

I’m (re)thinking what would be the value of compat infos if everything is already done right by the build tools? And for JS babel somehow actually does the same by transpiling your JS code to compatible browser compatible code. So rethinking it, I guess this is pretty much covered already by modern build tools? @eduardoboucas what you think, are you already using autoprefixer or similar?

[eduardoboucas (Eduardo Bouças)]

I don’t think we can make that kind of assumption about people’s build processes. Adding prefixes automatically may be something trivial for some, but definitely not for others. The same applies to transpiling JS.

In any case, warning people about missing CSS prefixes is definitely not the crux of what I’m suggesting, more of a by-product. The main idea is to warn people of features they’re using that will not be compatible with certain versions of some browsers, something that could easily be missed unless there’s some very thorough cross-browser testing procedure in place. These are issues that autoprefixer — or any other automated tool for that matter — would have a very hard time fixing for you.

To have a feel of how a site works on different browsers, people open Chrome and the Chrome Developer Tools, then Safari and the Safari Developer Tools, then Firefox and Firefox DevTools, etc. What I’m trying to achieve is making DevTools acknowledge the existence of other browsers and provide some basic understanding of how they will render your site. It doesn’t replace actual cross-browser testing for sure, but in my opinion it makes DevTools more attractive as a cross-browser development toolbox, which seems to be the way the project is heading.

And because of MDN, Web Compat and the strength of the Mozilla community, I agree 100% with @pbro when he says that if anyone can pull this off, it’s definitely Mozilla.

[eduardoboucas (Eduardo Bouças)]

Hello, beloved Mozillians!

I finally had some time to do some more research on this. It also helped massively that the browser-compat-data repository now has much more data – great job @fscholz, @sheppy et al!

I built an extension that adds a “Compatibility” panel to DevTools, in which the stylesheets of the inspected site are downloaded, parsed and compared against compatibility data from MDN. This is how it looks like at the moment:

Please note that this is still a very crude proof of concept and comes with several limitations:

• It currently looks into CSS only – it would be much more powerful if it could also flag JavaScript compatibility issues

• When parsing CSS, it’s looking at properties only, but in the future it also needs to analyse at-rules and declaration values (to look at things like units and shorthand values)

• It needs to be smart enough to look for fallbacks. For example, there’s probably no point in flagging an issue with rem units if there is a px fallback in the same rule

• The side panel should show you where in the stylesheet the issue is, as well as include a link to the MDN page for more information (I haven’t had the chance to look into this yet, as there’s some complexity when using source maps)

• Only a subset of the browsers is being shown at the moment, mostly because the browsers.json file in the repository doesn’t include all the browsers that are then listed in the individual compatibility tables. Are there plans to address this? I can work around it if not, just wanted to check.

I completely understand (and agree for the most part with) @sole’s point of not adding something like this to core, but it’s still worth pointing out some downsides of building this as an extension:

• There is a lot of duplicated effort. The extension needs to download and parse stylesheets and scripts, which the core engine is already doing but we can’t have access to (can we?)

• I’m still not convinced a dedicated panel is the best place for this. At least for CSS, I’d rather see compatibility issues flagged in the Style Editor panel. Not sure about JavaScript

Finally, some parting thoughts:

• There are no network requests being made to MDN. Currently, the compatibility data from the browser-compat-data repo is being pre-packaged with the extension, which raises the question of how to get updates to this data. Something to think about

• I still don’t know if this is worth pursuing – would love your thoughts on that. As I mentioned in the initial post, this is never going to be perfect and it’s not meant to replace proper cross-browser testing, but I love the idea of having a browser that is aware of the other browsers in the market and gives you an initial idea of any potential issues to look out for.

If you want to give it a try, here’s the source code: https://github.com/eduardoboucas/compat-report. Again, this is a rough proof of concept, so mind your step – you will find glitches in the matrix!

Thanks for reading and thanks in advance for any feedback.

[sheppy (Eric Shepherd)]

Eduardo – This is really an exciting beginning! A tool like this could be insanely helpful for developers trying to meet specific compatibility goals. Can’t wait to see where it goes.

Sheppy

[sole]

This is great! Thank you Eduardo

Re: built in vs not built in. Our ideal world is one in which we have a solid fast core with the subset of tools most people use, and offer lots of (robust, safe) APIs so extension developers can augment the tools to their liking.

The old Firefox extension system would allow lots of flexibility and developers could do pretty much anything (including directly referencing parts of the DevTools API like… the code editor!) – I guess you will agree this can be “a bit” unstable. The new WebExtensions system is more restrictive and is missing APIs, as you mentioned, but that does not mean that it cannot be fixed.

If I understood correctly, there might be ways to ship experimental APIs that only work if DevTools are running. If these APIs become popular, maybe we want to propose them as a standard. But we need people experimenting with these definitions, and getting a feel for what could work, or not. As any experimental work this needs time and patience and a lot of failed attempts, so there’s no immediate solution.

With regards to augmenting specific panels: we also discussed internally about this. The short answer: it is complicated. The long answer:

a) either you build an API to allow inserting/manipulating/removing content (which you have to design well and maintain)
b) or you expose the underlying structure (which can be a nightmare for us and extensions developers if we change the structure).

(and for both options, I am kind of imagining the security team screaming “XSS!!!” from afar)

The other option is to take this code into the core. Which would mean adding more code that we need to maintain with a small team, for functionality which might not be of interest for everyone. This is somewhat at odds with our aim of making the tools faster and leaner. But maybe this becomes an indispensable tool and everyone says they need it? I can’t predict the future, but I like using WebExtensions to test the waters!

Furthermore, downloading and parsing assets is not always done unless required; so we can’t assume that we’re duplicating work here. Also, it might be the case that your parsing is more benign than the one Firefox or the tools apply, as we might be ignoring properties that are not valid in Firefox. So using the parsing from the browser might actually not be what you want! Again, lots of fine grain to be looked at…

But definitely a good starting point! Thanks again!

[eduardoboucas (Eduardo Bouças)]

Hola Sole!

Thanks for your feedback.

This is somewhat at odds with our aim of making the tools faster and leaner.

I’m with you 100%, and I can see how the project would go completely off the rails if every new feature request was added to core. I think that, at least for know, it makes perfect sense to keep this as an extension.

I also agree with your “using WebExtensions to test the waters” approach. I still wonder about discoverability, but maybe that’s because I was never an extension kind of guy!

Also, it might be the case that your parsing is more benign than the one Firefox or the tools apply, as we might be ignoring properties that are not valid in Firefox.

This is very true. I thought about tapping into document.styleSheets to avoid downloading + parsing stylesheets again, but this wouldn’t give me access to CSS declarations that are ignored by the browser.

However, when I open the Style Editor panel I can see the full list of declarations, even the ones that Firefox will ignore, so the raw content should be there (and the fact that it’s syntax-highlighted makes me think that it’s being parsed to some degree?).

In any case, this duplication of effort is really a non-issue for now. It’s not really an argument in favour of building this into core, I just wanted to share all my findings.

So… I guess this is where I’m at: this is quite a big project, which is a challenge for me considering the short amount of time I can allocate to it on a regular basis. More than anything else, I guess I’m looking for validation and honest feedback on whether this is worth pursuing, and whether I could perhaps get some help at certain points along the way (e.g. some UX/UI advice).

I’ve been obsessing with this idea of having a browser that is aware of its competitors and flags compatibility issues, and with MDN increasingly becoming the place for Web documentation it seems natural to leverage that. Also, there is a world of possibilities to explore in this space, especially once you throw JavaScript in the mix, start suggest polyfills, etc.

But there’s always the possibility that other people won’t bother trying it, especially if it involves installing an add-on built by some guy they never heard of, if they ever come across it at all.

I guess I’ll wait for some more feedback and then, if we decide it’s worth going ahead, I’ll devise a plan to build this in phases with realistic milestones?

Thanks again for your feedback!

[Nicolas_Chevobbe]

Hello Eduardo, this is impressive, and I think lots of developers would like this very much.
For the discoverability side: we maintain a collection of recommended extension in AMO https://addons.mozilla.org/fr/firefox/collections/mozilla/webdeveloper/ , so I can imagine yours could be featured here.
Also, we want to experiment and have extension suggestion/browsing in the toolbox, so it might help here too.

[eduardoboucas (Eduardo Bouças)]

That’s great, @Nicolas_Chevobbe. Thank you for the feedback!

[pbro]

This looks amazing Eduardo. Thank you for sharing.

I think this is worth pursuing and pushing to addons.mozilla.org at some point.
If you need new WebExtension APIs, it’s always possible to file bugs for them, and then we can discuss about the feasibility and priority of each of them.

If you need more technical or design help on this, feel free to continue posting on discourse, or on the mailing list: https://lists.mozilla.org/listinfo/dev-developer-tools

I agree with the add-on and separate panel approach. This is what makes the most sense in the current state of things.

In terms of CSS parsing, the one DevTools does for the style editor and for the inspector would, in fact, be very useful to you. A few years ago we were using something similar to document.styleSheets, but now we have the full authored stylesheet text and we parse this, even things Gecko doesn’t care about. And we also handle source maps.
So, being built-in, or having more tightly coupled APIs would give you more power and avoid duplicating fore sure. But that’s not a possibility yet.

We can help make some noise about the extension once you feel a v1 is ready. And go from there. If it proves valuable to people, then we can discuss about better integration in the code.
But also with the UI itself: having some of the information in the style-editor, inspector, debugger would be very useful probably.

Keep up the good work!

[eduardoboucas (Eduardo Bouças)]

Thanks, Patrick! I really appreciate the feedback.

I feel I have enough support to carry on!

I’ll keep this thread updated with any news, and I’ll probably pester most of you on Slack at some point.

Thanks all!

[Nicolas_Chevobbe]

I think it would be nice if you could put your work on a Github repo so you can :

• Get contribution (for people who care, might be also some of the devtools team, maybe webcompat or MDN people as well ?)
• Get people to test it before publishing to AMO
• Gather specific needs/ideas from other devs

[eduardoboucas (Eduardo Bouças)]

@Nicolas_Chevobbe it is on a GitHub repo, linked above (https://github.com/eduardoboucas/compat-report).

In the next couple of days I’ll update the README with development instructions.

Thanks!

[atopal (Kadir Topal)]

Thank you Eduardo! This is amazing and exactly what we hoped people would do with the machine readable compat data.

[eduardoboucas (Eduardo Bouças)]

Hi everyone!

Just thought I’d share some progress on the extension. Here are some screenshots that show a bit of the workflow.

1. Clicking on the Compatibility tab displays a general view of the number of issues per browser version.

• Green: No issues
• Yellow: 1 to 7 issues
• Red: 8 or more issues

The sidebar shows a list of all the stylesheets found in the website, with the option to exclude any of them from the compatibility reports.

2. Clicking on a browser version opens a new tab that drills down on the compatibility issues found for that particular version. All stylesheets with compatibility issues will be shown on the sidebar.

3. Clicking on a stylesheet will display its contents on the code inspector, as well as expand its compatibility issues on the sidebar. Lines with issues will be highlighted in yellow. Clicking on an issue on the sidebar will scroll the code inspector to the respective line.

4. Clicking on the arrow in the beginning of each highlighted line will expand the details of that particular compatibility issue, showing the name of the source file, the line and column and a link to the respective MDN page. Whenever possible, information on how to fix the issue is provided – for example, the screenshot below shows a scenario where the problem can be fixed simply by adding a missing vendor prefix.

To do:

• Integrate with source maps
• Detect fallbacks (e.g. not flag CSS Grid as a compatibility issue if a float fallback has been found)
• Add support for reporting of JavaScript compatibility issues

I’ve updated the GitHub repository with the latest source, which you can use to test the extension.

Any feedback on the above will be much appreciated. I’ll share more as I progress.

Thanks!

[MikeRatcliffe]

You are creating a very useful tool… awesome work!

[eduardoboucas (Eduardo Bouças)]

Thanks, @MikeRatcliffe. Much appreciated!

I’ve actually just published a first version of the extension on AMO, making it easier to install: https://addons.mozilla.org/en-US/firefox/addon/compat-report/

If anyone has a chance to try it, I’d love to hear your thoughts.

Thanks!