RE: wading into the Prefix morass...

[Christoph Päper:]
> 
> 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.
> 
> 
I don't see how such a scheme helps authors. If each vendor supports
a different stage of a spec they'll still end up with a bunch of
prefixed versions of the same thing. And now they have to learn about
the standard track and where to find the answer as to which property
takes which value. 

Then you have to remember that vendors keep prefixes around to avoid
breaking content and now browsers support multiple prefixes for the
same feature.

So I'm really not sure I understand what this solves?

Received on Tuesday, 21 February 2012 20:44:19 UTC