W3C home > Mailing lists > Public > www-validator-css@w3.org > June 2010

Re: Vendor-specific extensions: warnings, not errors

From: Jens O. Meiert <jens@meiert.com>
Date: Sun, 27 Jun 2010 21:04:00 -0700
Message-ID: <AANLkTimBbaQr4RJKFz_rcVVhEQ2Y_Mu8LntxdHptFF0W@mail.gmail.com>
To: David Dorward <david@dorward.me.uk>
Cc: www-validator-css@w3.org
Now it seems we’re having a conversation—thanks David :)

> They aren't parsing errors, they conform to the syntax.
>
> > 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.

If we can agree on that the statement does not per se require to
throws errors that would work well for me.

> > 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.

That would solve the maintenance problem on the validator team end
though, right?

Why wouldn’t a warning, clearly stating that “vendor-specific
extensions got found and have only been checked for syntactic
correctness”, mean a viable alternative? From my perspective it does,
and means a win for everyone involved.

-- 
Jens O. Meiert
http://meiert.com/en/
Received on Monday, 28 June 2010 04:04:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 June 2012 00:14:26 GMT