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.
[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/
@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!
I spent some time looking into the new browser-compat-data repository (great job, MDN 
) 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! 
1 Like
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.
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
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
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.
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.
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?
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
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
remunits if there is apxfallback 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. 
4 Likes
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
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! 
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!
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.
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!
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!
1 Like
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
@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!