Re: Proposition to change the prefixing policy

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.

Regards,
Maciej

Received on Saturday, 5 May 2012 22:12:45 UTC