Re: [cssom] Element size/positioning information

On 4/11/11 2:35 PM, Tab Atkins Jr. wrote:
> Right now there are four ways of asking for the width of an element:
> elem.clientWidth, elem.scrollWidth,
> elem.getBoundingClientRect().width, and
> getComputedStyle(elem,'').width (similarly for height).

Of course the clientWidth thing is only needed for web compat.  The 
other three return totally different things from each other; which one 
you want depends on what you're measuring.

> (In case people are unaware of what the first two actually
> do, I made a diagram some time ago at
> <http://www.xanthir.com/diagrams/scrollwidth-clientwidth.html>.)

That diagram is .... wrong unless you're using a different meaning of 
"content width" than the usual one.

The clientWidth of an element is as you say.

The scrollWidth, however, has to do with the amount of scrolling the 
element can do.  This is not actually related to the "width" of the 
content in any layout sense (e.g. relative positioning of children 
affects scrollWidth.

> The first three return the size in pixels as an integer

This is false, except in some UAs that choose to clamp widths to 
integers.  For example, in Gecko elem.getBoundingClientRect().width will 
return the width actually used for layout of the element as a double.

> while the fourth returns size in pixels as a string with 'px' at the end.

This is also false.  The computed style width is "auto" for non-replaced 
inlines in Gecko, for example (and that's ignoring elements that are not 
rendered, for which the computed style width can be any specified width 
value).

> The third is transform-aware, while the others ignore any transforms on the
> element.

This is true in Webkit, but not in Gecko.  In Gecko none of these take 
transforms into account.


> All in all, these are the boxes that we might want to get sizing
> information about:
>
> 1. content box, ignoring scrollbars
 > 2. content box, subtracting scrollbars

What does this mean, exactly?  Scrollbars go into the padding, 
generally...  They don't usually affect the size of the content box, right?

> 3. content box, scrollable area

Is this meant to be the thing scroll* currently returns?

> 4. padding box (+/- scrollbars?  Depends on exactly where the impl
> puts the scrollbars.)

The scrollbars go in the padding per current spec, last I checked.

> 5. border box
> 6. transform-aware bounding box of at least the border box, possibly other boxes

We probably need the margin box as well.  Or whatever the right thing is 
to return for code that wants to size things on a line by subtracting 
the widths of some stuff from the block width and then setting the width 
of some box to what's left.

> Right now, there are two ways to get the position of an element:
> elem.offsetTop/Left (gives you coords relative to the element's
> positioning root), and
> elem.getBoundingClientRect().top/right/bottom/left (post-transform
> coords of the bounding box relative to the viewport).

Again, that's not actually what those do in all browsers.

> (Alternately, I could have gotten getComputedStyle().borderTopWidth
> and .borderLeftWidth and parsed them into integers.)

Which would also be wrong if the widths aren't integers...

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

It's unclear what this even means in a world with transforms, by the way....

> 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 what it's worth, I think this may be the wrong working group for 
this.  The fact that getBoundingClientRect ended up in CSSOM in the 
first place is pretty weird to me...  The various working groups that 
have actual experience with DOM API design might be better venues for 
designing more DOM APIs.

-Boris

Received on Monday, 11 April 2011 22:01:13 UTC