On 4 Feb 2010, at 07:42, Joshua Street wrote: >> The validator does correctly parse as per the spec. The spec defines a way >> for vendor prefixes to exist without conflicting with anything in CSS, no >> more. This makes them part of the grammar, not the vocabulary, and the >> validator checks both. The CSS 2.1 specification says "Authors should avoid >> vendor-specific extensions". > > I agree vendor-specific extensions do not constitute acceptable > vocabulary, but as the specification allows a grammatical means for > their inclusion it seems counter-productive to flag them as errors.
It provides a means for vendors to experiment without conflicting with real CSS, and for authors to *test* those features. > The specification assures authors and vendors that "An initial dash or > underscore is guaranteed never to be used in a property or keyword by > any current or future level of CSS" - and, accordingly, they are (and > will remain) grammatically permissible / safe for use. The imperative > to avoid these extensions lacks explanation and, while this list is > (by virtue of our name!) perhaps not the place for such views, seems > to stem from the desire to preserve the appearance of standardisation > rather than maximising the utility and flexibility of the standard in > question. The appearance of standardisation? The whole point of vendor extensions is that they are non-standard. Some of them are experimental implementations of standard features, some of them are experimental implementations of proposed features which may appear in future standards, some of them are outright proprietary. They are not standard. > As a counterpoint to this, of course, using standards-compliant > techniques to achieve an outcome will more successfully preserve > interoperability into the future. However, I would assert the advice > to "avoid vendor-specific extensions" should be constrained by this, > rather than suggesting that a guaranteed future-compatible (albeit > potentially no longer functional, contingent on ongoing vendor > support) identifier should be avoided unswervingly. They aren't "guaranteed future-compatible". Vendor: We propose this feature and have implemented this as -vendor-foo Other Vendor: Well, it has these problems, what if ... Vendor: OK. We've changed the way it works. All the slightly older clients supporting the original implementation promptly break. How would this be implemented anyway? Anything that looks like a vendor prefix works? -moz-bowder-wadius: Congratulations! It is "valid"! "But why doesn't it work?" Or does someone try to maintain a list of all the different extensions? The CSS 2.1 specification lists 12 known vendors who use the vendor prefix. Who is going to maintain a central list of all proprietary extensions and the values they accept? How would they be versioned? -- David Dorward http://dorward.me.uk ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *******************************************************************
