Re: Unprefixing CSS properties

On Wed, Nov 23, 2011 at 7:28 AM, fantasai <fantasai.lists@inkedblade.net> wrote:
> As for Henri's proposal of maintaining multiple features that do the
> same thing with varying levels of brokenness in order to drop prefixes
> as soon as implementations exist... that is weighting immediate
> gratification far too heavily against the coherency, understandability,
> and implementability of CSS going forward.

It seems that I have not communicated my proposal clearly enough.

I'm not suggesting maintaining multiple features that do the same
thing with varying levels of brokenness as a general solution. In
general, I hope the outcome from baking a feature first in
experimental builds and then shipping it unprefixed would be that
unprefixed good features get out there sooner without having to wait
for them to be tweaked to perfection while authors move to a de facto
standard parallel system.

I was suggesting that if *occasionally* a feature gets stuck in a
notably unideal design due to having been deployed without enough
polishing before too much existing content has accumulated,
introducing a second feature that fixes it is less bad than the
current model where almost *all* features go through a breaking step
(from prefixed to unprefixed) and often exist for an extended period
of time with varying levels of brokenness (in different engines with
different prefixes).

The process I'm proposing is:
 1) Come up with a feature and write a spec draft for it.
 2) Send email about it to www-style.
 3) Change the design to take into account comments from www-style.
(Or if others convinced you that the feature was really bad, abandon
the idea here.)
 4) Implement the feature in nightly builds (but don't let it leak to
releases); document what was implemented as a spec draft.
 5) Send email about the implementation to www-style.
 6) Change the design to take into account comments from www-style.
(Or if others convinced you that the feature was really bad, abandon
the idea here and delete the code.)
 7) Iterate steps 4 through 6
 8) When you are convinced that the feature is good enough to let the
future be constrained by it and you feel that it's so good that it
doesn't make sense to withold it from releases anymore, ship it
without a prefix in a release.
 9) Keep tweaking details that can still be changed without breaking
too much content that has accumulated already.
10) Consider the feature done when there's no need to change it
anymore or there's so much legacy content that it can't be changed
anymore.

I expect that this process would lead to authors getting stable
unprefixed features sooner than in the current model. I expect that
features emerging from this process would be good most of the time.

It's plausible that occasionally a feature would get to step 10 and
still be seriously flawed. In that case, the solution would be
introducing another feature that fixes the first one, but I expect
that situation to be an exception--not the normal outcome.

As for immediate gratification, I think we need to consider some
notion of net present value for specs. That is, a good spec soon is
more valuable than a perfect spec far in the future, because the spec
would have utility between now and the future and there are competing
solutions that can take over between now and the future. (Note that
competing solutions don't just include non-CSS technologies. They also
include vendor-prefixed engine-siloed CSS.)

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Thursday, 24 November 2011 14:31:49 UTC