Bug 1430488 Comment 4 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

For what it's worth, [someone on Stack Overflow also asked for that feature](https://stackoverflow.com/q/64605981/432681).

(In reply to rugk from comment #2)
> Judging from the screenshots on Twitter, it is both. Surprisingly CSS often seems to be even "less-used" than JS.

That is because the tool only checks the usage of the current page, while some parts of the style sheets may only be used on specific pages of your website. And in CSS you often have things that only work in a specific browser like prefixed properties.

In order to be actually useful, a tool like this needs to

* display general coverage information and possible savings.
* Work for CSS and JavaScript, maybe even HTML (regarding whether the HTML is actually visible to or accessible by the user).
* provide an overview of the coverages of the different sources of the website (preferably including inline sources).
* display which parts of the code of a single source are used and which ones not.
* work across page loads in order to complement the code coverage.
* be able to recognize features only available in specific browsers (e.g. via MDN's browser compatibility data).
* check different situations to be able to recognize whether code within media queries in CSS are used or event handlers in JavaScript are triggered.

So, proper code coverage testing is obviously a very complex topic.

Sebastian
For what it's worth, [someone on Stack Overflow also asked for that feature](https://stackoverflow.com/q/64605981/432681).

(In reply to rugk from comment #2)
> Judging from the screenshots on Twitter, it is both. Surprisingly CSS often seems to be even "less-used" than JS.

That is because the tool only checks the usage of the current page, while some parts of the style sheets may only be used on specific pages of your website. And in CSS you often have things that only work in a specific browser like prefixed properties.

In order to be actually useful, a tool like this needs to

* display general coverage information and possible savings.
* Work for CSS and JavaScript, maybe even HTML (regarding whether the HTML is actually visible to or accessible by the user).
* provide an overview of the coverages of the different sources of the website (preferably including inline sources).
* display which parts of the code of a single source are used and which ones not.
* check whether event handlers and other functions in JavaScript are called. (A relatively simple approach to that is to record activity on the current page. Though that's limited to functions called during page interaction. A more complete but also much more difficult to implement solution would be to programmatically do those checks.)
* work across page loads in order to complement the code coverage.
* be able to recognize features only available in specific browsers (e.g. via MDN's browser compatibility data).
* check different situations to be able to recognize e.g. whether rules within media queries in CSS are used.

So, proper code coverage testing is obviously a very complex topic.

Sebastian

Back to Bug 1430488 Comment 4