Re: Proposition to change the prefixing policy

On Sat, May 5, 2012 at 3:12 PM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> On May 4, 2012, at 7:12 PM, Ojan Vafai <ojan@chromium.org> wrote:
>
> > Since we're throwing proposals out there...
> >
> > I'd rather we do the same as http headers. Any experimental feature gets
> an x-prefix instead of a vendor prefix. That does mean that x-prefixed
> features that get wide adoption may need to be reverse engineered by other
> vendors and can't be killed. In practice that's not much different from
> what happens now. The x-prefix also means that web developers don't need to
> wade through vendor-prefix soup. There may be some incompatibility between
> different vendors x-prefixed implementations that will be a burden on web
> developers and browser vendors, but the unprefixed version can be made
> interoperable. In practice web developers already have to deal with the
> same pain with incompatible vendor-prefixed implementations, but browser
> vendors are more able to not feel responsible to address it.
> >
> > In that world, removing the prefix at CR seems fine to me. It doesn't
> carry any of the problems of long-lived vendor-prefixed properties and
> gives the WG the necessary time to really solidify the spec before removing
> prefixes.
> >
> > There's no perfect solution to this problem. But the downsides of
> x-prefixing are much milder than the downsides of vendor-prefixing IMO.
>
> x-prefixing seems to result in x-prefixed http headers or MIME types
> becoming de facto or in some cases even de jure standards. At that point,
> x- loses all meaning, and x-prefixing becomes basically the same as not
> prefixing at all. While I don't really support either x-prefixing or no
> prefixing ever, I would prefer a total lack of prefixing to not prefixing
> at all.
>

How is this different from vendor-prefixing? Any vendor-prefix that gains
enough marketshare becomes the de facto standard, as evidenced by the
webkit-prefixed properties that other browser vendors are (considering)
implementing. This is especially true when one rendering engine has
sufficiently large marketshare (i.e. WebKit in mobile).

I don't think any of the proposals in this thread would have avoided this
issue either. By the time there were two interoperable implementations of
many of these properties, the damage had already been done. In fact, even
if we were shipping these features unprefixed now, I expect most authors
would still be using the webkit-prefixed versions because they'd rather
support old iOS/android than non-WebKit browsers. While it's true authors
could include the webkit-prefixed and the unprefixed versions, a
sufficiently large percentage of them won't out of ignorance.

I don't think the x-prefix loses all meaning because in rare cases it
becomes the de facto standard. In cases where it doesn't get sufficient
marketshare, we can kill the x-prefixed version (or leave it in, but not
bother standardizing it and getting other vendors to implement it). Also,
in all cases, if we find issues with the syntax/values/name of the
x-prefixed property, we have an opportunity to fix it with the unprefixed
version.

Again, I don't see how vendor-prefixing is an improvement on x-prefixing.
It just adds complexity.

That said, whether we x-prefix or vendor-prefix, I agree with the rest of
the thread that two "roughly interoperable" implementations is a reasonable
point to unprefix the *properties* that are interoperably implemented. I
emphasize properties there because I think it's rare to get two roughly
interoperable implementations of an entire specification.

Ojan