Re: [cssom] Element size/positioning information

On 4/11/11, "Gérard Talbot" <www-style@gtalbot.org> wrote:
>
> Le Lun 11 avril 2011 18:46, Garrett Smith a écrit :
>> 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).
>
>
> Hello Garrett :)
>
Hey.

> You have to be careful too about specs and documentation websites from
> browser manufacturers. There are errors too in those. And browsers also
> have bugs too, you know :)
>
Yeah.

> There are at least 4 errors in the diagrams of this MSDN webpage:
>
> http://msdn.microsoft.com/en-us/library/ms533024.aspx
>
> 1- top and left offset properties are shown to be located between margin
> area and padding area: this is clearly wrong.

There isn't any margin area; AFAICT margin could be 0.

"The sample page contains a div element that is relatively positioned
on the page."

Whether or not offsetTop includes the border width (clientTop) depends
on the version and mode of IE. Yeah, so you can feature test that,
There are other quirks with offsetTop that vary from browser to
browser and depend on the element (table related elements and BODY
tend to be problems).

The previous MSDN diagram on
> "Measuring Element Dimension and Location" had the same mistake. Offset
> (left, top, bottom, right) values are applied to the CSS box, applied to
> the margin box.
>
> 2- div.scrollTop is not clearly and unambiguously identified: we do not
> see a double-head arrow establishing a measurement
>
> 3- div.scrollWidth is obviously much larger than shown... otherwise the
> horizontal scrollbar thumb is much too small, narrow. Either way, there is
> a contradiction, a blatant incoherence in the diagram.
>
> 4- div.style.border should be rather div.style.borderBottom as the 4
> borders have obviously different widths.
>
> General rule is to never trust a MSDN document; best is to test and verify
> empirically what is going on.
>
Don't trust them per se but do read them and then test; don't just
guess. The MSDN offsetTop docs reflect what IE8 does. but it's an
extreme example (-:.

And again, in IE, the offsetTop and offsetLeft values may include or
exclude border widths (clientTop, clientLeft) depending on the version
of IE. Recent versions include borders (measure from padding edge).
Opera flip flops on this, too. Standardizing offsetTop and offsetLeft
was obviously mistake. I tried to stop it; it was a painfully lost
battle of mine vs AVKs standardizing them.

[...]
>
>
> I am against jQuery and likes. With browser manufacturers getting really
> serious about identifying+tackling+fixing browser bugs and achieving
> compliance with new specs (eg CSSOM), I believe web authors do not need
> complex, heavy, monstruous js libraries (over 100Kbytes of unintelligible,
> nonsensical code).

CSSOM Views defines the unreliable offsetTop and offsetLeft. So while
I agree with the concept of standards support, CSSOM Views isn't good.
And besides, where's clientBottom and clientRight?

The ideas AVK was kicking around about a css values API seem to
address that. ... I think this is it:
http://annevankesteren.nl/2010/03/cssom-css-value-api

Also my idea which was to get values in a given unit. ... Yeah, I
think this one:
http://lists.w3.org/Archives/Public/www-style/2009Dec/0291.html
-- 
Garrett

Received on Tuesday, 12 April 2011 04:07:55 UTC