- From: David Dorward <david@dorward.me.uk>
- Date: Sat, 26 Jun 2010 17:55:57 +0100
- To: Jens O. Meiert <jens@meiert.com>
- Cc: www-validator-css@w3.org
On 26 Jun 2010, at 17:24, Jens O. Meiert wrote: >> They are still errors, and authors are still advised not to use them. > > Where does the spec say that vendor-specific extensions should result > in errors on validation? (The parsing error section [1] doesn’t, > correct me if I’m wrong.) They aren't parsing errors, they conform to the syntax. They are properties that are not specified by CSS 2.1 (or any other profile supported by the validator.) Since the validator reports properties that are not specified by CSS as not existing, there is no reason to exclude vendor properties. > How is the “should” in “[a]uthors should avoid vendor-specific > extensions” to be understood if not as an RFC 2119 “should” [2,3], and > how does this “should” then require errors on validation? The reverse is also true. > And even if that is all fine, what is the precise benefit of this approach? It avoids giving the appearance of blessing proprietary extensions, and it saves the very small validator team from having to invest any of the small amount of time they have to devote to the CSS validator in trying to track a big stack of properties which are not documented by the W3C but, if they are publicly documented at all, but more then half a dozen third parties in various locations without any documentation standard. Of course, the validator could just accept any property starting with a dash as "OK", but then people would be complaining that it was blessing -moz-bowder-radius and -opacity: o. -- David Dorward http://dorward.me.uk
Received on Saturday, 26 June 2010 16:56:35 UTC