[Bug 17433] New: Term 'accumulated 3D transformation matrix' misleading


           Summary: Term 'accumulated 3D transformation matrix' misleading
           Product: CSS
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Transforms
        AssignedTo: smfr@me.com
        ReportedBy: dschulze@adobe.com
         QAContact: public-css-bugzilla@w3.org
                CC: ayg@aryeh.name, cmarrin@apple.com, eoconnor@apple.com,
                    smfr@me.com, dino@apple.com, dschulze@adobe.com

Created attachment 1141
  --> https://www.w3.org/Bugs/Public/attachment.cgi?id=1141
Mapping from coordinates to different coordinate systems

The spec currently says, that a new 3D rendering context gets created, when the
property 'transform-style' is set to 'preserve-3d', and the element is not not
part of an 3D rendering context. If it is part, it is a containing block and
extends the existing 3D rendering context.

Assume that div boxes and body elements in the following examples have 3D

  <div style="transform-style: preserve-3d;"></div>
  <div style="transform-style: preserve-3d;"></div>

Both div boxes fulfill the requirement for a 3d rendering context, therefore a
new 3d rendering context is created for both. Correct?

  <div style="transform-style: preserve-3d;">
    <div style="transform-style: preserve-3d;">
      <div style="transform-style: preserve-3d;">

Just the first div fulfills the requirement, therefore just for the first div a
3d rendering context is created. The other elements are containing blocks and
contribute to the existing context.

<body style="transform-style: preserve-3d;">
  <div style="transform-style: preserve-3d;"></div>
  <div style="transform-style: preserve-3d;"></div>

In this example the body created a 3D rendering context and the div boxes just
contribute to the existing 3D rendering context.

One understanding problem that I had on reading the section about creating a 3D
rendering context is the following sentence: "An element that establishes a 3D
rendering context also participates in that context." What does it mean for the
local coordinate space of the root element of the rendering context? The
transformation must be applied to the element as well before rendering the
element to this context? Does it mean that the 3D rendering context is
initially in the the same coordinate space as the parent element of the element
that establishes the 3D rendering context? If my understanding is correct, can
we say that more explicitly? If my understanding is wrong. Does the spec
describe how to map the 3d rendering context itself into the coordinate space
of the parent element of the element that established the 3d rendering context?

Differences "accumulated 3D transformation matrix" and "current transformation

Obviously 'accumulated 3D transformation matrix' does just describe the
transform till the root element in the 3D rendering context, but not beyond
that. The CTM is defined to be "A matrix that defines the mapping from the
local coordinate system into the viewport coordinate system.". I wonder if the
CTM makes sense for elements within a 3D rendering context. I would say that it
does. I wonder why we define 'accumulated 3D transformation matrix' at all? Why
not just use CTM?

Because of this difference it is _not_ specified how to apply the perspective
property to elements that neither establish a new 3D rendering context, nor
contribute to one. This explanation belongs to 'accumulated 3D transformation
matrix' currently.

Instead we should just define how points can get mapped from the current
coordinate system to the previous one in general - like the image with formulas
that I attached. The term 3D rendering context just describes that elements can
be drawn beyond the CSS rendering model, but does not influence the way we map
coordinates to the coordinate system of the viewport.

Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 7 June 2012 05:13:09 UTC