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

Re: Proposition to change the prefixing policy

From: Henri Sivonen <hsivonen@iki.fi>
Date: Tue, 8 May 2012 16:23:10 +0300
Message-ID: <CAJQvAufMnDRwTXqjWOXY9P3HJNP=YVL+tePh84YEPUjzK4EUuQ@mail.gmail.com>
To: www-style@w3.org
On Fri, May 4, 2012 at 8:26 PM, Florian Rivoal <florianr@opera.com> wrote:
> I believe the current prefixing policy is hurting more than it helps, and
> that the problems are fundamental to the policy itself, rather than
> something that can be blamed on various parties for not following it
> correctly.

I agree.  In order to get this problem fixed, I think the CSS working
group needs to acknowledge that the policy is flawed since it bears
the kind of fruit that it bears and placing the blame away from the
policy itself doesn't help fix the problem.

> Some have argued that authors should not use prefixed properties in
> production sites.

Arguing that authors shouldn't use something that's made available to
them is a losing proposition anyway.  To keep authors from using
something, it's needs not to be shipped.  Sometimes even that's not
enough and authors enthusiastically start to use features before any
browser supports them.

> When a browser vendor implements a new css feature, it should support it,
> from day 1, both prefixed and unprefixed, the two being aliased. If a
> style sheet contains both prefixed and unprefixed, the last one wins,
> according to the cascade.
> Authors should write their style sheets using the unprefixed property,
> and only add a prefixed version of the property (below the unprefixed
> one) if they discover a bug or inconsistency that they need to work
> around in a particular browser.

I think it makes sense for browsers to ship without a prefix when a
given feature is shipped.  (I think that stuff that isn't "ready" to
be shipped in a release build without prefix shouldn't be shipped in a
release build at all.)

However, I think the part of your proposal that involves shipping also
with prefix is risky is specially in an environment where some Web
authors only care about one engine and are even proud of it.  When
writing engine-specific styling is facilitated with vendor prefixes,
there's no guarantee that offers will only use them to target old
versions of IE and abandoned WebKit snapshots.  The kind of authors
who today only care about WebKit on mobile might continue to write
WebKit-targeted CSS under the model you propose in order to
deliberately serve down-level content to browsers they don't care to
test with.  (Deliberately serving down-level content to browsers--even
WebKit browsers--that authors don't care to test with happens even at
Google; see https://lists.webkit.org/pipermail/webkit-dev/2012-May/020573.html)
Moreover, building a system that allows authors to target legacy
versions would be an overkill for rapidly released browsers.

Furthermore, if the prefix version is there as a one-shot opportunity
to target legacy versions of a given browser engine, vendors would be
disincented from tracking specs through multiple iterations.  On the
other hand, if we believed that tracking specs with prefix through
multiple iterations was OK, surely it would be OK to do it without
prefix and forget the prefix.

On Fri, May 4, 2012 at 9:02 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Several WG members have indicated on numerous occasions that as a matter of
> company policy they are unable to propose something for standardization
> until they have shipped a (prefixed, at the moment) implementation of it.
>  What this means with your proposal is that any ideas they have, no matter
> how half-baked, would have to be dumped out on the web without a prefix
> before they could even start to bring them to the working group.

It looks like you're referring to Microsoft and Apple here.

It's already clear that the current prefixing policy doesn't help
ensure that Apple can't push their stuff unilaterally onto the Web.
As far as the Apple situation goes, I think in retrospect it would
have been better for Apple's competitors if Apple had shipped without
prefix to begin with and the working group had more or less rubber
stamped transforms, transitions and animations.  (I think the
syntactic improvements to gradients don't justify all the trouble from
prefixing and since the changes were grammar-incompatible, the working
group could have changed the syntax the way it did anyway and ended up
with a situation where browsers need to support at most two syntaxes
which seems to be where Opera is headed when it comes to gradients.)

As for Microsoft, we have past experience of Microsoft shipping
features without prefix without the features being standardized first.
 In the case of innerHTML and the like that got rubber stamped later,
everyone is better off that Microsoft didn't use prefixes initially.
As for stuff that failed eventually like VBScript, ActiveX and
attachEvent, I doubt that prefixing them would have significantly
discouraged authors from using them in 1999.

Even though I would like vendors to come forward with proposals in the
working group long before being on the verge of shipping, I think
prefixing doesn't help when vendors won't do that.

>> This doesn't mean that the WG would just be a rubber stand body validating
>> de-facto standards.
> I think this would be the most likely outcome of this proposal, given the
> interactions between shipping and initial standardization proposals
> described above...

Would that be so terrible after all?  I've been professionally
polishing HTML-related after the fact rubber stamped turds for a while
now and most of the time I think that it's better that less than ideal
stuff made it to the market early instead of features staying off the
market so that they could have been perfected during the time away
from market.

On the time to market point, I also think the Web was better off for
CSS 2 being available unprefixed before CSS 2.1 was done. Looking at
what people now consider unfortunate characteristics of CSS, many of
those come from the spec side instead of a vendor jumping the gun:
e.g.  having float, display and position as distinct properties. But I
still think it was better for that stuff to be available unprefixed

On Fri, May 4, 2012 at 9:14 PM, Alan Stearns <stearns@adobe.com> wrote:
> I do not think this would necessarily be the case. Experiments and
> browser-specific features could still be added with a vendor prefix only.

When an experiment is shipped in a release build and supported for
extended periods of time, it's not really an experiment.  It's a real
feature with a weird name.  Can't have the cake and eat it too here.

As for browser-specific features, I think they are antithetical to
interoperability and standardization policies shouldn't cater to them.
 As far as I can tell, browser-specific features fall into the
following categories:

1) Features that are needed for representing legacy oddities that need
to be represented in the UA style sheet.  For example: :-moz-is-html.
Since every UA needs these, these might as well be standardized even
though the benefit for Web authors might be low.  In any case, this
sort of thing does not need to be browser-specific.

