W3C home > Mailing lists > Public > www-style@w3.org > September 2013

Re: [CSSOM] Revisiting transforms and getBoundingClientRect()

From: Robert O'Callahan <robert@ocallahan.org>
Date: Fri, 20 Sep 2013 08:09:43 +1200
Message-ID: <CAOp6jLY2cKVUdMovSiAoV=bjsRx-xM=fcoCEzJd0+bPCjegokg@mail.gmail.com>
To: Simon Pieters <simonp@opera.com>
Cc: Simon Fraser <smfr@me.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Andrew Dupont <w3@andrewdupont.net>, www-style <www-style@w3.org>
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

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

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 Thursday, 19 September 2013 20:10:11 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:32 UTC