Re: [cssom] Element size/positioning information

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 :)

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 :)

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




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


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).

regards, Gérard
-- 
CSS 2.1 Test suite RC6, March 23rd 2011
http://test.csswg.org/suites/css2.1/20110323/html4/toc.html

Contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/

Web authors' contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/web-authors-contributions-css21-testsuite.html

Received on Tuesday, 12 April 2011 02:16:11 UTC