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

Re: [css3-transforms] What is the use-case for transform-style: flat?

From: Aryeh Gregor <ayg@aryeh.name>
Date: Mon, 6 Feb 2012 14:40:07 -0500
Message-ID: <CAKA+Ax=-StMUmDgxs13C2RiJwrBjDP8HXFPPeX9dQ+drpb2ChQ@mail.gmail.com>
To: Dean Jackson <dino@apple.com>, Simon Fraser <smfr@me.com>
Cc: David Hyatt <hyatt@apple.com>, Chris Marrin <cmarrin@apple.com>, "Edward O'Connor" <eoconnor@apple.com>, Vincent Hardy <vhardy@adobe.com>, Dirk Schulze <dschulze@adobe.com>, www-style@w3.org, Matt Woodrow <mwoodrow@mozilla.com>
On Mon, Feb 6, 2012 at 2:15 PM, Dean Jackson <dino@apple.com> wrote:
> Preserving 3D is actually a little complex (see the mozilla bugs where
> there are some expletives trying to work out how it was implemented
> in webkit - now Simon is writing the spec text to explain it better).

Yes, I've seen that.  It certainly made things a lot clearer.

> That's not quite true. Scaling anything to 0 doesn't really flatten it,
> it makes it disappear.

Why?  If everything lies in the x-y plane to start with, the
z-components are zero, so scalez(0) should be a no-op.  Why would it
make anything disappear?  (It actually does in Firefox and IE, but not
Chrome, at least on my machines.  But I don't know why it should.
https://bugzilla.mozilla.org/show_bug.cgi?id=719092)

> Also, I don't believe a scaleZ(0) would necessarily
> take the perspective into account.

If you mean the 'perspective' property on a parent, yes, because
scaleZ(0) will be applied after it, not before.  (That's a whole
separate question: why do we have a separate 'perspective' property
instead of just having authors use perspective()?  I'll start another
thread.)

> What preserve-3d actually does under the hood is play with the nesting
> of content - what looks like a child in the DOM might end up as a sibling
> in the compositing engine. This has overhead that can't be turned on
> for all transforming content.

On Mon, Feb 6, 2012 at 2:18 PM, Simon Fraser <smfr@me.com> wrote:
> Also, in terms of implementation, UAs have to do a lot more work to support
> the 'preserve-3d' behavior, and are likely to use more system resources doing so.
> For this reason, we think it appropriate that authors "opt-in" to the special 3d rendering
> context behavior, and the new rendering behaviors and potential resource usage
> that goes along with it.


So if this is just for performance considerations, can we think of
some way to do it that doesn't require explicit author opt-in?  For
instance, if the only available mode were transform-style:
preserve-3d, couldn't you optimize rendering by only enabling it if
there's a combination of 3D transforms that needs it?  E.g., if an
element has no 3D transform applied to it and it has at most one child
that's being rendered, or if it has a 3D transform applied to it but
its children have no 3D transforms applied to them, there should be no
difference between flat and preserve-3d, so you can automatically
switch to the faster way of doing things.

I'm concerned about the possibility that we're adding a confusing
switch here forever for the sake of performance now.  This doesn't
sound like a good tradeoff to me.  If I were an author, I'd do * {
transform-style: preserve-3d } as soon as I hit the first surprising
behavior.  Can't this be optimized without author opt-in?

I'd especially like to hear from Microsoft and Mozilla people about
whether they agree that the performance impact requires a separate
mode for preserve-3d.

On Mon, Feb 6, 2012 at 2:18 PM, Simon Fraser <smfr@me.com> wrote:
> We chose 'flat' as the default because 'preserve-3d' introduces new behavior
> which can affect elements which don't have transforms applied to them directly,
> namely, it enables intersection of sibling elements if one of them has a transform that
> causes it to intersect the z=0 plane.

Is this relevant if there are no 3D transforms in effect?  What's a
case where this would be surprising to authors?
Received on Monday, 6 February 2012 19:40:59 GMT

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