Re: Unprefixing CSS properties

On Thu, Nov 17, 2011 at 1:25 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Tue, Nov 15, 2011 at 8:02 PM, Robert O'Callahan <robert@ocallahan.org>
> wrote:
> > 2D Transforms: all properties
> > 3D Transforms: all properties
> > Transitions: all properties
> > Animations: all properties (responses to feedback urgently need to be
> added
> > to the spec, and that should probably happen first)
>
> Disagree with 3d transforms. I don't think we have any real idea how
> preserve3d is supposed to work, for example.
>

There is an issue with whether/how preserve3d is inherited; I don't know
about any other major issues. However, we discovered this issue on a
production site where someone was using -moz-transform with 3D transforms
before we've even shipped the feature! I assume they just did a
bulk-replace of -webkit with -moz at some time in the past. In an
environment where people are doing this routinely (and I saw hundreds of
Web devs being explicitly taught to do this at Web Directions South a few
weeks ago), we have nothing to lose by dropping the prefix now.

> Images: image() value, 'object-*', 'image-*'
> Why did you omit element()?  Do Moz people have some issues with it?
>

It's a relatively complex feature underneath, I'm not confident in it until
there's a second implementation.

If so, could you tell me about them in a new thread?  It at least has
> an implementation - image() has 0 afaik.
>

Yeah, but image() is super simple.

If you wait a week or two for the Image Values LC, or until January or
> so for CR, gradients will be stable as well.
>

Yes, and we should unprefix those as soon as humanly possible.

> Values: a subset of calc() (the intersection of what IE9 and Gecko
> > implement), the new units
>
> What's the subset of calc()?  Is it just "everything but min() and
> max()"?  If so, we should just punt min() and max().
>

I think it is, yeah.

The only remaining bits are attr() and cycle().  I presume you find
> those unstable?
>

dbaron thought they were unstable.

> Selectors 4: :matches, :any-link, :nth-match, :nth-last-match, :column,
> > :nth-column, :nth-last-column
>
> Agree, though we could just cut Selectors 4 and push it quickly to CR
> as well.  That could take as little as a few months.
>

Even a few months seems unnecessarily long.

Things like this are fixable in a
> different way - I believe that we browsers shouldn't expose prefixed
> properties in our public versions.  Exposing them in betas or
> nightlies still lets people experiment with the features without them
> showing up in publicly-exposed websites or adopted as valid practices.
>  This *also* puts a social pressure on us, the spec authors, to get
> our shit in order and finish our specs, so people *can* use them
> publicly-exposed websites.
>
> We've discussed this seriously within Chrome, and I believe roc likes
> this as well.  There are difficulties with it (convincing the release
> engineers to accept pushing an untested binary to beta because we
> switched off some prefixed features), but I think it's doable.
>

I think it's a good idea overall. I would relax it slightly to say that
"browsers shouldn't expose prefixed properties in our public versions *by
default*." Both Firefox and Chrome routinely ship experimental stuff in
release builds but disabled by default, explicitly enablable by the user.
This reduces the risk of changing the binaries you ship, and lets authors
more easily access the experimental features.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not
in us. If we confess our sins, he is faithful and just and will forgive us
our sins and purify us from all unrighteousness. If we claim we have not
sinned, we make him out to be a liar and his word is not in us." [1 John
1:8-10]