- From: <bugzilla@jessica.w3.org>
- Date: Thu, 07 Jun 2012 05:13:06 +0000
- To: public-css-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17433 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 transforms: <body> <div style="transform-style: preserve-3d;"></div> <div style="transform-style: preserve-3d;"></div> </body> Both div boxes fulfill the requirement for a 3d rendering context, therefore a new 3d rendering context is created for both. Correct? <body> <div style="transform-style: preserve-3d;"> <div style="transform-style: preserve-3d;"> <div style="transform-style: preserve-3d;"> </div> </div> </div> </body> 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> </body> 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 function" 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