Re: [CSSOM] Revisiting transforms and getBoundingClientRect()

On Fri, Sep 20, 2013 at 3:30 AM, Simon Fraser <> wrote:

> A bit late to the party, sorry.

Welcome :-)

> On Aug 28, 2013, at 4:43 pm, Robert O'Callahan <>
> wrote:
> We also need to consider the Matrix work:
> I think if we're going to use any prefix, we should use the same prefix
> for Point, Rect, Quad and Matrix. I'm afraid to arrogate those names as-is.
> Either DOM or CSS would work for me. Blink has already got an
> implementation of CSSMatrix so I think we may as well go with the "CSS"
> prefix. Yes, it's useful for more than just CSS, but that doesn't bother me.
> Agreed. I have a minor preference for a DOM prefix but don't feel strongly.

Good because everyone else converged on "DOM" too :-).

> The signatures of the convert* methods here and in the other linked
>> thread constantly confuse me.  Perhaps a better naming scheme in the
>> IDL would help, like "sourceNode" and "sourceQuad"?  Also, the name
>> suggests a "quad, node" ordering, but the actual signature is the
>> opposite.
> I can't see how "Node sourceNode" is more helpful than "Node from". But I
> agree about the ordering.
> I dislike the syntactical decoration of passing dictionaries that name the
> parameters, like
> "node.getBoxQuads({relativeTo:otherNode})"
> since it's rarely (ever?) used elsewhere, and just just more to remember
> when typing (like like the
> microsyntax that's used in gradients, I find it very hard to remember what
> the extra terms are,
> and where to put them).

Quite a few other APIs are using dictionaries to collect optional named
parameters now, e.g., Geolocation.getCurrentPosition,
TextDecoder.decode, URL.createObjectURL.

The dictionary parameter may be a little harder to type, but it makes the
code much easier to read, IMHO, which is more important.

I don't see why you'd want to convert relative to a specific box in the
> source or target. We should just state that the
> origin of the coordinate space for an element is the top left of its
> border box, and let authors do the math inside the
> element. Thinking about different source/target boxes makes this much more
> complex than it needs to be,
> and transforms never affect the relationship of the boxes within an
> element.

It's definitely useful to be able to convert to the content-box of an
element instead of the border-box, for example if you're trying to map
points to the content of a <canvas>.

Given that the box type parameters are hidden in the dictionary, and
they're pretty easy to implement (I've done it), I think exposing the fully
general one-step conversion here is very low-cost for implementers and
authors and we may as well just do it. Avoiding the construction of an
intermediate object may be beneficial in some cases too.

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:41:46 UTC