Browser compatibility tool

Developer Tools
#1

Hello DevToolers!

I’d like to share with you and hear your thoughts on something I’d love to see added to Firefox DevTools.

When writing code for the web, whether it’s CSS, client-side JavaScript or even Node.js, developers need to constantly be wary of compatibility issues, as every line of code they add to the codebase can potentially break the experience for a group of people that are on a particular browser/device/OS combination. This is a big challenge!

The way most of us tackle this is by doing extensive cross-browser testing at various stages of the project, but still it isn’t trivial to understand how compatible a new piece of code is with the various platforms we want to cater for unless there’s a comprehensive set of automated cross-platform regression tests in place that run continuously as new code is added. This is difficult and complex.

To help developers with that challenge, I propose a tool that constantly looks at the code of a project and generates a compatibility report, highlighting in real time what parts of the code are problematic for certain platforms and painting a picture of what the overall mininum browser requirements are.

In a nutshell, it would need to:

  1. Read/parse source files (CSS and JS) attached to a page;
  2. Match the code against a list of features on a compatibility table (e.g. caniuse.com or MDN).

This would allow us to generate information like “this site requires IE10 because it’s using Flexbox”. Taking it a step further, we could help developers solve some of the compatibility issues by linking to polyfills on MDN or polyfill.io.

There’s a lot of scope for improvement over time, such as being smart about detecting fallbacks (e.g. not flag the use of rem units as a compatibility issue if we identify a px fallback).

I have worked on a very crude proof of concept that implements this by looking at the caniuse.com API, but I think it would be interesting to make this part of DevTools because:

  • MDN is a gold mine of information and, from what I understand, the team is moving towards making compatibility information available programatically. I think this would be another great opportunity to link the two projects.

  • I think this idea plays nicely with the path DevTools is taking towards becoming the go-to browser-agnostic set of development tools, in the sense that it’d acknowledge the existence of the other browsers and help developers with the challenges of working with them.

This tool does not intend to replace any cross-browser testing, of course, which will always be the ultimate way of understanding how something works across the various environments, but I believe it would warn developers of potential issues as they arise, allowing them to test, tackle or dismiss them with more confidence.

I’d love to hear your thoughts on whether you think this would be an interesting addition to DevTools. Please let me know if something wasn’t clear and I’ll be more than happy to explain in more detail.

Thanks all!

1 Like
#2

Hello!

I think that’s a great idea! Super useful for web developers–specially if they are using some new area they’re not super familiar with.

What would you think about splitting this in a few parts and keep them separated from DevTools per se? E.g. one module that looks at code, another one which renders results, etc. This would allow us to test the code faster than inside the tools, and also reuse it in multiple ways. It could be a cli runner, so you could run it on continuous integration systems like Travis, and it could also be a WebExtension so it would run both in Firefox, Chrome and other browsers that support these standard addons.

By not being coupled to anything it would be really pragmatic, and it would bring the power of the MDN info to many more places =)

#3

Absolutely, I’m all for modularity! Do you think any of these modules would ever be part of the DevTools UI, or would it always remain completely decoupled as an extension?

#4

To be honest, I don’t know, sorry. I know that we’re ‘at capacity’ with panels, as there are a lot that can be enabled and past a certain point there’s just not enough space. This feature sounded like a new panel, so my alarms went off, so to speak.

Perhaps this tool will be super useful and everyone wants to install it, or perhaps not. My line of thought with the modularisation/extensibility was so that we could use its features in as many places as possible.

#5

That’s completely understandable and I suspected that might be the case. The only reason I suggested it anyway is because I figured that making this part of DevTools could give it a visibility that might otherwise be difficult with an extension.

For example, we could experiment with automatically processing a stylesheet in the background and providing some very subtle indications of compatibility issues, “luring” users to expand on that information and see a detailed view of the compatibility report.

With an extension, we’d need people to actively look for this functionality and install it on their system — there’s absolutely nothing wrong with that, I just wanted to throw the discussion out there to get an idea of how useful do you think this would be, to assess whether this (quite big!) undertaking is worth pursuing. :slight_smile:

#6

I am fairly sure we have discussed this before. We hope to add compatibility information to JS and HTML as well as providing general feedback in some form.

How we surface that though is another question. I don’t think it should be a new panel but rather additions to other panels. We have the event icon in the markup view so maybe another small icon would be discrete enough.

#7

Agree! I just realised that in my previous comments I unintentionally made it seem like this would require a new panel, but it probably doesn’t. We could flag individual compatibility issues on the existing editors, and perhaps add an icon somewhere that provides an overall compatibility report/score.

#8

Great idea @eduardoboucas, thank you for sharing!

I’m definitely interested in something along these lines. If there’s a devtools out there which can provide webcompat information, it’s Mozilla’s. We should totally do it.
I’m sure the people in the Mozilla WebCompat team would be interested in this actually.

The hardest part is figuring out what exactly should this thing do. What’s the scope? Where does it live?
You mentioned you have a proof of concept already, I’d be very interested in learning more about that!

#9

This was my thinking exactly! :slight_smile:

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.

#10

Off topic, but your work here reminds me of something similar I started that would give users warnings when they use valid CSS that is useless (e.g. setting a width on an inline element). Similarly to your approach, it has a list of rules, reads CSS, and when it finds something that matches a rule emits a message.

#11

[Not totally offtopic] Is https://github.com/ai/browserslist used on this? or should it?
An article discussing it too: https://css-tricks.com/browserlist-good-idea/

#12

@pbro I love that! In a way, it’s the same line of thought where we preemptively inform users of potential issues with their code as they’re writing it.

@sole it isn’t at the moment, but it totally should. Thanks for sharing that!

#13

I spent some time looking into the new browser-compat-data repository (great job, MDN :heart: ) and I think that a first step into this compatibility tool would be to write something that matches that data against a given style sheet. This would likely be similar to the “triggers” approach I described above, either by annotating the existing JSON files with information about how that rule can be matched, or by placing that information on a separate file/repository (probably a better idea).

@fscholz, it would be great to hear your thoughts on all of this! :slight_smile:

1 Like
#14

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.

#15

I think striving to ensure that the browser-compat and mdn/data projects (the latter probably needs a more descriptive name, by the way :slightly_smiling_face:) 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


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

#16

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


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.

#17

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.

#18

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?

#19

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.

1 Like
#20

Hello, beloved Mozillians! :wave:

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:

screenshot1
screenshot1.png2286×1868 433 KB

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. :heart:

4 Likes