W3C home > Mailing lists > Public > public-qa-dev@w3.org > November 2009

Vendor-specific extensions are invalid CSS | 456 Berea Street

From: Karl Dubost <karl@pheromone.ca>
Date: Wed, 18 Nov 2009 13:57:59 -0500
Message-Id: <BDDEAD0B-FFB2-4C30-81FA-150BDE6DD91E@pheromone.ca>
To: public-qa-dev@w3.org
For information

On Wed, 18 Nov 2009 18:56:00 GMT
In Vendor-specific extensions are invalid CSS | 456 Berea Street
At http://www.456bereastreet.com/archive/200911/vendor-specific_extensions_are_invalid_css/

Vendor-specific extensions are invalid CSS

In New W3C website launched I mentioned that the W3C’s new site
uses a bit of invalid CSS. A couple of readers have told me that
the errors caused by vendor-specific extensions aren’t really
errors, and that the CSS validator is wrong to report such
property names as errors.

I wasn’t completely sure about whether or not this was true, so I
did a bit of research. And, to the best of my understanding,
vendor-specific extensions are invalid.
Correct grammar but still invalid

Here is the relevant part from CSS 2.1, currently in Candidate
Recommendation status (emphasis mine):

     A valid CSS 2.1 style sheet must be written according to the
grammar of CSS 2.1. Furthermore, it must contain only at-rules,
property names, and property values defined in this

Vendor-specific extension (mostly) do adhere to the CSS 2.1
grammar, but since they are not defined in the CSS 2.1
specification, they are invalid. Hence the CSS validator is
correct in reporting them as validation errors.
Invalid does not necessarily mean “do not use”

Invalid or not, vendor-specific extensions to CSS can be useful.
And since the CSS specification requires that CSS parsers ignore
declarations with an unknown property, they should also be safe
to use.

The catch is that the CSS validator won’t help you catch typos or
other errors in properties it knows nothing about.
An idea for the CSS validator

When using validation during QA, you have to manually filter out
any errors caused by vendor-specific extensions. How much of a
problem this is obviously depends on how much you use
vendor-specific CSS, but there is no question that it takes
longer than if you could be certain that all errors are “real”

One way around this problem would be for the CSS validator to
have an option to list errors caused by vendor-specific
extensions in a section called “Vendor-specific”, “Experimental”,
or something similar. The validator could then give you a message
like this:

     We found 10 errors, 10 of which are caused by vendor-specific

That way you’ll know right away if you need to take a closer look
at the list of errors or not.

Just an

Karl Dubost - Dev Team Director
« Il doit être modeste mais non de pacotille,
  bon marché mais non fragile. » Soetsu Yanagi
Received on Wednesday, 18 November 2009 18:59:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:54:56 UTC