- From: Dirk Schulze <dschulze@adobe.com>
- Date: Mon, 14 Oct 2013 23:16:47 -0700
- To: "robert@ocallahan.org" <robert@ocallahan.org>
- CC: "public-fx@w3.org" <public-fx@w3.org>
On Oct 15, 2013, at 8:08 AM, Robert O'Callahan <robert@ocallahan.org> wrote: >> On Tue, Oct 15, 2013 at 1:51 AM, Dirk Schulze <dschulze@adobe.com> wrote: >> I assume you are referencing the following text [1]: >> >> "" >> multiply the accumulated matrix with the perspective matrix on the element’s containing block (if any). That containing block is not necessarily a member of the 3D rendering context. >> "" >> >> Even if the term "containing block" is misleading, it indeed suggests that the perspective matrix (perspective projection matrix) from one of the ancestors establishing a 3D context is taken into account. > > Yeah, for SVG I'm assuming that the "containing block" here is the parent SVG element. We could potentially alter that decision. > >> To which box do implementations resolve percentage values for 'perspective' in HTML? Still to the value returned by getClientRects() / getBoundingClientRect() ? Does getBoundingClientRect() include any transforms from children? IIRC it doesn't even if CSS Transforms still says[2]: >> >> "" >> Transforms affect the results of the Element Interface extensions getClientRects() and getBoundingClientRect() >> "" >> >> which would naturally just be the case for SVG where getClientRects() returns the object bounding box. > > For HTML percentage values resolve relative to the border-box which is unaffected by the layout of any children. Why is that the case? By default you have 'height: auto' and it depends on the children to determine the height and the getClientRects() value (which returns the border box). Am I mistaken here? Or do you mean it does not include the transformation applied to the children? Greetings, Dirk > That's the key difference between HTML and SVG here. > >> I would like to understand what implementations do on HTML before we resolve on SVG. We might even consider that perspective is not included in the SVG definition of object bounding box then. > > That would probably be weird for authors using the SVG bounding box in other contexts. > > One way to fix this would be to say that for SVG elements with 3D transforms, the perspective matrix is taken from the outermost SVG element, whose perspective-origin values are resolved relative to its CSS border-box. I wonder if that would be too restrictive. > > Rob > -- > Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w
Received on Tuesday, 15 October 2013 06:18:38 UTC