layout area and event targeting area
John J Barton
only one half of what one may want from it.
Currently Firebug outlines the getBoundingClientRect() values. This is a
CSS function that gives the CSS box, I believe it corresponds to "layout
area"?
But sometimes you are interested in a different box. For example, if you
wrap an <a> tag around a large image, you may want to know what part of
the screen responds to the link. I guess this is called the "event
targeting" area.?
For a given element, is the event targeting area according to ROC:
collect up all the getClientRects of the element
and all its descendants, include text node descendants.
Text nodes don't support getClientRects,
but you can create a Range covering the text node
and call getClientRects on that.
Boris said "union of all client rects", so I guess that is what "collect
up" means?
The last bit that confuses me is the getClientRect() vs calls to
getClientRect() on an element an all of its children. getClientRect()
already returns a list. I guess the list part of getClientRect() is
really zero, one or two items, just to deal with tables in a special way?
(The event targeting area can be even more interesting now that we have
access to the event listener bindings).
jjb
Mike Shaver
<johnj...@johnjbarton.com> wrote:
> The last bit that confuses me is the getClientRect() vs calls to
> getClientRect() on an element an all of its children. getClientRect()
> already returns a list. I guess the list part of getClientRect() is really
> zero, one or two items, just to deal with tables in a special way?
If you have a page with a span that, well, spans multiple lines due to
wrapping, I would expect that you would get multiple rects:
............ AAAA
AAAAAAAAAA
AAA ..............
A would likely have 3 client rects, no? In the presence of floated
images I could imagine that it gets even more complex:
............ AAAA
AAAAAAAAAA
AAAAAAAFFF
AAAAAAAFFF
AAAAAAAFFF
AAAAAAAAAA
AAA ..............
Where F is a floated-right image -- could get 7 (?) rects, maybe? I'm
not sure how the implementation would split those out, tbh.
Mike
Boris Zbarsky
> Where F is a floated-right image -- could get 7 (?) rects, maybe? I'm
> not sure how the implementation would split those out, tbh.
Our implementation returns one client rect per continuation at the
moment. That means that you'll get at least one per line when the span
line-wraps. You will also get multiple rects on a single line if there
are bidi continuations involved. You will also get multiple rects if
the inline contains blocks, of course (since that effectively causes
line-wrapping, but you will also, in Gecko, get a rect for the wrapper
block around the block child).
-Boris
John J Barton
Ah, so that is the purpose of the list part of getClientRect()? The
documentation is opaque.
So then my question is: for the event target do we want the union of the
element's getClientRect() or that plus all of its children?
jjb
Boris Zbarsky
> CSS function that gives the CSS box, I believe it corresponds to "layout
> area"?
getBoundingClientRect gives the bounding rectangle of the region one
gets by taking the union of the CSS boxes generated by the element (more
or less; it only looks at the "toplevel" boxes generated by the element).
In the case of blocks, and if you ignore column layouts and printing,
there is only one generated box for the element, and in that case that
box's rect and the return value of getBoundingClientRect() coincide.
I have no idea what "layout area" is.
> But sometimes you are interested in a different box. For example, if you
> wrap an <a> tag around a large image, you may want to know what part of
> the screen responds to the link. I guess this is called the "event
> targeting" area.?
This isn't a box, in general. It's just some region; quite possibly
non-rectangular and not really describably as a finite union of
rectangles where SVG is involved.... If you ignore svg, though:
> For a given element, is the event targeting area according to ROC:
> collect up all the getClientRects of the element
> and all its descendants, include text node descendants.
> Text nodes don't support getClientRects,
> but you can create a Range covering the text node
> and call getClientRects on that.
That's correct.
> Boris said "union of all client rects", so I guess that is what "collect
> up" means?
Yes.
> The last bit that confuses me is the getClientRect() vs calls to
> getClientRect() on an element an all of its children. getClientRect()
> already returns a list. I guess the list part of getClientRect() is
> really zero, one or two items, just to deal with tables in a special way?
No. You get multiple rects any time line-breaking, column-breaking, or
page-breaking happen. But these rects are just the rects for the
element itself, and its descendants can overflow it for various reasons
(your <img>-in-<a> example is one such reason, but the descendants might
also just be positioned or floated).
-Boris
Boris Zbarsky
> So then my question is: for the event target do we want the union of the
> element's getClientRect() or that plus all of its children?
The latter, with roc's correction for textnodes. Here's a simple
testcase you can use to investigate the behavior:
<!DOCTYPE html>
<html>
abc<a href="http://www.example.com"
style="position: relative; top: 200px; border: 1px solid blue">def
<span style="position: absolute; top: -100px; width: 20px; height: 20px;
border: 1px solid purple; font-size: 50px">xyz</span>
<br>ghi</a>
</html>
-Boris
John J. Barton
...
> This isn't a box, in general. It's just some region; quite possibly
> non-rectangular and not really describably as a finite union of
> rectangles where SVG is involved.... If you ignore svg, though:
>
>> For a given element, is the event targeting area according to ROC:
>> collect up all the getClientRects of the element
>> and all its descendants, include text node descendants.
>> Text nodes don't support getClientRects,
>> but you can create a Range covering the text node
>> and call getClientRects on that.
>
> That's correct.
>
>> Boris said "union of all client rects", so I guess that is what "collect
>> up" means?
>
> Yes.
This feature will wait for FF 3.7 (Firebug 1.6), because as Steve
Roussey pointed out to me, Range.getClientRects() is not in FF 3.6.
http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/7ed4d752a19c3cfa
jjb
Boris Zbarsky
> This feature will wait for FF 3.7 (Firebug 1.6), because as Steve
> Roussey pointed out to me, Range.getClientRects() is not in FF 3.6.
You could provide an approximation by at least doing the element rects;
for many cases this would be good enough. But either way.
-Boris
Robert O'Callahan
> you will also, in Gecko, get a rect for the wrapper
> block around the block child).
Actually you don't. We explicitly avoid returning rects corresponding to
anonymous boxes.
Rob