W3C home > Mailing lists > Public > www-style@w3.org > April 2011

Re: [cssom] Element size/positioning information

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Mon, 11 Apr 2011 18:46:08 -0700
Message-ID: <BANLkTin3xkv5igBE1wG21z0hpZJ4u0rF9A@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style list <www-style@w3.org>
On 4/11/11, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> The current OM APIs for determining the size and position of an
> element are verbose and confusing.
Uh huh.

> Determining the Size of an Element
> ==================================
> Right now there are four ways of asking for the width of an element:
> elem.clientWidth, elem.scrollWidth,
> elem.getBoundingClientRect().width, and
Nope. The `width` property is not reliable cross-browser. That's yet
another example of  AVK taking an MS APIs and changing it to make it
incompatible with the very API it is purported to standardize. Can you
think of a better way make browsers more interoperable?

> getComputedStyle(elem,'').width (similarly for height).

Uh , aren't you forgetting offsetWidth?

> It's completely unobvious what each of these do
That happens when you don't read specs. (From MSDN, MDC, W3C).

> Libraries like jQuery offer some simple, relatively-well-named
> functions for querying various sizes that you might want.  jQuery
> gives you .width() for the content box, .innerWidth() for the padding
> box, and .outerWidth() for the border box.
Yeah. It's so complicated, lets just use jQuery. I've seen that mental
pattern (mental pattern != reasoning) a thousand times.

And so often, the misguided use of jQuery leads them away from very
simple solutions like scrollWidth or offsetWidth.

Last I remember (over 1y), jQUery used offsetWidth for that in an
attempt to solve for all sorts of different things and even including
the width of either document or window, and either my memory is a mess
or it truly is that absurd. And IIRC Dojo tried to build getting the
margin box in their monolith function.

Me, I ust use whatever I need at the moment. And FWIW, I agree, these
APIs could use a bit of help.

> 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
clientWidth if you want the padding; scrollWidth if you don't.

> 3. content box, scrollable area
scrollWidth again.

> 4. padding box (+/- scrollbars?  Depends on exactly where the impl
> puts the scrollbars.)
> 5. border box
That's offsetWidth, again.

> Thoughts?
A new property for offsetTop and offsetLEft and the respective border
properties clientLeft and clientTop.

Style value reading/writing in wanted units, e.g. el.computedStyle.width.px.

I read somewhere about a year ago AVK's style proposal for getting and
setting numeric pixels via special getter/setter, something like what
I wrote above. It was rough, but seemed to be on the point of your
Received on Tuesday, 12 April 2011 01:46:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:45 UTC