[css-transforms] 'perspective' should apply to elements not in a 3D rendering context, and related issues

The transforms spec currently defines a 3D rendering context as
being established by 'transform-style: preserve-3d' elements whose
parent is not 'preserve-3d'.  This is defined (somewhat ambigously)
at http://dev.w3.org/csswg/css-transforms/#3d-rendering-context ,
although without clearly explaining what is in a separate rendering
context and also without clearly explaining the definition's
interaction with the exceptions to 3d preservation in
http://dev.w3.org/csswg/css-transforms/#propdef-transform-style .

It then defines an accumulated 3D transformation matrix as something
that exists for elements in a 3D rendering context here:
http://dev.w3.org/csswg/css-transforms/#accumulated-3d-transformation-matrix
and defines the computation here:
http://dev.w3.org/csswg/css-transforms/#accumulated-3d-transformation-matrix-computation

The accumulated 3D transformation matrix is the only thing that is
influenced by the perspective matrix, which is in turn the only
thing that is influenced by the 'perspective' property.

This, in turn, seems to mean the spec defines 'perspective' as not
applying unless there is a 3D rendering context (i.e., a hierarchy
with preserve-3d).

I think this is incorrect for two reasons:

  (1) my understanding of the model the spec tries to describe is
  that 'transform-style: preserve-3d' delays flattening to an
  ancestor and preserves the 3D scene, but doesn't otherwise disable
  features that still make sense when doing flattening in the
  containing block.

  (2) This doesn't appear to be compatible with implementations.
  http://dbaron.org/css/test/2014/perspective-3d-context shows that
  perspective is supported, as I would expect, in at least Gecko and
  WebKit.


So I think there's something wrong with the formalism in these
definitions.  I'm not particularly happy with the "3D rendering
context" terminology as a whole, but at the very least it seems like
concepts shouldn't be restricted to being present only on elements
in a preserve-3d hierarchy.  It might make more sense to restrict
some concepts to being present only on elements that have either a
3-D transform or preserve-3d, or something like that.

(It might be worth waiting for Simon Fraser's upcoming proposal,
discussed at the last face-to-face meeting in Seattle, about
changing how 'transform-style' works, though.)

I also think many of the details need to be cleaned up, such as:

  (a) the interaction of the definition with the cases when
  'transform-style: preserve-3d' can't preserve 3D (which I think
  requires a defined term to describe the cases where 3D
  preservation does happen)

  (b) the boundary conditions on definitions like
  http://dev.w3.org/csswg/css-transforms/#accumulated-3d-transformation-matrix-computation
  which defines the "accumulated 3D transformation matrix" in a way
  that is not clear about whether the matrices from the "element in
  question" and the "root of the 3D rendering context" are used.
  (It's certainly not clear enough to convince me that the author
  intended a particular interpretation, even if an interpretation
  (excluding both endpoints, I think, which seems wrong to me) could
  be derived from the words.)

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)