Re: [CSSOM] Revisiting transforms and getBoundingClientRect()

On 9/7/11 6:56 PM, Robert O'Callahan wrote:
> On Thu, Sep 8, 2011 at 4:47 AM, Simon Fraser <smfr@me.com 
> <mailto:smfr@me.com>> wrote:
>
>     I think this would be useful, but we should expose point mapping
>     in the same way that we expose rect/quad mapping.
>
>
> Sure, OK. Something like element.mapPointTo(relativeTo, x, y)?
>
>     Having a variety of functions for the content, padding and margin
>     rects seems like overkill; I would prefer one or two "bottleneck"
>     quad mapping functions with helper methods to get the various
>     boxes for a given element.
>
>
> I'm not quite sure what you mean. Can you suggest something?

Look into adding this in CSSOM style.
window.getComputedStyle is a precedent.
window.getComputedQuads(element, [optional] relativeTo).margin

If relativeTo is not specified, it'd default to window.

>
>     In addition to the split boxes issue, we also have to settle on a
>     coordinate system for split inlines (I believe David Baron
>     suggested that the top  left of the first box could be considered
>     to be the origin).
>
>
> Not quite sure what you mean here either. I think my suggestion is 
> well-defined for inlines.
Word wrapping / flowing spans of text... especially flowing spans of 
text. One of the intents of the getClientRects method was to return a 
list of boxes for each flowing area of text.

I think that sticking to bounding boxes / extents, such as is done in 
getClientRects width/height/top/left/bottom/right is a more useful 
method. I'd like to see more work done on exposing information on inline 
spans.

We've used unfortunate methods like  textContent.split(' 
').join('</span><span>') to work around the lack of methods for 
reflecting information on spans of text. It would be nice to have a 
better selector system for them.

-Charles