Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How toMeasure Element Dimensions

Reply
Thread Tools

David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How toMeasure Element Dimensions

 
 
Gene Wirchenko
Guest
Posts: n/a
 
      11-11-2011
On Fri, 11 Nov 2011 09:59:56 -0000, "Richard Cornford"
<(E-Mail Removed)> wrote:

>Gene Wirchenko wrote:


[snip]

>> Another possibility is that it might be thought to work that
>> way with old versions of the language.

>
>Possibly, but it would be possible to check the older specs and observe
>that it should never have 'worked'. Older versions of browsers would be
>a better excuse, but not when it is found in code that is only designed
>to be supported by a known sub-set of 'current' browsers, as is the case
>with the 'popular' libraries that have featured this code.


Is it worth the time? It can be rather time-consuming to track
such things down. Cost-benefit analysis may lead to "Meh. Why
bother?"

>> At the point I am in JavaScript, I would not catch the
>> error. I might eventually since any code that I do not
>> understand tends to stick my attention.

>
>But at this point would you be publishing your code for use by the
>general (web-programming) public, claiming its inherent superiority to
>alternatives, pronouncing it as a demonstration of your abilities, and
>writing/selling javascript programming books off the back of it?


No. Even if I had very polished code, I might not even do it
even then.

>> But I might not have time to get to it.

>
>Yes, mistakes are often time consuming and inconvenient to reverse.
>That suggests limiting the scope of your early work, and learning from
>the mistakes before propagating the code to the rest of the world.


Oh, sure. Bring logic into it!

>>> people mistook it for an example of code written by someone who knew
>>> what they were doing, and so for a valid/meaningful/useful test.

>>
>> A beautiful example of ugliness.

>
>I don't know about "ugliness". Code-wise it is very similar to much that
>is justified, correct and sensible, which is probably one factor in
>preventing it from standing out as something that should have been
>questioned.


Extra verbiage that does nothing useful is ugly by my sense of
aesthetics.

Yes to your second sentence. A favourite quote of mine: "There
are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way
is to make it so complicated that there are no obvious deficiencies.
The first method is far more difficult." -- C.A.R. Hoare

Sincerely,

Gene Wirchenko
 
Reply With Quote
 
 
 
 
Dr J R Stockton
Guest
Posts: n/a
 
      11-11-2011
In comp.lang.javascript message <bd12b66f-33f5-43d2-8e22-6f81b42c3d8b@n1
4g2000vbn.googlegroups.com>, Thu, 10 Nov 2011 06:09:29, David Mark
<(E-Mail Removed)> posted:

>How to Measure Element Dimensions


It could be useful if there were, linked from within each posted Tip, a
Web Index of Tips, linking to Web copies.

One Tip might be the answer to "I have an on-screen element, of known
size, with an on[dbl]click method; how do I obtain the co-ordinates of a
[double-]click with respect to a given position in the element itself?"

The aforementioned index page could have a feedback form, partly for
suggesting topics for tips and possible answers. The latter, when
imperfect, would provide fodder for further Tips, of course.

In what appears to be the cinsoft home page, "By" should be "To".

Consider a page, <http://www.cinsoft.net/position.html>, which has been
found by a serendipitous Google search for "starting point for a move
animation" or otherwise. It recommends
o = getElementPositionStyles(el);
- and that does not work. The necessary further information is not
clearly provided; indeed, the page seems to have no <a href="...">Home
Page</a>.

--
(c) John Stockton, nr London UK. replyYYWW merlyn demon co uk Turnpike 6.05.
Web <http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes precede replies. Snip well. Write clearly. Mail no News.
 
Reply With Quote
 
 
 
 
Hans-Georg Michna
Guest
Posts: n/a
 
      11-12-2011
On Fri, 11 Nov 2011 00:36:57 -0000, Richard Cornford wrote:

