W3C home > Mailing lists > Public > www-style@w3.org > February 2012

RE: Dropping Prefixes Early on Transforms/Transitions/Animations

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Thu, 16 Feb 2012 00:58:13 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>, www-style list <www-style@w3.org>
Message-ID: <3C4041FF83E1E04A986B6DC50F01782903428F51@TK5EX14MBXC295.redmond.corp.microsoft.com>
[Tab Atkins Jr.:]
> 
> Tantek proposed during the conf call (and I proposed during the f2f, and
> roc proposed 6 months ago on the list...) dropping the prefixes for
> Transforms/Transitions/Animations (hereafter "TTA") early, while we work
> to advance the spec normally (but quickly).
> 
> The major objector to this proposal was Sylvain, who argued that if we can
> get TTA to CR in 2-3 months (the time estimate based on a 3-week LC and 8-
> weeks for responding to comments), we don't need to unprefix early, and if
> we *can't* get to CR in that period, the spec clearly isn't stable anyway.
> 
> This is a false argument, based on a false equivalence.  Tantek is
> suggesting that the syntax is clearly stable (single implementation for a
> long time, multiple impls more recently), so we can go ahead and unprefix
> and work under the assumption that we're constrained in any changes by
> that.  However, the *functionality* may not be perfectly stable yet; in
> particular, for 3d transforms there are still some kinks to work out and
> define, such as how to render intersecting elements.
> 
> The fact that functionality needs thought, tweaking, and spec work has *no
> bearing* on whether the syntax is effectively frozen or not (in this case,
> at least; generally, they usually are linked).  But Sylvain's argument
> hinges on that, because for us to reach CR we need both the functionality
> *and* the syntax to be stable.
> 
> So, we should reject Sylvain's false argument and go ahead and unprefix
> TTA.  We already, for all practical purposes, act as if the current syntax
> is a legacy constraint on future changes.  We shouldn't pretend like we're
> going to make a breaking change.
> 
> This will *not* prevent us from making syntax changes in the future.
> They will just have to be compatible with the existing syntax.
> 

Tab,

Given that half the members on today's call agreed with the course I proposed,
is it necessary or helpful for you to single one of them out? Your description
is at the least grossly misleading as it implies one person - me - single-handedly
blocked progress. Given that the straw poll minuted by *you* shows that to be 
obviously untrue, I'm not sure what to make of your aggressive revisionism. It's
disappointing, at the least. 

Second, today's discussion came to the exact same non-conclusion as it did a 
week ago. My position then was the same - as shown by Wednesday's minutes - and 
other members agreed as well, hence the general frustration. Given the already
delicate nature of the debate, discussing the actual issues would, at this point, 
seem more productive than starting some public 'blamestorming' session, however 
fun going high-school on people may be.

Authors expect the same unprefixed value to render the same across browsers. 
Stable syntax is a necessary component of interop but it's not sufficient. 
Especially for a spec as backlogged with issues as Animations. We have 56 
issues logged against the spec and I yet have to go through about 10 months
worth of www-style. Many of these issues define what the syntax should *do* 
and refer to specific interop issues [1][2]. Others involve OM issues that 
should be resolved to ensure interop [3][4]. Are you suggesting issues like 
these don't need to be resolved before dropping prefixes? If browsers disagree 
about relatively basic runtime issues for the next 9-12 months as we finish the
spec, are web and framework authors going to thank the WG for the result? Is it
really going to be an improvement to the alternative from their point of view? 
May I *at least* ask how and why the benefits to Mozilla or Opera are worth the 
possible pain on everyone else? (Microsoft is specifically concerned about 
WebKit-only properties that are unspecified AND prevalent on the mobile web)

Yes, I do object to Animations entering Last Call with so many open issues. 
And yes, I object to dropping prefixes when some of the interop issues raised on 
this mailing list persist in implementations a year after they were filed. If 
that is a "false argument" then we probably have nothing more to discuss on this topic.

Most of the discussion actually revolved around Transforms as there *is* general 
consensus that this area is closest to interop. I strongly support pushing these 
modules to CR. 

The allegedly 'false' argument here was that either:
1. We are confident that the specs and implementations are nearly done; in which
case the time saved from dropping prefixes right now should be in the neighborhood 
of ~3 months or approximately between now and the next f2f. It's up to those folks 
who cannot wait another 12 weeks to explain why. Given their release cycle of 6 weeks 
or so, it's a perfectly reasonable question imo. 

2. We are confident in our implementations but the specs are way behind; in that case,
I asked that we at least attempt to establish the basis of our implementation confidence 
beyond anecdotal evidence that basic transform effects - e.g. animated rotations on 
:hover - and other demo pages appear to work the same 'everywhere'. 

In other words, I requested that we at least produce reasonable testcase-based evidence 
*demonstrating* that we can drop prefixes today and make the spec match browsers tomorrow. 
Your response to that was 'But it won't change the syntax' which sort of misses the point 
by a mile as the idea is to understand which types of values, if any, may result in 
incompatible rendering across unprefixed implementations for months to come (if not a few 
years in IE's case; not everyone ships a new release at the top of the hour). 

We have to write those testcases to exit CR anyway. If writing a bunch of testcases to
demonstrate to ourselves and the community that we know what the hell we're doing is such
an undue burden then I must conclude Mozilla will go for a -webkit prefix regardless and 
I'd rather not *also* give authors unprefixed properties with annoying interop issues for 
a year or more. I would assume, however, that the folks who want to implement -webkit-transform 
have done much of this testing already to ensure their -webkit alias will work well enough with 
real content. So submitting a useful bunch of testcases *should* be a formality if Mozilla and/or 
Opera are really ready to pull this specific -webkit trigger in the next few weeks. If it's not 
a formality because they haven't done that testing then I really don't have any basis to support 
their request. And, imo, neither do you regardless of how high you can stack bullshit when you're
having a bad day.  

Now, can we call the grandstanding phase complete and get to work on concrete and actionable 
problems? Thank you.
S.


[1] http://lists.w3.org/Archives/Public/www-style/2011Oct/0214.html 
[2] http://lists.w3.org/Archives/Public/www-style/2011Nov/0020.html

[3] http://lists.w3.org/Archives/Public/www-style/2011Apr/0036.html

[4] http://lists.w3.org/Archives/Public/www-style/2011Nov/0021.html







Received on Thursday, 16 February 2012 00:58:46 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:50 GMT