Re: Unprefixing CSS properties

On Wed, Nov 16, 2011 at 5:18 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> On Thu, Nov 17, 2011 at 1:25 PM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>> 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.

There's no consensus on whether preserve3d with intersecting elements
draws using painting order, 3d z order, or splits them to draw
"correctly".

Our impl appears to have several other quirks, as well.


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

Okay.


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

Then let's punt min() and max().  I'll start a separate thread.


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

I think both are fine.  I'd like to try and implement cycle() this month.


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

I think 3 months is about the minimum cycle time if we want to do this
"right".  I don't think it's a huge deal - it's just two browser
releases or so.  ^_^


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

That seems reasonable.  Accomplishes the same thing, but with less
risk, as you said.  Let's chat about this in a side-channel.

~TJ

Received on Thursday, 17 November 2011 01:33:10 UTC