>Welcome to the low entry cost world of browser scripting.
>
>So, an illustration, but which one? Try this, go to
><URL: http://www.google.com/codesearch >
>and in the search box at the top of the page enter the following line:-
>
>typeof\s*\(?\s*[\S]+\s*\)?\s*(!|=)==?\s*("|')array("|') lang:javascript
>
>- and do the search. It gets 4,000+ results (including from a
>cross-section of 'popular' libraries) along the lines of:-


Nice! I just got 19,000+ hits. Strange that it varies so much.

Anyway, do you have more examples? These would be good demos of
the general ignorance towards correct JavaScript programming.
Good for demos.

Hans-Georg
 
Reply With Quote
 
Eric Bednarz
Guest
Posts: n/a
 
      11-12-2011
"Richard Cornford" <(E-Mail Removed)> writes:

> document.write(
> "<scr"+"ipt type='text/javascript' src='"+tmps[x]+"'></scr"+"ipt>"
> );
>
> The cargo-cult programming structure is the first (left-most) string
> concatenation operation. The final (right-most) string concatenation
> operation has some justification in some contexts. Its use in those
> contexts demonstrates a shallow understanding of the reasons for its
> use (as there are more efficient, shorter and more formally correct
> alternatives), and it was almost certainly that shallow understanding
> that inspired the real cargo-cult structure to the left. However, One
> context where the final (right-most) concatenation is purposeless is
> when it is found in an imported JS file, which is of course where
> Google's code search is finding it. So that too is pushing cargo-cult
> programming in the contexts where it is being found above.


I’m getting the impression that you think that the purpose of splitting
and concatenating the generic identifier is somehow related to escaping
the ETAGO delimiter (‘</’), while it is much more likely to be related
to Norton ‘Internet Security’ inserting it’s dreaded SymError function
after the first instance of anything that looks like the start tag of a
script element (and ususally messing things up in the process).
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      11-12-2011
Eric Bednarz wrote:

> "Richard Cornford" <(E-Mail Removed)> writes:
>> document.write(
>> "<scr"+"ipt type='text/javascript' src='"+tmps[x]+"'></scr"+"ipt>"
>> );
>>
>> The cargo-cult programming structure is the first (left-most) string
>> concatenation operation. The final (right-most) string concatenation
>> operation has some justification in some contexts. Its use in those
>> contexts demonstrates a shallow understanding of the reasons for its
>> use (as there are more efficient, shorter and more formally correct
>> alternatives), and it was almost certainly that shallow understanding
>> that inspired the real cargo-cult structure to the left. However, One
>> context where the final (right-most) concatenation is purposeless is
>> when it is found in an imported JS file, which is of course where
>> Google's code search is finding it. So that too is pushing cargo-cult
>> programming in the contexts where it is being found above.

>
> I’m getting the impression that you think that the purpose of splitting
> and concatenating the generic identifier is somehow related to escaping
> the ETAGO delimiter (‘</’), while it is much more likely to be related
> to Norton ‘Internet Security’ inserting it’s dreaded SymError function
> after the first instance of anything that looks like the start tag of a
> script element (and ususally messing things up in the process).


Suppose that was the case, then it would be a Bad Idea to work around that.
Either it is a bug in Norton InSecurity, then working around it will help to
keep it forever, having everyone to jump forever through the hoops that
Symantec's incompetent, greedy developers once set up. Or it is a feature,
then one would ignore the user's wishes, which is always a bad idea.


PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$(E-Mail Removed)> (2004)
 
Reply With Quote
 
J.R.
Guest
Posts: n/a
 
      11-13-2011
On 10/11/2011 12:09, David Mark wrote:

> if (document.documentElement&& typeof
> document.documentElement.clientWidth == 'number') {
> var getInnerDimensions = function(el) {
> return [el.clientHeight, el.clientWidth];
> };
> }
>


Considering an element having scrollbars, we might use:

return [el.scrollTop + el.clientHeight,
el.scrollLeft + el.clientWidth];

Note: scrollWidth/scrollHeight are buggy in IE6-8 and Opera 10. So, we'd
need to compare (scrollTop + clientHeight) to scrollHeight too. In IE8,
scrollWidth is 5 pixels off. See
<http://www.quirksmode.org/dom/w3c_cssom.html>

--
Joao Rodrigues (J.R.)
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      11-13-2011
J.R. wrote:

> On 10/11/2011 12:09, David Mark wrote:
>> if (document.documentElement&& typeof
>> document.documentElement.clientWidth == 'number') {
>> var getInnerDimensions = function(el) {
>> return [el.clientHeight, el.clientWidth];
>> };
>> }
>>

>
> Considering an element having scrollbars, we might use:
>
> return [el.scrollTop + el.clientHeight,
> el.scrollLeft + el.clientWidth];


Please explain what the scroll position has to do with the element
dimensions.

> Note: scrollWidth/scrollHeight are buggy in IE6-8 and Opera 10
>
> So, we'd need to compare (scrollTop + clientHeight) to scrollHeight too.
> In IE8, scrollWidth is 5 pixels off. See
> <http://www.quirksmode.org/dom/w3c_cssom.html>


That states that *scrollHeight* is buggy in IE *5.5* to 7, and that
scrollWidth is _correct_ in those versions. It also states that scrollWidth
is 5 pixel off in IE 8, and that "Opera gives odd, incorrect values." Quite
different from what you stated.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
 
Reply With Quote
 
Jukka K. Korpela
Guest
Posts: n/a
 
      11-13-2011
2011-11-12 11:38, Hans-Georg Michna wrote:

>> typeof\s*\(?\s*[\S]+\s*\)?\s*(!|=)==?\s*("|')array("|') lang:javascript
>>
>> - and do the search. It gets 4,000+ results (including from a
>> cross-section of 'popular' libraries) along the lines of:-

>
> Nice! I just got 19,000+ hits. Strange that it varies so much.


And I got alternatingly 2,900 or 2,667.

It's not that strange that it varies. The common Google search is known
to give varying results depending on Google server used (e.g.
www.google.com vs. www.google.de), language settings, Google
customization options, cookies (carrying e.g. information about past
searches), browser and the request headers it sends, and possibly phase
of the moon. There is most probably intentional randomization, too, due
to Google testing new functionality or just carrying out A/B testing or
something similar.

Google code search may have any of these causes of variation, and maybe
some more too.

Moreover, the figures that Google tells us are, well, just figures it
tells us. They probably reflect some internal hit counts. But if you try
scan through the results, clicking on the last of the results page
number in the list at the bottom, you may observe that the hit count
drops at some point. In my test in this case, page 19 said
"Results 181 - 190 of 2,665"
but clicking on "Next" led to
"Your search - typeof\s*\(?\s*[\S]+\s*\)?\s*(!|=)==?\s*("|')array("|')
lang:javascript - did not match any documents."

In the common Google search, it seems that at some point, Google set an
upper limit of 999 on the number of hits it actually shows to the user.
That is, when the user proceeds from one hit page to the next, or takes
a shortcut via the page number links, Google stops showing results at
some point, apparently so that in no circumstances can you go past
result 999. So the count that it initially gives can be just about
anything. I don't think it's completely arbitrary, but it surely isn't a
reliable count of anything.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
 
Reply With Quote
 
J.R.
Guest
Posts: n/a
 
      11-13-2011
On 13/11/2011 01:31, Thomas 'PointedEars' Lahn wrote:
> J.R. wrote:
>
>> On 10/11/2011 12:09, David Mark wrote:
>>> if (document.documentElement&& typeof
>>> document.documentElement.clientWidth == 'number') {
>>> var getInnerDimensions = function(el) {
>>> return [el.clientHeight, el.clientWidth];
>>> };
>>> }
>>>

>>
>> Considering an element having scrollbars, we might use:
>>
>> return [el.scrollTop + el.clientHeight,
>> el.scrollLeft + el.clientWidth];

>
> Please explain what the scroll position has to do with the element
> dimensions.


The clientWidth and clientHeight properties return the width and height
of the content field, excluding borders and *scrollbars* (when visible),
but including padding. If the element's content overflows then the
browser might show scrollbars depending on the overflow CSS property. In
the latter case, clientWidth and clientHeight won't retrieve the
measurement of the hidden parts of the element's content.

A better approach would be using scrollWidth and scrollHeight, but these
properties are "buggy" in IE and Opera, according to
<http://www.quirksmode.org/dom/w3c_cssom.html#elementview>. The irony
here is that scrollWidth and scrollHeight were introduced by Microsoft
in their MSIE's DHTML object model...

Therefore, if we want a "getInnerDimensions" function to return the
correct dimensions for the element's content we will need to add the
scrollTop and scrollLeft values to the clientHeight and clientWidth
values respectively, otherwise we would not get the correct inner
dimensions if the element is scrolled all the way down or to the right.

But what if the element doesn't have scrollbars? No problem, because
scrollTop and scrollLeft will return zero.

>> Note: scrollWidth/scrollHeight are buggy in IE6-8 and Opera 10
>>
>> So, we'd need to compare (scrollTop + clientHeight) to scrollHeight too.
>> In IE8, scrollWidth is 5 pixels off. See
>> <http://www.quirksmode.org/dom/w3c_cssom.html>

>
> That states that *scrollHeight* is buggy in IE *5.5* to 7, and that
> scrollWidth is _correct_ in those versions. It also states that scrollWidth
> is 5 pixel off in IE 8, and that "Opera gives odd, incorrect values." Quite
> different from what you stated.


I don't think it is *quite* different, perhaps a *little* different...
In fact, it is better to avoid scrollWidth/scrollHeight whenever we need
a cross-browser code.

--
Joao Rodrigues (J.R.)
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      11-13-2011
J.R. wrote:

> Thomas 'PointedEars' Lahn wrote:
>> J.R. wrote:
>>> On 10/11/2011 12:09, David Mark wrote:
>>>> if (document.documentElement&& typeof
>>>> document.documentElement.clientWidth == 'number') {
>>>> var getInnerDimensions = function(el) {
>>>> return [el.clientHeight, el.clientWidth];
>>>> };
>>>> }
>>>
>>> Considering an element having scrollbars, we might use:
>>>
>>> return [el.scrollTop + el.clientHeight,
>>> el.scrollLeft + el.clientWidth];

>>
>> Please explain what the scroll position has to do with the element
>> dimensions.

>
> […]
> A better approach would be using scrollWidth and scrollHeight, but these
> properties are "buggy" in IE and Opera, according to
> <http://www.quirksmode.org/dom/w3c_cssom.html#elementview>. The irony
> here is that scrollWidth and scrollHeight were introduced by Microsoft
> in their MSIE's DHTML object model...
>
> Therefore, if we want a "getInnerDimensions" function to return the
> correct dimensions for the element's content we will need to add the
> scrollTop and scrollLeft values to the clientHeight and clientWidth
> values respectively, otherwise we would not get the correct inner
> dimensions if the element is scrolled all the way down or to the right.
>
> But what if the element doesn't have scrollbars? No problem, because
> scrollTop and scrollLeft will return zero.


And if I scroll down or right a scrollable element its content becomes
higher/wider?

>>> Note: scrollWidth/scrollHeight are buggy in IE6-8 and Opera 10
>>>
>>> So, we'd need to compare (scrollTop + clientHeight) to scrollHeight too.
>>> In IE8, scrollWidth is 5 pixels off. See
>>> <http://www.quirksmode.org/dom/w3c_cssom.html>

>>
>> That states that *scrollHeight* is buggy in IE *5.5* to 7, and that
>> scrollWidth is _correct_ in those versions. It also states that
>> scrollWidth
>> is 5 pixel off in IE 8, and that "Opera gives odd, incorrect values."
>> Quite different from what you stated.

>
> I don't think it is *quite* different, perhaps a *little* different...
> In fact, it is better to avoid scrollWidth/scrollHeight whenever we need
> a cross-browser code.


It is better to be aware of it and use *sensible* workarounds if necessary.
This is actually one case where property inference (window.opera) is useful
and acceptable; IE should be dealt with using Conditional Comments instead.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
David Mark's Essential Javascript Tips - Volume #8 - Tip #47E -Attaching and Detaching Event Listeners David Mark Javascript 1 12-17-2011 08:07 AM
David Mark's Daily Javascript Tips - Volume #3 - Tip #10 - How toCreate an XHR (Ajax) Object David Mark Javascript 8 12-10-2011 07:56 PM
David Mark's Daily Javascript Tips - Volume #3 - Tip #8 - How toCompute Styles David Mark Javascript 1 12-07-2011 02:34 AM
David Mark's Javascript Daily - Volume #3 - Tip #6 - How to Get andSet HTML David Mark Javascript 6 11-16-2011 06:51 PM
David Mark's Javascript Tip of the Day - Volume #1 - #Tip 14-C David Mark Javascript 16 11-11-2011 02:45 AM



Advertisments