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

Re: Dropping Prefixes Early on Transforms/Transitions/Animations

From: Dirk Schulze <dschulze@adobe.com>
Date: Thu, 16 Feb 2012 14:50:04 -0800
To: Charles Pritchard <chuck@jumis.com>
CC: Glenn Adams <glenn@skynav.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
Message-ID: <37F3132B-2170-44BF-A5DD-21B4EB9456F6@adobe.com>

On Feb 15, 2012, at 9:29 PM, Charles Pritchard wrote:

> 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.
Can you give an example please? I don't understand what you mean with 'zoom', the CSS property? How is it related to checkboxes. What is the bug with zoom and transform?

> 
> 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.
Can you file limitations (I assume you mean issues) on https://www.w3.org/Bugs/Public/ please? I don't want to miss an issue.

> 
> 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.
We are not talking about Flash but CSS Transforms, no? I don't think that we will address issues on Flash on the W3C.

> 
> 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.
Oh sorry, You mean you want to increase the size of checkboxes and you want to use CSS Transforms to do it the same way cross platform. Did I understand it correctly?

-Dirk

> 
> 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 22:50:43 GMT

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