Re: "-draftX-" prefix

On Mon, Dec 5, 2011 at 3:47 PM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
> ± From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> ± Sent: Monday, December 05, 2011 2:57 PM
> ±
> ± * It doesn't seem to aid in preventing prefixes from being supported forever.  In
> ± fact, it probably makes it worse.
>
> Of course not. Supporting prefixes long-term depends only on amount of existing prefixed content (with any kind of prefixes). The only way to avoid supporting prefixes forever is to not use them to begin with.
>
> I don't see how this can make it worse either, this is addressing a different problem.

If multiple browsers use a single prefix, it's much more likely that
content will be authored to depend on that prefix.  Usually only the
first implementor runs this risk, because they have it prefixed for
longer than the others.


> ± *  It allows authors to write only a single prefix, which is better than writing 3-4
> ± prefixes.  However, the latter situation is rare (usually, properties stabilize before
> ± more than 1 or 2 browsers have a prefixed impl).
>
> Rare?? How do you define "rare"? That is exactly what designers are unhappy about, have you read any or the vendor-prefix articles lately?

In my email (not present in the quotes you preserved), I explicitly
called out the main failure cases, and explained what the cause of the
failure was.  This proposal does not help either of those.  The fact
that multiple prefixes are necessary makes them more painful than they
would be if everyone just used a shared prefix, but it wouldn't solve
the underlying problem, and thus the majority of the pain would still
be present.


> An even bigger issue is that content authored for existing prefixed implementations won't work in new implementations until authors update content (and some content never changes). If there is content on the web with "-ms-grid-", implementing "-webkit-grid-" does nothing for supporting that content.

If there is content on the web with -draft1-grid, implementing
-draft2-grid does nothing for supporting that content.  Spending extra
effort to support an obsolete version of a property doesn't seem very
attractive either.  Thus, this doesn't solve that problem.

> ± * It does nothing to stop the pain of authors either writing the unprefixed version
> ± speculatively (creating content that harms our ability to change the grammar before
> ± CR), or never writing the unprefixed version (preventing browsers from removing
> ± support for the prefixed version).
> ±
> ± So, it doesn't seem like we need complicated solutions for this stuff.
> ± We just need to ensure that specs actually reach CR in a timely manner when they're
> ± ready for it.
>
> You are not saying that directly but it looks like you are suggesting that specs have to be in CR before first implementations, and there are no syntax changes in specs based on implementation feedback. That's wishful thinking. You are editing flexbox spec for two years now -- is it ready for unprefixed implementation? I don't think so.
>
> It would be great to speed up CSS spec process, I am all for that, but claiming that it can quickly become so fast as to remove the need for prefixed implementation is just denial.

No, I'm not suggesting that at all, and I never have.  It's a
ridiculous position on it's face, so of course I wouldn't.  I also
specifically called out one of the failure cases (gradients) where
there were syntax changes based on feedback.

Gradients would not have been helped by moving faster, because they
changed based on author feedback and internal design reviews.  As I
said, we forged new ground with it, and that took more time than it
"should" have if we'd already known what we do now.  On the other
hand, Transitions/Animations/Transforms are only not in CR because the
editors haven't been working on them - moving faster *would* have
helped with them.  I've been poking at Flexbox for some time, but I
didn't actually start rewriting it until March of this year, only 9
months ago.  I think it's advancing at a reasonable pace; it would go
slightly faster if I weren't also focusing on Images and Lists and
several other things, but not significantly so.

~TJ

Received on Tuesday, 6 December 2011 00:09:40 UTC