Re: [CSSOM] Revisiting transforms and getBoundingClientRect()

On Thu, 29 Aug 2013 00:21:31 +0200, Robert O'Callahan  
<robert@ocallahan.org> wrote:

> [Reviving old thread]
>
> On Fri, Sep 9, 2011 at 7:01 AM, Simon Fraser <smfr@me.com> wrote:
>
>> The basic pieces seem to be:
>>
>> 1. Get an element's padding, content, border and margin boxes relative  
>> to
>> its own border-box, as rects.
>> 2. Convert a rect to a quad.
>> 3. Map arbitrary point from one element to another.
>> 4. Map arbitrary quad from one element to another (mapping 4 points)
>>
>
> Splitting the pieces up this way has a problem: with CSS Regions (or CSS
> Overflow), it's possible for a CSS transform to apply to one box of an
> element, but not another --- when one fragment flows into a container  
> that
> has a CSS transform, and another fragment flows into a different  
> container
> with no transform. In such a case, step 1 is lossy :-(.
>
> Therefore I think we need to offer a way to get the boxes as a list of
> quads. In that case, I think we may as well offer coordinate-space
> conversion in the same call.

So DOMQuad basically maps to a CSS box, is that right? Do we want DOMQuad  
to support .usedStyle? Should it have a pointer back to its Node?

> Part 3 has been more recently addressed:
> http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0099.html
>
> So here's my proposal:
>
> Rename ClientRect to CSSRect.
>
> [Constructor(CSSPoint, CSSPoint, CSSPoint, CSSPoint),
>  Constructor(ClientRect)]

What's the use case for this constructor?

> interface Quad {
>   readonly attribute CSSPoint p1; // 2D only (z,w not present)
>   readonly attribute CSSPoint p2;
>   readonly attribute CSSPoint p3;
>   readonly attribute CSSPoint p4;
>   readonly attribute CSSRect bounds;
> };
>
> [Constructor(sequence<Quad>)]

What's the use case for this constructor?

> interface QuadList {
>   readonly attribute unsigned long length;
>   getter Quad item(unsigned long index);
>   readonly attribute CSSRect bounds;
> };
>
> enum BoxType { "margin", "border", "padding", "content" };
> dictionary BoxQuadOptions {
>   attribute BoxType box; // defaults to "border"
>   attribute Node relativeTo; // defaults to viewport

Which object gets to represent the viewport? Since the type is Node, the  
closest fit is Document, but we don't have to use that. We could use  
Window instead if we want.

Also, should we restrict the set of Nodes that participate in the API to  
Element and Text (and Window or Document for the viewport)? Does it make  
sense to have the methods below on DocumentFragment, DocumentType,  
ProcessingInstruction and Comment?

Do we want PseudoElement to participate in this API?

> };
>
> partial interface Node {
>   QuadList getBoxQuads(BoxQuadOptions options);
>   Quad convertQuadFromNode(Node from, Quad quad);
>   Quad convertRectFromNode(Node from, CSSRect rect);
> };
>
> [snip]

-- 
Simon Pieters
Opera Software

Received on Thursday, 19 September 2013 12:20:13 UTC