Re: [CSSOM] Revisiting transforms and getBoundingClientRect()

On Fri, Sep 20, 2013 at 12:19 AM, Simon Pieters <simonp@opera.com> wrote:

> 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?
>

No, I think it's simpler if DOMQuad is pure geometry --- just four points.
Then we can, for example, provide a method that transforms a DOMQuad by a
DOMMatrix to produce another DOMQuad. And because DOMPoints can be in 3D
space, we can also support APIs that treat DOMQuads as 3D objects.


>  Part 3 has been more recently addressed:
>> http://lists.w3.org/Archives/**Public/public-pointer-events/**
>> 2013JanMar/0099.html<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?


Which one? I guess I don'thave a use-case for these right now. Let's drop
them and we can add them later if they turn out to be useful.


>  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;
>> };
>>
>
Never mind, let's get rid of QuadList since getBoxQuads can just return
sequence<DOMQuad>.


>
>> 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.
>

A Window is not a Node. I think we should use Document.


> 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?
>

I don't believe it does, so we should restrict the set of nodes to Element,
Text, and Document.

Do we want PseudoElement to participate in this API?
>

Hmm. Where is PseduoElement specified? I'm not familiar with it.

Thanks,
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  *
*