CSS Validation and Vendor Extensions: Throw Warnings, Not Errors

Published on June 26, 2010 (↻ June 10, 2021), filed under Development (RSS feed for all categories).

If you understand valid code as a quality baseline, you validate your code. If you validate style sheets, you come across errors like:

These should be warnings, not errors.

Two reasons.

1. CSS validators should check for correct syntax. The syntax in this case, and in fact most vendor-specific extensions out there, is correct.

2. Vendor-specific extensions are a reality. There is no advantage in ignoring this reality, or making it harder for web developers to make sure their style sheet code respects at least the syntax of CSS.

This is not a case against standardization; it is a case for opening the eyes. We don’t do web developers a favor by reporting non-standardized but syntactically correct and practically necessary properties and values as errors. This is especially true for those who got under the influence of hardcore standardistas.

A strong believer in open standards and standardization, I still avoid anything proprietary in my code. I recognize the opportunities and sometimes necessities of vendor-specific extensions though. And following, and working hard to have followed, maintainability best practices I’m less concerned about maintaining and keeping clean style sheets, than about false positives that deflect from more important things.

Not the first one to write about this, not the last one to ping www-validator-css@w3.org either.

Update (June 28, 2010)

Consider following or joining the conversation on www-validator-css@w3.org for more detail.

Update (December 31, 2010)

Fellow Googler Cyrille Moureaux and I worked to get this fixed. We have a patch ready, to actually throw warnings. We’re now figuring out how we can get the validator updated.

Update (2011)

Some time in early 2011 we got the validator patched and the issue fixed.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)

Comments (Closed)

1. On June 26, 2010, 7:26 CEST, Dan Zollman said:

   I looked at a couple of the earlier discussions on the W3 list (not all of them), and although the reasons for the current validation scheme make sense, it seems completely reasonable to change these from errors to warnings.

   If they were to change this by providing new validation options (whether through a new profile or through another setting) I think it would make sense for the option to allow checking for “correct syntax” in general, rather than having something that makes an exception for vendor-specific properties in particular.

   For example, let’s say there’s a proprietary unit that is used instead of px or em. A stylesheet using those units would be invalid even if it uses correct syntax, so this hypothetical validator setting would permit fictional units. Maybe that’s going too far since it doesn’t reflect common practice and this kind of thing isn’t recognized in the spec…but in theory, there could be other proprietary customizations, aside from properties, that don’t break syntax rules. What do you think?

2. On June 26, 2010, 12:49 CEST, Keith said:

   I agree, Jens. Although vendor-specific extensions are not part of the standard language of CSS, the fact that the W3C has expressly permitted them in the specification means that the validator should not classify their use as an error if they are syntactically correct—particularly since a conforming CSS parser that does not understand an extension will simply ignore it.

   Throwing up a warning does seem like a fair way for the validator to treat these extensions, if only to remind CSS authors that they have included them, and to say, “Did you really mean that? Have you got all the details correct, because I can’t check them for you.”

   If they are syntactically incorrect, then yes, the validator should report an error.

3. On July 1, 2010, 11:53 CEST, Dave Smith said:

   I agree too. It was surprising and a bit confusing to receive errors for vendor-specific extensions when the syntax was correct.

   Throwing a warning makes sense. Just wondered though, What if a valid occurrence throws a “vendor extension” instead?

   They could be listed below errors and above warnings. With specific information and guidelines relating to the use of vendor extensions.

4. On October 6, 2010, 18:22 CEST, Radomir Dopieralski said:

   It would be even more awesome if it actually displayed a warning when you have a vendor-specific rule for one browser, but not for others (this would need to be constantly updated, of course, so it’s not exactly a low hanging fruit, but still awesome).

5. On November 24, 2010, 20:36 CET, virusescu said:

   I don’t quite agree. Validation of ’standardized’ code (which i think is what w3c is seeking) must not merely include only syntax checking.

   I expect an error free code, in any language, to output the same results no matter the system that is able to run the code.

   Let’s suppose you have some javascript class, with some methods that do some algebraic equations. But, you don’t have the latest version which lacks some methods.

   Your code would run smoothly with the latest version and has a correct syntax. Wouldn’t you expect an error generated by the lack of one function even though the code has a perfect syntax?

   I get it that CSS is just a view language and such code degrades mostly harmless and sometimes pretty nice if the developer is good, but the validity of one’s code, especially from the, “standard CSS”’s point of view, can not be a subjective issue.

   True enough. This kind of ‘messages’ are a big frustrations generator. “I know how it looks if some shitty browser does not interpret that rule!!!” one might say to one’self.

   Though… I think that even if any non standard code should still be marked as errors, as a workaround, it should be placed in separate CSS files. The validator validates ’standard code’ and not ’sintactically correct code’. Vendor specific code is against standardization and is exactly this kind of vendor-superiority from the past that generated most of the crossbrowser mayhem.

   We shouldn’t encourage vendors by promoting a non standard rule from error to just warning. If we love standards, this is exactly how such a rule must be treated: as an error.