2) Features that everyone agrees should be part of the Web but only
one browser has gotten around to implementing so far.  It's bad to
prefix stuff like this, because prefixing means deliberately
sabotaging the interoperability of a feature that everyone agrees that
should be part of the Web.

3) Features that have been proposed with the good-faith expectation
that it's good for them to become part of the Web but so far only to
propose are has implemented them.  If the good-faith expectation is
that the feature will move to category #2 in the future, prefixing the
feature will just cause trouble.  If the feature is rejected, chances
are that having the feature prefixed initially wouldn't significantly
help discourage all first from using it.  To discourage offers from
using a feature, other vendors need to offer an alternative that is
more broadly supported.

4) Features that blatantly expose vendor-specific functionality to the
Web.  I'm trying to recall when this has happened in CSS. The IE
filter property exposed DX filters with a value-side prefixes to such
as "DXImageTransform.Microsoft.", but I don't know the filters well
enough to determine if any of the filters would have been inherently
unreplicable by other vendors.  In any case, I think there shouldn't
be a working group-endorsed mechanism for exposing vendor-specific
functionality to the Web when the functionality isn't in good-faith
proposed to be implemented by every one eventually per case number
three above.

On Fri, May 4, 2012 at 10:19 PM, Ojan Vafai <ojan@chromium.org> wrote:
> I'm really torn on this. On the one hand, the current policy clearly has
> problem of unprefixing too late.  On the other, looking at the latest
> flexbox spec, it wasn't until the preparations for last-call that a bunch of
> naming changes were made.

How is that an argument in favor of prefixing?  If the drafts had been
implemented without prefixes and then all the names had been changed,
the new names would be exactly as non-conflicting with the old names
as in the case where the old names were prefixed.

On Sat, May 5, 2012 at 5:12 AM, Ojan Vafai <ojan@chromium.org> wrote:
> I'd rather we do the same as http headers. Any experimental feature gets an
> x-prefix instead of a vendor prefix.

