Suggestion for improvement of output from the W3C CSS checker

I have .css files, for example details.css, that have an @import "common.css" at the start. The common.css file contains a data: URI that has contents about 3.7kB long. Recent versions of the CSS checker now crash, with a caught exception, if these strings exceed 2048 bytes in length. This means that I can’t use the CSS checker any more, not without temporarily mutilating the main file, eg details.css, to temporarily remove the @import. This is not the bug I wish to report here, as that bug has, I believe, already been reported.

I wasted a lot of time trying to work out what was going on when this bug was introduced in a recent CSS checker version because I couldn’t see that the crash was triggered by the _content_ of my @import "common.css". I wasn’t even aware that the checker scans the contents of @imported files. I can’t see a mention of this anywhere. 

1. scanning the contents of @imports should be an option; a tickbox when you start your scan.
2. Error messages should include the line number _within the @imported file_ and also the filename of the file where the error is found.

I simply got a useless message saying that there was an exception caught, at line 1 in my details file, but it didn’t tell me that the problem was _inside_ the @import, nor where it was within the @imported file.

I’m not sure of the need to scan the contents of @imports. But if this is made an option then everyone is happy. However for example if the checker at some point detects undefined CSS var() variables, then cases where the variable is defined in the @import and used in the main file will need the @import to be scanned. That would be a very nice improvement, to detect for example cases where the name of the reference to a var() variable is misspelled.

Cecil Ward

Received on Thursday, 12 March 2026 09:35:44 UTC