wading into the Prefix morass...

I do this with all appropriate humility, and aware that I may be inviting flame-throwers pointed my way…


I do wonder whether it would help us, and the web community, if we differentiated more clearly between

A) experimental features that vendors introduce, that are truly vendor-specific
and
B) 'early' (before spec. stability)  implementations of specifications that are in process at the W3C.

It doesn't seem to help the web community much to ask them to write N similar 'vendor-specific' constructs for case (b), when, in fact, they are all (trying to) implement the same specification.

This is what led to me wondering (a few emails ago) if we could usefully use draft-specific prefixes for features, and only change the prefix if the parsing had to change.  I agree, it makes life harder for the spec. author (you have to think: do I need to change the 'draft prefix' as a result of this edit?) but it makes life way easier for the web developer.  And it removes the ugly temptation to implement another vendor's prefix; you don't, you implement the 'draft' prefix.

so, instead of -webkit-frotz, we might see -css-a-frotz, -css-b-frotz, and so on (as the definition of frotz evolves), with some final definition being -frotz and equivalent to -css-r-frotz (well, I hope we don't have 'r' revisions of anything).

I use -css- to suggest "the definition currently 'belongs' to the CSS WG", and the lack of it to say "it's now owned by the whole wonderful world and its web"…





David Singer
Multimedia and Software Standards, Apple Inc.

Received on Monday, 20 February 2012 19:46:38 UTC