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!
Thank you Eduardo! This is amazing and exactly what we hoped people would do with the machine readable compat data.
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
floatfallback 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!
You are creating a very useful tool… awesome work!
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!