W3C home > Mailing lists > Public > www-style@w3.org > May 2012

Re: Proposition to change the prefixing policy

From: Maciej Stachowiak <mjs@apple.com>
Date: Sat, 05 May 2012 15:12:18 -0700
Cc: Rik Schaaf <coolcat_the_best@hotmail.com>, Florian Rivoal <florianr@opera.com>, "www-style@w3.org" <www-style@w3.org>
Message-id: <4A8B674C-9124-44B0-84B5-7CF13196D20B@apple.com>
To: Ojan Vafai <ojan@chromium.org>

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.

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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:16 UTC