Policy for experimental CSS features in Gecko

Showing 1-8 of 8 messages
Policy for experimental CSS features in Gecko L. David Baron 6/1/12 3:42 PM
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/   𝄂
Re: Policy for experimental CSS features in Gecko Sheppy 6/1/12 4:26 PM
I for one love this plan, it would be incredibly useful for the docs
team to have a better idea of which new CSS features are likely to be
considered "done" and when.

Sheppy
Re: Policy for experimental CSS features in Gecko Scott Johnson 6/2/12 9:53 AM
David:

One comment/question I have about this:

> 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.

Does this mean that if the implementations are different, we wouldn't
ship the feature unprefixed? I'd like to think that if, for example, our
implementation of column-span (we don't currently implement this), if
it's different that say Opera, which is, in turn, different than
Trident's implementation, this would be a good reason to leave it prefixed.

Also, what does it mean for features as they are developed? If, for
example, we choose to implement column-span, which is also implemented
by Opera, Trident, Webkit, etc... are we going to land these unprefixed
immediately, or is there some kind of "breaking in" period, where the
feature will still be prefixed?

~Scott


On 06/01/2012 05:42 PM, thus spoke L. David Baron:
Re: Policy for experimental CSS features in Gecko Jason Smith 6/3/12 9:23 PM
Hi David,

I do like the concept presented here, as Gecko would drive in the direction of preventing deployment of too many prefixed CSS properties. But will this align with what the development of other layout engines will do? I'm all for trying to take initiative on our end for gecko, but a strong need to make this plan successful would need development of other layout engines, specifically webkit, to follow suit. Otherwise, we could end up in a situation where other layout engines such as webkit could continue heavily building up prefixed-based properties still, causing the gap between gecko CSS support vs. webkit CSS support to get larger overtime, even if those webkit properties were prefixed. This could result in situations where say, I the web developer, want to take advantage of a lot of webkit's prefixed properties and build a site to reflect that. But gecko would have a smaller feature set, so I may not be able to build the site I built on webkit - could that lead to user agent sniffing happening?

Sincerely,
Jason Smith
Re: Policy for experimental CSS features in Gecko Jason Smith 6/3/12 9:23 PM
On Saturday, June 2, 2012 12:53:17 PM UTC-4, Scott Johnson wrote:
Re: Policy for experimental CSS features in Gecko Henri Sivonen 6/4/12 5:10 AM
On Sat, Jun 2, 2012 at 1:42 AM, L. David Baron <dba...@dbaron.org> wrote:
> (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.)

At present, I think that is more of an issue for APIs than for CSS.

> Proposed (strawman) policy for experimental CSS features in Gecko

Thank you. I support this policy for CSS.

I think we also need a policy that avoids prefix proliferation in APIs
on the release channel. Should I express opinions about that in this
thread or refrain from doing so in order not to derail discussion
about the policy specific to CSS?

On Sat, Jun 2, 2012 at 7:53 PM, Scott Johnson <sjoh...@mozilla.com> wrote:
> I'd like to think that if, for example, our
> implementation of column-span (we don't currently implement this), if
> it's different that say Opera, which is, in turn, different than
> Trident's implementation, this would be a good reason to leave it prefixed.

More to the point, that would be a good reason not to ship it in the
beta or release channels.

> Also, what does it mean for features as they are developed? If, for
> example, we choose to implement column-span, which is also implemented
> by Opera, Trident, Webkit, etc... are we going to land these unprefixed
> immediately, or is there some kind of "breaking in" period, where the
> feature will still be prefixed?

Since the feature wouldn't reach the beta and release channels under
this policy before it's interoperable, I think it would be okay to
land work in progress without a prefix on trunk. That would make it
easier to test the work in progress against test suites.

On Mon, Jun 4, 2012 at 7:23 AM, Jason Smith <jsm...@mozilla.com> wrote:
> But will this align with what the development of other layout engines will do? I'm all
> for trying to take initiative on our end for gecko, but a strong need to make this plan
> successful would need development of other layout engines, specifically webkit,
> to follow suit.

I think the best way to get other layout engines to follow the same
policy would be for us to adopt the policy first. It's worth noting
that there are people in the Chrome team who are sympathetic for
problems caused by -webkit- prefixes, Opera is acutely aware of the
problems prefixes are causing for them and Microsoft also sees the
problems to an extent that has caused them to deviate somewhat from
the (in my opinion flawed) CSS working group policy on unprefixing:
"With the Release Preview of Windows 8, IE10 adds support for
non-vendor prefixed versions of standards that have reached Candidate
Recommendation (CR) status since the Windows 8 Consumer Preview or
***should reach CR in 2012***." (emphasis mine, source:
http://blogs.msdn.com/b/ie/archive/2012/05/31/windows-release-preview-the-sixth-ie10-platform-preview.aspx
).

> Otherwise, we could end up in a situation where other layout engines such as
> webkit could continue heavily building up prefixed-based properties still,
> causing the gap between gecko CSS support vs. webkit CSS support to
> get larger overtime, even if those webkit properties were prefixed.

If we adopt this policy but Apple doesn't, I think there are two ways
to proceed and they aren't mutually exclusive:
1) Call Apple on using the fragmentation that prefixes create as a
source of competitive advantage that's unhealthy for the Web (for this
to be credible, we need an anti-moz-prefix policy for the WebAPI
effort, too)
2) Add -webkit- aliases to Gecko.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Re: Policy for experimental CSS features in Gecko Aryeh Gregor 6/5/12 1:54 AM
On Saturday, June 2, 2012 1:42:44 AM UTC+3, L. David Baron wrote:
> Below I've written a draft of a proposal that I think will help with
> this.

I'm strongly in favor of this proposal.  I think it gets everything essentially right.  A feature that's shipping in two other engines is close to a de facto standard and should almost surely be shipped unprefixed.  We also need the ability to selectively ship features that only one other engine implements -- in practice, this will mostly be when WebKit innovates and we don't want to wait on IE/Opera.  We should never be shipping something that no one else has implemented.  So I think this gets everything right.

Is there any reason this policy shouldn't be applied to DOM features too?
Re: Policy for experimental CSS features in Gecko Aryeh Gregor 6/5/12 1:54 AM
On Saturday, June 2, 2012 1:42:44 AM UTC+3, L. David Baron wrote:
> Below I've written a draft of a proposal that I think will help with
> this.