RE: Dropping Prefixes Early on Transforms/Transitions/Animations

If you can initiate a public thread based on a claim in direct conflict with your own minutes I will grant
that you probably are an authority on argumentative fallacies.

Now I’d like to hear from people who edit these specs and/or represent the vendors who ask for
this prefix drop. Signal vs. noise and all that.


From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
Sent: Wednesday, February 15, 2012 5:24 PM
To: Sylvain Galineau
Cc: www-style list
Subject: RE: Dropping Prefixes Early on Transforms/Transitions/Animations


I make a straightforward claim that your argument relied on a false premise, you respond by calling my email "grandstanding" and "bullshit", and attempt to belittle me by claiming I'm "having a bad day".

Please write back when you can discuss things without employing personal attacks and argumentative fallacies.

~TJ
On Feb 15, 2012 4:58 PM, "Sylvain Galineau" <sylvaing@microsoft.com<mailto:sylvaing@microsoft.com>> wrote:
[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