There's been a lot of discussion lately about vendor prefixes in CSS.
The benefits of prefixes are, in theory:
1. that they prevent vendor experiments from using up the namespace
that CSS standards can use
2. that they make vendor-specific styles easily noticeable within a
style sheet
In particular, there have lately been problems resulting from
widespread use of vendor-prefixed CSS on the Web (which in turn is
the result of things not moving quickly enough to being unprefixed):
1. either:
(a) authors have to deal with the pain of writing things
multiple times for different vendors, or
(b) authors write for only one vendor and implementations feel
the need to implement other vendors' prefixes because of
content written specifically for that vendor
2. either:
(a) authors write the unprefixed version and cause the namespace
pollution that prefixes are designed to prevent, or
(b) authors don't write the unprefixed version, which prevents
browsers from later removing support for the unprefixed
version, and means that any future browsers will have to
support at least one of the prefixed versions
Henri has written more about this at
http://hsivonen.iki.fi/vendor-prefixes/
I agree with him that we need a solution that leads us to prefixes
being used much less on the Web.
Below I've written a draft of a proposal that I think will help with
this. I see this as a piece of a larger solution for how we should
interact with other vendors, though. I also think, for example,
that if we like most of what another vendor has proposed but believe
some aspects should be change, we should implement it with the
changes that we want until we can come to an agreement in a
standards body (rather than implementing what they've proposed and
then arguing for changes).
I think it's important that we come up with a policy that we'd
encourage other browser vendors to adopt as well, and be comfortable
with the results if they did (even if, say, they want to push the
rules to the limit to try to force certain technologies on others).
I'm not strongly attached to the particular rules I propose here; in
fact I think some of them may be too loose. I'm a little more
attached to (though still also not entirely sure about) the approach
that we want to think separately about what the criteria should be
for making features non-experimental based on:
1. whether other major browser engines have shipped them
2. whether other major browser engines have implemented them (this is
now different if we start not shipping, or not exposing to Web
content, things that we consider experimental)
3. possibly (though I'd prefer not) based on other factors
(I'd like to say a little more about (3) here: some would argue that we
might need to add features to the Web because we feel the Web platform
has a critical need for this feature immediately. However, I'd argue on
the flip side that if the Web platform has a critical need for this new
feature, shipping it in only one browser engine isn't actually going to
help. It needs to be shipped across browser engines. If, on the other
hand, we're talking about content that doesn't need to work across
browser engines, then we're not talking about the Web, and what we do to
support that content shouldn't affect the decisions we make for the
Web.)
-David
Proposed (strawman) policy for experimental CSS features in Gecko
=================================================================
Side note about experimental CSS features we currently ship:
We will continue shipping most or all of the experimental CSS
features that we currently ship. Our goal will be to either (a)
ship them without prefixes and drop support for the prefixed
features or (b) drop support for the features. However, the way
we achieve that is not covered by this policy, although it is
likely to be influenced by this policy. This policy is primarily
about new features going forward.
We intend to continue developing experimental CSS features and
shipping them to the nightly and aurora channels. For the time
being we will continue doing this with prefixes, although once we
establish the pattern of doing this we may consider dropping
prefixes.
We will no longer ship new implementations of experimental CSS
features to the beta or release channels, except in the following
cases (where in both cases "interoperable" means ignoring any
differences in prefixing, but otherwise isn't particularly carefully
defined):
1. If two other engines ship interoperable implementations of an
experimental CSS feature that we also implement, we will also
ship it (without prefixes) unless there are good reasons not to
do so. Reasons related to the feature's stage or state in any
standardization process will not be considered.
2. If one other engine independently implements (but not
necessarily ships) an interoperable implementation of an
experimental CSS feature that we also implement, we will
consider shipping it (without prefixes). We will consult the
CSS working group before doing so, and will consider technical
objections raised. Reasons related to the feature's stage or
state in any standardization process will not be considered.
3. The CSS Working Group has said the feature is stable and ready
to be shipped.
When we are the first to implement or the first to ship a new CSS
feature we will make a serious effort to shepherd it through the
standards process, including work on both specification and test
suite. We expect to share this work with others advocating for,
implementing, or shipping the same feature, particularly when
another engine is the first to implement or first to ship, or does
so around the same time. Note that the act of shipping does not
remove the need to standardize the features that the Web depends on.
We will encourage other browser engines to adopt the same policy.
--
𝄞 L. David Baron
http://dbaron.org/ 𝄂
𝄢 Mozilla
http://www.mozilla.org/ 𝄂