Bug 9687 – WebKit needs to log CSS errors (like FireFox & FireBug do)

• Component: CSS
• Status: RESOLVED FIXED

[Eric Seidel (no email)]

WebKit needs to be able to log CSS errors (like FireFox & FireBug do)

These should be logged any time a declaration is dropped, or a value is ignored.

[Eric Seidel (no email)]

I looked at this very briefly.  I would need to talk to hyatt to better understand where we might hook in.

There are several places where you might want to throw CSS-related error messages, not all of which should have the same error information.

Two examples:
1. parsing a stylesheet for a page.
2.  setting a style value via javascript.

Firefox handles case 1 quite nicely, but case 2 very poorly (it shows a useless error message).  Ideally we would design a system to work across most if not all of the cases where the CSS parser should "throw errors".

[Dave Hyatt]

Errors basically break down into two classes I think...

(1) Errors that bison would catch, e.g., bad tokens, bad combinations, etc.

(2) Errors that cssparser.cpp would catch, i.e., grammatically well-formed properties that are simply illegal (wrong unit types, wrong # of arguments, etc.)

(1) is pretty hard, since we often don't even handle those errors well for real. :)
(2) is easier and probably where you'd get more bang for your buck anyway.

See also bug 7296.

[Eric Seidel (no email)]

Created attachment 12000 [details]
A hack to make this possible

I don't really expect anyone to take this patch seriously.  However it does address the issue at hand (and hopefully could start some small dialog on the subject).

[Alexey Proskuryakov]

Do we also want to distinguish errors, warnings and messages, as Firefox does?

[Alexey Proskuryakov]

Actually, this patch seems to match bug 10361 better.

[Geoffrey Garen]

Doesn't this patch mean "only log JS errors?"

[Eric Seidel (no email)]

Personally, I find Firefox's logging system a bit overly geeky.  The point of only logging JS errors in my hack-patch, was to maintain the status-quo, as logging more than that might be a "UI decision".

[Darin Adler]

Comment on attachment 12000 [details]
A hack to make this possible

This doesn't seem necessary. I suggest we start logging more on the console, and later add levels and/or types based on our experience using the console.

[Timothy Hatcher]

*** Bug 14358 has been marked as a duplicate of this bug. ***

[Blaze Burg]

CSS errors and warnings are logged to console and highlighted in the CSS text editor in the current inspector.

[Simon Fraser (smfr)]

But not nearly enough of them. I think we only log syntax errors, right, and then only property names?

What about:
* invalid values
* meaningless combinations of properties (e.g. z-index on non-positioned)
* things with perf impact (negative text-indent without overflow:hidden)

[Blaze Burg]

Some invalid values are shown as crossed out in the CSS details sidebar, IIRC. The other things sound like audits to me. (I agree we need new audits, but each one in a separate bug.) In any case, I'm not sure that blasting the console with these errors/warnings is the right thing to do. Even with just parse errors today, the console gets filled with junk on popular websites.