Re: Steps to unprefixing CSS Transforms, was: Re: "-draftX-" prefix

On Monday 2011-12-05 16:22 -0800, Charles Pritchard wrote:
> On 12/5/11 4:08 PM, Tab Atkins Jr. wrote:
> >Gradients would not have been helped by moving faster, because they
> >changed based on author feedback and internal design reviews.  As I
> >said, we forged new ground with it, and that took more time than it
> >"should" have if we'd already known what we do now.  On the other
> >hand, Transitions/Animations/Transforms are only not in CR because the
> >editors haven't been working on them - moving faster*would*  have
> >helped with them.  I've been poking at Flexbox for some time, but I
> >didn't actually start rewriting it until March of this year, only 9
> >months ago.  I think it's advancing at a reasonable pace; it would go
> >slightly faster if I weren't also focusing on Images and Lists and
> >several other things, but not significantly so.
> 
> There are still instabilities and incompatibilities between the
> vendors on CSS Transforms. I think that more time needs to pass with
> Web Components before it's figured out. There has been significant
> push-back from Mozilla about zoom-related interfaces. As a
> consequence, the behavior of form elements, such as <input> and
> <canvas> are up in the air.
> 
> I'm confident the issues will re-appear in some form with Web
> Components, as that effort examines the inner-workings of
> interactive elements and their relationship to DOM+CSS.

I don't see what Web Components or form elements have to do with the
stability of CSS transforms.

I think there's some work that needs to be done to describe how
certain other things behave in the presence of transforms, such as
getBoundingClientRects().  These problems may be slightly worse when
when iframes are inside of a transform (e.g., what happens to some
media queries?).  But I think the right thing to do there is try to
solve those problems as quickly as possible when we become aware of
them, not to wait for time to pass.

> By push-back, I'm referring to: style.zoom, window.screen pixelRatio
> values, and css transform hit testing on input elements.

I haven't heard of style.zoom other than perhaps as a reference to
the CSS OM representation of a nonstandard property in some
browsers.  It shouldn't have any bearing on transforms.

I also haven't heard of "window.screen pixelRatio".  Mozilla doesn't
implement anything called "pixelRatio", though we have a
window.screen object (for which cssom-view has a draft
specification).  Are you referring to something about what happens
inside of transformed iframes?  Is pixelRatio a property of some
object in some other browsers?

What sort of hit testing on input elements are you referring to?
Are you referring to browser bugs or disagreement about what the
spec should say?

> There are also issues with the behavior of CSS transforms and
> <object> elements, such as when using Flash. Given how contentions
> <canvas> and <input> have been, I don't expect <object> behavior to
> be easily unified.

Are you referring to windowed plugins?

> CSS transforms have not reached consensus amongst vendors. They may
> like the spec, but they have not agreed on implementation of it.

Getting to CR doesn't require that the implementations are
compatible; it requires that we agree on what we *intend* to
implement.  *Exiting* CR requires interoperable implementations.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂

Received on Tuesday, 6 December 2011 00:45:07 UTC