info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Policy for experimental CSS features in Gecko
966 views
Skip to first unread message
L. David Baron
Jun 1, 2012, 6:42:44 PM6/1/12
to dev-pl...@lists.mozilla.org
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/ 𝄂
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/ 𝄂
Sheppy
Jun 1, 2012, 7:26:46 PM6/1/12
to
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
team to have a better idea of which new CSS features are likely to be
considered "done" and when.
Sheppy
Scott Johnson
Jun 2, 2012, 12:53:17 PM6/2/12
to L. David Baron, dev-pl...@lists.mozilla.org
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:
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.
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:
Jason Smith
Jun 4, 2012, 12:23:49 AM6/4/12
to mozilla.de...@googlegroups.com, L. David Baron, dev-pl...@lists.mozilla.org
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
Jason Smith
Jun 4, 2012, 12:23:49 AM6/4/12
to L. David Baron, dev-pl...@lists.mozilla.org
On Saturday, June 2, 2012 12:53:17 PM UTC-4, Scott Johnson wrote:
Henri Sivonen
Jun 4, 2012, 8:10:03 AM6/4/12
to dev-platform
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.
> (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.)
> Proposed (strawman) policy for experimental CSS features in Gecko
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.
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?
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.
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.
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/
Aryeh Gregor
Jun 5, 2012, 4:54:53 AM6/5/12
to dev-pl...@lists.mozilla.org
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.
> Below I've written a draft of a proposal that I think will help with
> this.
Is there any reason this policy shouldn't be applied to DOM features too?
Aryeh Gregor
Jun 5, 2012, 4:54:53 AM6/5/12
to mozilla.de...@googlegroups.com, dev-pl...@lists.mozilla.org
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.
> this.
0 new messages