Re: Dropping Prefixes Early on Transforms/Transitions/Animations

On Tue, Feb 21, 2012 at 11:35 AM, Simon Fraser <smfr@me.com> wrote:
> I object, on the basis that if browsers support unprefixed properties too early,
> it results in lock-in in potentially incorrect or suboptimal behavior before the
> CSS WG can have a chance to fix it. As Sylvain keeps saying, it is not sufficient
> for just the syntax to be stable; you have to have proven interoperability.

Does the CSS WG really have a chance to fix it after all browsers have
supported it for a while?  Authors will be relying on it, and pages
will break if it's changed.

> Or, imagine that our perspective/flattening discussion had come out a different
> way, and you were able to persuade me that transform-style was unnecessary.
> If we'd already shipped unprefixed, we would not have been able to every change that.

We probably wouldn't have been able to change it anyway.  Too many
pages rely on it.  Likewise, Tab and fantasai have suggested that some
transform functions change to not accept commas between some
arguments, and some implementers objected on the basis that the syntax
was already stable and authors rely on it.

> Premature dropping of prefixes leads to early lock-in, which is not a good way
> to develop standards. The whole point of prefixes is to allow UA experimentation,
> and for authors to provide feedback. If we prematurely drop prefixes, we throw away
> that experimentation phase.

Experimentation is fine, but once you have a significant number of
real webpages depending on the feature, it can no longer be called
experimental.  Features are experimental based on how they're actually
treated, not based on whether we call them experimental.  If browsers
really wanted these features to be treated as experimental, they could
ship support only in betas and disable it for release builds.  Once
they ship in release builds for a while, they're in production, not
experimental.

On Tue, Feb 21, 2012 at 5:20 PM, Sylvain Galineau
<sylvaing@microsoft.com> wrote:
> Yes, that is definitely the risk. But this only leads us back to CSS as it is
> practiced by authors: if you agree that a large-enough majority will include an
> unprefixed version of a new feature in their stylesheet because it's the 'best
> practice' then haven't we already lost the experimentation phase? At least
> when the feature is successful on the web? Fwiw IE never had a prefixed border-radius
> but we saw the feature light up nearly overnight in many pages courtesy of
> future-proofing. (Saved by authors doing it wrong!) And I can see how, in such
> a case, Aryeh and others can argue that anything that forces us to think very
> hard before we go 'fix success' is more a feature than a bug for the people who
> created all that content. Maybe going on a gradient syntax makeover - which I
> approved of at the time, by the way - when there are four broadly compatible
> implementations supporting a lot of content should be a very difficult call.

Precisely.  If the unprefixed property is used widely enough that
changing its syntax would be a problem, then ipso facto we should be
very reluctant to change its syntax.

Received on Wednesday, 22 February 2012 15:37:21 UTC