On Thu, Feb 4, 2010 at 6:16 PM, David Dorward <da...@dorward.me.uk> wrote: > On 4 Feb 2010, at 03:29, Joshua Street wrote: >>> The prefix may be "part of it" to address parsing issues, but - afaik - that >>> does not make these extensions CSS properties. >> >> Indeed - yet therein lies the frustration at the validator failing to >> correctly parse as per spec. > > 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. 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. 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. So I guess my problem is with the language of the specification as much as with the validator - but I feel there is probably enough ambiguity in the specification around this (i.e. why introduce a feature only to advise authors to avoid implementations applying this feature?!) that the validator should, on the basis of grammar, accept flexible vocabulary following this dash (-) or underscore (_) prefix. There are good, pragmatic reasons for both approaches - but erring on the side of flexibility here does nothing to damage the abilities of compliant user-agents, or the fabric of the standards-based web. Particularly in seasons where we wait for finalisation of good and important features into usable, non-draft-form standards, the validator's interpretation remains unhelpful. -- Josh Street http://josh.st/ +61 (0) 425 808 469 ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *******************************************************************
