RE: Unprefixing CSS properties

Side proposal:  CSSWG should probably make a wiki page so people can easily add the newest observations or proposals to a common location, since this seems to come up at least once a month.


If it’s not ready to CR, it’s not ready to unprefix.  I thought that was the general working model of the CSSWG.

Consequently, if you “really want” to unprefix then the focus should be on working with the WG to bring those specs to CR.

That might mean moving the “not ready” parts to “next” (3 to 4, 4 to 5, etc.) so they don’t hold up the “ready” parts.  It might mean splitting modules into smaller pieces as well.

Sidestepping the system because it’s inconvenient produces harm in the near term and long term as well as potentially the really long term (box-model width example).

Perhaps I’m misunderstanding the proposal.


Looking down your list...

·         WD 2009/12 - http://www.w3.org/TR/css3-2d-transforms/


o   ED 2011/09

·         WD 2009/03 - http://www.w3.org/TR/css3-3d-transforms/


o   ED 2011/03

·         WD 2009/12 - http://www.w3.org/TR/css3-transitions/


o   ED 2011/07

·         WD 2009/03 - http://www.w3.org/TR/css3-animations/


o   ED 2011/07

·         WD 2011/09 - http://www.w3.org/TR/css3-conditional/


o   ED 2011/10

·         WD 2011/09 - http://www.w3.org/TR/css3-images/


o   ED 2011/11

·         WD 2011/09 - http://www.w3.org/TR/css3-text/


o   ED 2011/10

·         WD 2011/09 - http://www.w3.org/TR/css3-values/


o   ED 2011/10

·         WD 2011/09 - http://www.w3.org/TR/2011/WD-selectors4-20110929/


o   ED 2011/11

It looks like all of these modules have gotten attention in the last 5 months, with the exception of 3D transforms.  And I’m pretty sure 3D transforms will get an edit sometime soon to catch up to a syntax change that was made for 2D transforms (Jennifer/Simon thread).

Just skimming some of the others...

·         transitions – the timing function property has an expanded grammar in ED relative to WD

·         animations – the timing function property has an expanded grammar in ED relative to WD

·         images – significant grammar changes proposed for radial-gradient; variety of changes in other sections

Evaluating that small sampling alone, I would argue that unprefixing is premature.



One could also make another argument...

Perhaps the prioritization should be on bringing the current set of CRs to RECs by bringing the test suite and implementations to quality and depth supporting that upgrade.
http://www.w3.org/TR/tr-status-all#tr_CR

http://www.w3.org/TR/tr-status-all#tr_LCWD

After that’s achieved, I’d bet that many of the current WD/ED specs will have reached LC/CR.
http://www.w3.org/TR/tr-status-all#tr_WD



In addition to trimming the breadth of active, non-REC specs, this would help in stabilizing the foundation that the newer specs are building upon.

Granted the shiny new toys are more fun to unwrap than the old toys...

-Brian

From: Charles Pritchard [mailto:chuck@jumis.com]
Sent: Tuesday, November 15, 2011 8:26 PM
To: robert@ocallahan.org
Cc: www-style
Subject: Re: Unprefixing CSS properties

I echo the sentiment; I've brought up a fast-track concept to webkit-dev before but it was unresolved.

I do have an issue with transforms... And I never expected to.

Object, embed and iframe have had unreliable behavior with CSS transforms.

WebKit broke, then fixed iframe. Chromium is reporting that the Pepper API will fix embed and object, but the old API (NPAPI?) isn't going to be salvaged.

Anyway, that's my concern on it. I'm fine considering it a bug in implementation when transform doesn't work as expected on those tags.

-Charles


On Nov 15, 2011, at 8:02 PM, "Robert O'Callahan" <robert@ocallahan.org<mailto:robert@ocallahan.org>> wrote:
Web authors have complained a lot about excessive need for vendor prefixing. Henri Sivonen has recently blogged about the damage prefixing can do to the Web --- see http://hsivonen.iki.fi/vendor-prefixes/.


One observation is that when browser vendors already agree closely on the syntax and semantics of a property, and when Web authors routinely use the same property value for multiple engines' prefixed properties and the unprefixed property, in public Web content, vendor prefixes are providing negligible benefit and incur considerable costs --- or outright harm. I think we can improve the situation in the short term with relatively low risk by identifying properties whose specs are not yet in CR, but where the spec is considered stable (but for whatever reason not ready to enter CR, perhaps because it contains other properties that aren't stable), and agreeing to encourage unprefixed implementations of those properties. Naturally we still want implementations to be reasonably conformant before shipping unprefixed.

We had a meeting about this with some Mozilla developers today and came up with a proposed list of properties/features which we think are eligible for unprefixing:

2D Transforms: all properties
3D Transforms: all properties
Transitions: all properties
Animations: all properties (responses to feedback urgently need to be added to the spec, and that should probably happen first)
Conditional: nested @-rules (probably no-one would have prefixed this anyway)
Images: image() value, 'object-*', 'image-*'
Text: 'tab-size', 'hyphens', 'text-align-last', 'text-decoration-*'
Values: a subset of calc() (the intersection of what IE9 and Gecko implement), the new units
Selectors 4: :matches, :any-link, :nth-match, :nth-last-match, :column, :nth-column, :nth-last-column

Any objections? :-)

Rob
--
"If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us." [1 John 1:8-10]