Re: [CSSOM] Revisiting transforms and getBoundingClientRect()

On Fri, Sep 20, 2013 at 3:30 AM, Simon Fraser <smfr@me.com> wrote:

> A bit late to the party, sorry.
>

Welcome :-)


> On Aug 28, 2013, at 4:43 pm, Robert O'Callahan <robert@ocallahan.org>
> wrote:
>
>
> We also need to consider the Matrix work:
> https://dvcs.w3.org/hg/FXTF/raw-file/tip/matrix/index.html
>
> 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. IDBFactory.open, 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.

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