Re: Vendor-specific extensions: warnings, not errors

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 UTC