Even the IETF, which is a super-conservative organization (must use
ASCII-only text paginated for an ancient printer) for whom it is
really hard to get to acknowledge its past mistakes (consider for
example the default encoding for text/* MIME types), is waking up to
realize that x-prefixes where a bad idea:

On Sat, May 5, 2012 at 5:33 AM, Liam R E Quin <liam@w3.org> wrote:
> 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.

Different value spaces are grammar-incompatible and, therefore, the
different versions of the syntax don't conflict any more than
differently-prefixed versions of the syntax.

Check out the source code of
http://mrdoob.com/lab/javascript/webgl/ie/ .  It shows a property
being used with multiple grammar-incompatible values.  Some of the
values of trivially incompatible due to different prefixes but there
are two different -webkit-prefixed values in use as well.

On Sat, May 5, 2012 at 1:20 PM, Daniel Glazman
<daniel.glazman@disruptive-innovations.com> wrote:
> Florian, I think your proposal has one flaw only but that's a pretty
> big one... We introduced prefixes originally to be able to have preview
> implementations potentially differing from the final spec and
> implementations.

It would be nice if the W3C declassified the records of the
discussions that led to the introduction of vendor prefixes so that we
could discuss the original intentions on this mailing list and compare
the intentions with the outcomes publicly.

I think the motivating factor for introducing vendor prefixes is
substantially different from the browser situation that we have now,
but I think I will have to leave it at that and not go into the

On Sat, May 5, 2012 at 6:30 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Yes, that's one of the key problems against a UA unilaterally moving to a
> model where they ship things preffed off by default.  It puts them at a
> competitive disadvantage.  And even if we all agreed to do it, the benefits
> to defecting would be enormous.

As far as I can tell, there would be benefits from defecting from the
current policy.  Kudos to Opera for defecting, but it has taken a
remarkably long time for them to do so and it seems to be hard to get
Mozilla and Microsoft to defect.  I don't know why Mozilla hasn't
defected already, so I can't comment on the mechanism that causes
non-defection, but it evidently looks like vendors won't necessarily
defect from working group policy even when there would be benefits
from doing so.  Thus, it seems that a policy could hold even when
there are benefits from defecting.  (Getting Web authors not to defect
from a policy is hopeless of course.)

Moreover, I think it's a feature that if the working group takes
unbearably long to nail something down when vendors have running code,
vendors defect, ship and make the feature available to authors leaving
it to be polished after the fact like many of the backward-looking
features specced in HTML5 and that have made the Web better off by
being available rather than withheld.

On Mon, May 7, 2012 at 1:49 PM, L. David Baron <dbaron@dbaron.org> wrote:
> On Saturday 2012-05-05 15:02 -0700, Maciej Stachowiak wrote:
>> Properties can be shipped in unprefixed form once both of the following are true:
>> (A) The appropriate standards group (most likely the CSS WG for CSS properties) has agreed to take up the relevant specification as a work item; AND
>> (B) At least two independent roughly interoperable (though not necessarily identical in all edge cases) implementations are publicly available.
> I think this is largely reasonable, except I'd like an opportunity
> to reconsider taking things up as a work item, given its additional
> implications.
> There are some things where I agreed to let them be work items
> despite the opinion that the current spec is harmful, with the hope
> (as yet unfulfilled) that they'd be improved while worked on in the
> group. [1]

If a harmful spec has proceeded to the stage where there are two
independent roughly interoperable implementations and the creators of
those implementations want to ship, is there really any way to put the
cat back into bag by the working group speaking against a feature?
That is, if Maciej's condition (B) holds, isn't the feature pretty
much a done deal anyway to such an extent that it's futile to try to
undo its existence?  Is there a historical example of a case where
condition (B) was true and a W3C working group managed to purge the
feature from the Web platform to such an extent that other vendors
didn't need to implement it and could still successfully render the

Henri Sivonen
Received on Tuesday, 8 May 2012 13:23:44 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:58 UTC