Re: [cssom] Element size/positioning information

On Mon, Apr 11, 2011 at 3:46 PM, Simon Fraser <smfr@me.com> wrote:
> WIth transformed elements, you may want a quad (set of four points corresponding to the corners),

Oh yeah, I meant to include that, but couldn't immediately find a good
way to talk about it, and then forgot about it.


> Potentially split inlines also pose problems. You may want all the rects/quads, or just a bounding box/quad.

Yup, or boxes split across pages/columns/regions.

We've already got this sorta solved by getBoundingClientRect and
getClientRects, where the former returns a single bounding box and the
latter returns a list of individual boxes.  Perhaps lean on the same
division, so you have elem.cssBorderRects (always returns an array,
will often be size 1) and elem.cssBoundingBorderRect (always returns a
single object)?


>> Position Relative to Another Element
>> ====================================
>>
>> Right now you can determine the position of an element relative to
>> another element by figuring out their position relative to the same
>> thing manually with one of the above methods, then subtracting one's
>> top/left from the other.  Does this need to be made more convenient,
>> so you can directly ask for something's position relative to something
>> else?
>
> I'd say no, since this gets hard with transforms. Authors can always
> go via the viewport.

I'm thinking the same thing.  This is only confusing right now just
because it inherits the general confusion around size/position
measurement.  I think once we fix the measurement properly, this'll be
easy.


>> Mouse Positioning
>> =================
>>
>> On a closely related tangent, the mouse events expose .clientX and
>> .clientY properties which are relative to the viewport.  If you're
>> trying to find the position of the mouse relative to an element (for
>> example, if you're drawing something to a <canvas> where the mouse
>> is), you have to find the position of the element relative to the
>> viewport and subtract the two positions.  I think this is a good
>> candidate for being made easier, so you can just request the mouse
>> coords relative to an element.  Again, all of the boxes of an element
>> are potential targets for being measured relative to.
>
> And here again split inlines are troublesome.

Yup.  Perhaps we can address it in a similar way to grabbing rects?


>> Mouse Positioning and Transfoms
>> ===============================
>>
>> When an element is being transformed, the position of the mouse
>> relative to it is subtler.  You may want the actual position of the
>> mouse relative to the current post-transform layout position of the
>> element - this is easy to do by just subtracting the mouse position
>> from the bounding-box position.  If you're drawing into a transformed
>> <canvas>, though, you may want the position back in pre-transform
>> coordinates, as if you took the stated mouse position and applied the
>> element's inverse transform, so you can easily draw into the canvas
>> and still have the visual display track the mouse.
>
> I think you almost always want the event coordinates in the local coordinate
> system of the element, which I think is what you're saying.

Yes, that's what I'm saying.


>> Proposal
>> ========
>>
>> I'm not sure!  There's a lot of different possible approaches here.
>> I'd like to optimize for author comprehensibility, which often means
>> optimizing for terseness as well, but I'm not certain how best to do
>> that.
>>
>> For the simple measurement case, something like
>> elem.cssBorderRect.width/height/top/right/bottom/left would work.  We
>> could similarly expose cssPaddingRect, cssContentRect, cssScrollRect,
>> etc.  Bounding boxes for transform-awareness can be requested as
>> cssBoundingBorderRect - in the absence of transforms, these return the
>> same information as their non-bounding equivalents.
>
> I think you want to access these coordinate via the view (I know that MVC was
> long flushed down the toilet with CSS/DOM, but I don't think we should give
> up entirely).
>
> So that would make it window.getCSSBorderRect(elem).left etc.

That API design has *never* made sense to me.  Every time I use it I
first write "elem.getComputedStyle()" and then remember to reverse it.
 I doubt I'm alone.  We should be optimizing for developer
intuitiveness, not a controversial theoretical purity.


> What happens on display:none elements?

Something arbitrary but well-defined.


>> Doing relative measurement is harder.  I'm not sure how I can tersely
>> expose that information.  It may be acceptable to just say "hey,
>> subtract the positions", given that getting the positions relative to
>> the same thing would be easier.  If anyone has better ideas, feel free
>> to pipe up.
>
> I think you just compute both relative to a known base coordinate system
> (client/document) and compare.

Yeah.


>> The mouse positioning case has already received some attention - the
>> last proposal I saw was for a MouseEvent.getCoordsAt(elem) function,
>> which returns an object with .x and .y.  This is the point in the
>> transformed space (the one you can easily use to draw something under
>> the mouse with <canvas>).  This isn't *quite* sufficient, since it
>> would presumably give you coordinates relative to the border box of
>> the element, when you may want one of the other boxes, but it's close.
>>
>> Finding the mouse position relative to an element in normal space can
>> probably be done by just subtracting the positions, same as finding
>> the relative positions of two elements.
>
> I think the trickiest part here is elements with multiple boxes (split inlines,
> paginated stuff etc).

Yup, same issue as above.

~TJ

Received on Monday, 11 April 2011 23:34:54 UTC