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> 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
>
>
>
>
>
>
>