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

Re: Proposition to change the prefixing policy

From: Ojan Vafai <ojan@chromium.org>
Date: Fri, 4 May 2012 22:02:25 -0700
Message-ID: <CANMdWTvb_QxKR1WbRm3r4VYAf-66tCQxQ22F4_dTUeNU24wO+Q@mail.gmail.com>
To: liam@w3.org
Cc: Rik Schaaf <coolcat_the_best@hotmail.com>, Florian Rivoal <florianr@opera.com>, "www-style@w3.org" <www-style@w3.org>
On Fri, May 4, 2012 at 7:33 PM, Liam R E Quin <liam@w3.org> wrote:

> On Fri, 2012-05-04 at 19:12 -0700, Ojan Vafai 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.
> How does that work if two different browsers have different value-spaces
> for the same property? This seems entirely likely - e.g. they implement
> different drafts, or invent something independently.

Good question. These are the sorts of things that would be more difficult
for both browser vendors and web developers. They would have to work around
it by applying different CSS either through UA sniffing or setting the CSS
with javascript (e.g. via the style property or via the CSSOM).

Alternately, they can just avoid using the feature until it's been
unprefixed and standardized. These are experimental features after all.
It's OK for web developers to have a difficult time using them in rare
cases. Different value-spaces for the same property is rare enough that
it's not worth the enormous costs of vendor-prefixing just to avoid this

Any feature that gets sufficient marketshare can't be killed just because
it happens to have a vendor-prefix. Either we don't ship any prefixed
properties or we live with getting stuck with the ones that gain sufficient
marketshare. Getting specs to CR faster would somewhat alleviate the
problem, but it's a race against web developers adopting the feature in

Received on Saturday, 5 May 2012 05:03:15 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:14 UTC