Re: wading into the Prefix morass...

David Singer:
> I do wonder whether it would help us … if we differentiated more clearly between

Yes.

> A) experimental features that vendors introduce, that are truly vendor-specific
> B) 'early' (…)  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 but one of the scenarios.

> so, instead of -webkit-frotz, we might see -css-a-frotz, -css-b-frotz, and so on (as the definition of frotz evolves),

I don’t think versioned prefixes should include arbitrary numbers or letters. The W3C process stages should be enough.

This is what implementers might be telling authors by use of prefixes:

  -VND- We invented it and may use it internally. Don’t use in the wild!
        Similar features may be available in other browsers using
        completely different names and incompatible syntax.

  -pd-  It’s been proposed to the W3C. Try it out in our nightlies.
        Even our prototypical implementation is not stable.
        Syntax will change. You have been warned.

  -ed-  It’s been accepted in general. Syntax may change at any time.
        There might be a WD for it already, but we’re not satisfied 
        with it or haven’t had time for it yet, either way, our
        implementation doesn’t match the most current draft. Like 
        -pd- it’s not available in public releases, but there may be
        an opt-in switch.

  -wd-  It’s probably coming if others like it. Syntax should be stable,
        but may have loopholes; border cases may be ambiguous or vague.
        We make it available in public releases for everyone to test.
        We will drop support for features thus prefixed with the first
        release that follows a Call for Implementation.

Implementers may combine -pd-, -ed- and -wd- as -draft-.

  -lc-  It’s coming if others can implement it. Any upcoming revision
        of syntax will be compatible, so adding it without a prefix
        should be safe, although we don’t support that yet.

  -cr-  It’s defined in a stable draft, but we know our implementation
        still contains bugs or follows an earlier draft. You may use
        it without prefix for other or future implementations.

  -pr-  Basically the same as -cr-.

  -rec- Basically the same as -rec-.

The prefixes -cr-, -pr- and -rec- may be combined into -bugs-.

  -ORG- Some other organization than the W3C / CSSWG specified this
        feature. We try to implement that. You may use it prefixed
        only and should limit it to applications that are in scope
        of that third-party specification. Someday it may be 
        included in CSS proper – no promises. If that happens the
        syntax may or may not be compatible, therefore don not
        include a prefix-less variant already.

Received on Tuesday, 21 February 2012 14:03:19 UTC