[CSSWG][css-transforms-2] Updated WD of CSS Transforms Level 2

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

    https://www.w3.org/TR/css-transforms-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:

  https://www.w3.org/TR/2021/WD-css-transforms-2-20211109/#changes-recent

Please review the draft and file issues in the GitHub repository at
https://github.com/w3c/csswg-drafts/issues (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 https://github.com/w3c/csswg-drafts/issues/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:

   - https://github.com/w3c/csswg-drafts/issues/6238 (painting order)
   - https://github.com/w3c/csswg-drafts/issues/6191 (accumulated 3D transformation matrix)
   - https://github.com/w3c/csswg-drafts/issues/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.)

For the CSS WG,
David

-- 
𝄞   L. David Baron                        https://dbaron.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)

Received on Tuesday, 9 November 2021 19:38:36 UTC