W3C home > Mailing lists > Public > www-style@w3.org > February 2012

Re: Dropping Prefixes Early on Transforms/Transitions/Animations

From: Charles Pritchard <chuck@jumis.com>
Date: Wed, 15 Feb 2012 21:29:19 -0800
Message-Id: <EEA47F49-2C96-4B63-9363-46AFE6E2FE9F@jumis.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
To: Glenn Adams <glenn@skynav.com>
On Feb 15, 2012, at 2:46 PM, Glenn Adams <glenn@skynav.com> wrote:

> If some implementer wants to support another vendor's prefix, then we see no problem in principle in them doing that. But if they have some confidence in "TTA" going to CR within a reasonable time period, then perhaps they will wait a bit.


My perspective:

Adobe flash and transforms in Chrome have been unstable across releases. <object> transforms may or may not behave in different ways. There's no firm agreement there.

Transforms with @style zoom may or may not behave in certain ways. On the Mac, zoom is enough, on the pc, zoom and transform need to be used on checkboxes.

As we're in CSS-land, I have no means at all of feature detecting these issues. The only thing I can do is platform sniff.

That's just one popular vendor implementation on two targets.

I'm happy to see transforms unprefixed, but first, I want to see real decisions about existing limitations.

On some level, I need a real agreement on the transformation change so I can at least scale up components to help with readability.

Do not shrug off device pixel ratio (and Microsoft's dpi extensions in window.screen); do not simply reject zoom as obsolete/unsupported. Setup some ground rules for object. It seems that at least scale can and should be supported there.

It's important that the entire chain work. It almost does, but vendors and their developers have not fully addressed this issue.

Chrome has a tuned and embedded Flash, yet transform support is unstable.

Zoom may have a real use for ease now, with transform; it may have a strong use case with web components. It certainly makes drawing a 2x large checkbox easier.

Pixel ratio is something we need to know about when setting out backing bitmaps, whether in Canvas or in C++ libraries. I want to know that I can run transform, and scale an element and have it be crisp, and reliable.

I do not have that presently. And when I bring up the bugs, there is confusion.

The spec is incomplete.

I have three different ways of pulling the window pixel ratios, for three different browser families. Within one family, I have two different scale behaviors (depending on OS); within one plugin, I have three different scale behaviors on one. OS, depending on where and when I set a stable property.

When I bring up these issues, there is heavy pushback. Address these issues, please, and then we will have actually tested CSS transforms prior to an unprefixed release.

-Charles
Received on Thursday, 16 February 2012 05:29:50 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:50 GMT