CSS WG Blog CSS Transforms Level 2 Updated

CSS Transforms Level 2 Updated

The CSS WG has published an updated Working Draft of the CSS Transforms Module Level 2.

CSS transforms allow elements styled with CSS to be transformed in two-dimensional or three-dimensional space. Level 2 (currently mostly a delta specification) adds new transform functions and properties for three-dimensional transforms, and convenience functions for simple transforms.

The full list of substantive changes in this working draft (relative to the First Public Working Draft, which is really what separated this material from Level 1 rather than the first publication of the material) is listed in the Changes section.

Please review the draft and file issues in the GitHub repository (or, if needed, send them by email to www-style@w3.org). Either way, please prefix the summary/subject with [css-transforms-2].

A few pieces that I’d like to highlight from the full changes section linked above are the following:

• The edits for w3c/csswg-drafts#3305 (to reflect that 3D-ness of transforms should not be stored or determined by the syntax used, that is, that using 3D syntax with something that is expressable as 2D should not be different from something expressed in 2D syntax) are only half-done. They’re done for individual transform properties, but they’re not done for the functions in the transform property. I was hoping to do this before publication, but I think it likely requires a good bit of new text rather than modification to existing text (since the currently implemented behavior isn’t defined in the spec), so I’d like to take the time to think about it more carefully. (Once it’s done, it will also need warnings that it might not be Web-compatible.)
• Another interesting set of edits is the following set:
  • #6238, painting order
  • #6191, accumulated 3D transformation matrix
  • #926, further cleanup of painting order

  These edits help make the spec’s model more consistent internally, and also a bit clearer, although they also align more clearly to the Chromium/Gecko behavior rather than the WebKit behavior. (I think some of the text that was there would have made sense if the spec had WebKit’s model for 3D rendering contexts, but I think it probably doesn’t make sense with the spec having the model that’s used in Chromium and Gecko.)

  The background behind this is that my understanding of the difference between the model currently implemented in WebKit and the model currently implemented in Chromium and Gecko is that:

  • In the absence of preserve-3d, WebKit performs 3D intersection between siblings, whereas Chromium and Gecko separately flatten each sibling after applying its transform and its parent’s perspective.
  • preserve-3d allows elements to be connected into a single 3D scene (a “3D Rendering Context”) in which the elements are intersected in 3D and then the resulting scene is flattened together.
  • In Chromium and Gecko, this flattening includes the root-most element with preserve-3d, its descendants that are connected by chains of elements that all have preserve-3d, and their children. It includes that root-most element’s transform and its parent’s perspective.
  • Analogously to the situation in the absence of preserve-3d, in WebKit this scene also includes the siblings of that root-most element. (But I believe it does not consider the transform on that root-most element’s parent.)
  • As a result of this difference, in the Chromium/Gecko model and in the spec, the element that is considered to “establish” the 3D scene is the root-most element with preserve-3d, whereas in WebKit the element that is considered to “establish” the 3D scene is its parent. (The establishing element is effectively the element responsible for the flattening.)

  While the spec defined the construction of 3D scenes in the way that matches the Chromium/Gecko model, there were a few definitions that matched the WebKit model instead. These edits essentially fix those definitions to match the Chromium/Gecko model, and then do some further cleanup on the definitions.

  Applying the spec definitions as previously written may not have been Web-compatible, since it would have implied results that did not match any browser. Essentially I’d think of this as that the Chromium/Gecko model and the WebKit model differ by “half” a step up the the tree, whereas applying these definitions as previously written would have caused the spec’s requirements to differ from WebKit by a “full” step up the tree and from Chromium/Gecko by “half” a step up the tree (since they were written in terms of the WebKit model’s concept of “establishing element”). In this description, a full step up the tree (meaning including one more ancestor and its children in the 3D scene) consists of two half-steps: the first half-step is that of merging the siblings of the current root into the scene (and thus making the new root be the old root’s parent), and the second half-step is applying the transform of the new root (along with the perspective of its parent). Chromium, Gecko, and WebKit currently all agree on the overall transform; the difference in behavior affects which elements are part of the 3D scene.

The spec still has a large number of open issues.

In the near future, I’m hoping to:

• continue to slowly make progress on the list of issues, and
• work specifically on defining backface-visibility better, and finding a way to move towards interoperability in a way that doesn’t break (too much) content on the Web. In particular, I’d like to provide clear definitions of:
  • which descendants do and don’t get hidden when an element has ‘backface-visibility: hidden’, and
  • what grouping effects ‘backface-visibility: hidden’ has. (Causing more grouping effects makes it easier to include more descendants, which is likely the desired behavior in most cases.)

« Previous article Next article »