Prev: DOM ready, window.onload, etc.
Next: Chrome, canvas, PNG, Save Image As
From: David Mark on 28 Dec 2009 19:33
On Dec 28, 6:44 pm, GTalbot <newsgr...(a)gtalbot.org> wrote:
> On 28 déc, 12:32, moha297 <moha...(a)gmail.com> wrote:
>
> > I want to get the top and left values for a div on the screen.
>
> As Peter Michaux replied to you, your description of the problem for
> which you require assistance is not accurate, too general. An URL
> would have helped. And maybe, just maybe, you may be wrongly using
> offsetLeft and offsetTop to get the left and top values of a div on
> the screen. We can't be sure of this without a real webpage, URL.
>
> > I have been using the code to calculate the top and left values.
>
> > var total1 = 0;
> > var total2 = 0;
> > while(element){
> > total1+=element.offsetTop;
> > total2+=element.offsetLeft;
> > try{
> > element=element.offsetParent;
>
> > }catch(E){
> > break;
> > }
> > }
>
> First, the while statement does not make sense.
>
> You want an element (which is going to execute the controlled block)
> that has offsetTop and offsetLeft values to do the controlled block.
> Therefore, your while statement should be
>
> while (element.offsetParent) {..controlled block..}

Just don't pass orphaned elements. I imagine that's what that
mysterious try-catch was about.

> meaning as long as the current element being examined has an non-null
> offsetParent...

And it better not have typeof "unknown" either. ;)

>
> Second, using a try.. catch does not perfection make sense from a
> debugging perspective and from a property detection support.

Right. It's just hiding some other problem (code passing an orphaned
element).

> Let's say
> the assignment fails because the current element being examined in
> that while block does not have an offsetParent: why should it
> generates an exception or an error object?

It definitely can.

> Anyway, try.. catch is for
> managing exceptions, for debugging purposes. At least, this is what I
> would want to do when choosing to add a try...catch.

Right. There should not be a try-catch here.

> And here, you do
> not even try to identify the error message, error line, type of error,
> etc.. So why resort to a try..catch block anyway?

Exactly. It's just covering up a problem.

>
> Third, your local variable identifiers (total1, total2) are not
> recommendable. You should always try to choose identifiers for
> variables that are meaningful, intuitive, that helps debugging, code
> maintenance, examining in debugging tools, that helps review by others
> who may not be accustomed to your internal function logic (or help
> review by yourself years later). This helps everyone and can make a
> huge difference when the code is very long, complex, with many
> intricated functions.
>
> Here's how I did the same function 7 years ago:
>
> var Element = evt.target ;
> var CalculatedTotalOffsetLeft = CalculatedTotalOffsetTop = 0 ; while
> (Element.offsetParent)
> {
>   CalculatedTotalOffsetLeft += Element.offsetLeft ;
>   CalculatedTotalOffsetTop += Element.offsetTop ;
>   Element = Element.offsetParent ;
>
> } ;
>
> OffsetXForNS6 = evt.pageX - CalculatedTotalOffsetLeft ;
> OffsetYForNS6 = evt.pageY - CalculatedTotalOffsetTop ;
>
> http://www.gtalbot.org/DHTMLSection/WindowEventsNS6.html#screenLeft#N...
>
> http://www.gtalbot.org/DHTMLSection/WindowEventsIE6.html#screenLeft#N...

That doesn't take borders into account. If you _must_ measure all the
way to the document origin (virtually never), use
getBoundingClientRect.

>
> > For the same DOM TREE this code is giving a performance reading of
> > 30msec in IE8 and 80 to 200msec in IE6. I want to gain a considerable
> > performance improvement in IE6.
>
> IE6 <sigh ..  Why do you need to support IE6?>.

Because lots of corporate users are stuck with it? And because
there's virtually no difference with IE7. And then there are the
browsers that copied IE6 oddities...

> Imagine that people
> are less and less using that browser and that IE8 implemented an
> improved offsetParent, offsetLeft and offsetTop model.

Yes, less people are using IE6. IE6-8 (and perhaps earlier) all have
getBoundingClientRect (and other browsers have copied). But it is
much simpler and less problematic to measure to the origin of a
positioned ancestor.

>
> With those numbers, don't you want to tell your IE6 users to upgrade
> or to switch? It would solve many many problems...

Because you can't tell users to upgrade their browsers. Some can't
upgrade them. Some don't know what a browser _is_. ;)

>
> "30msec in IE8 and 80 to 200msec" does not mean much if we do not know
> on which machine (CPU, RAM, video card, etc) these results are
> gathered from. 30msec is very long for a super-computer and 200msec is
> very fast on a Pentium 1 90Mhz.
>
> If nodeA is an area HTML element which has a map HTML element
> somewhere in the ancestor chain, then nodeA.offsetParent returns the
> nearest ancestor map HTML element... but that is not the case in IE 7;
> IE8 corrected this.
>
> http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/CSSOM-offsetParen...

Skip the image maps and you'll be fine.

[...]

>
> Why is performance important to you, with regards to offsetTop and
> offsetLeft and with regards to IE 6?
> Please elaborate.
>
> (There is such a thing has having an overexcessive number of
> positioned containers (like nested tables)... in a very bloated
> webpage)

Yes. And there is such a thing as making one of them
position:relative. ;)

>
> > I found that the bulk of the time is always spent in getting property
> > value rather than parsing the DOM TREE which less constantly from my
> > logs.(I might be wrong)
>
> Post an URL according to the constraints I gave you.
>
> And if you are open to all ideas, then add a IE6nomore or IE6RIP
> button in your webpage so that people get the message that IE6 is
> buggy, not recommendable, etc. should upgrade or switch.

Hell no. You _never_ insult the user's browser. They may not be able
(or know how) to upgrade.
From: David Mark on 28 Dec 2009 19:36
On Dec 28, 1:01 pm, Peter Michaux <petermich...(a)gmail.com> wrote:
> On Dec 28, 11:32 am, moha297 <moha...(a)gmail.com> wrote:
>
>
>
> > I want to get the top and left values for a div on the screen.
>
> physical screen or upper-left corner of the page (which may be out of
> view if the page is scrolled.)?
>
> As Richard Cornford has mentioned here many times, this problem is not
> solved in general. If your div has parents that scroll, have table
> elements, is a button, etc, then the calculation of the div's upper-
> left corner relative to the upper-left corner of the page is complex.
>

It's been done. It's just not an advisable cross-browser design to
rely on such complex code when simpler options are available.
From: GTalbot on 28 Dec 2009 20:53
On 28 déc, 19:33, David Mark <dmark.cins...(a)gmail.com> wrote:
> On Dec 28, 6:44 pm, GTalbot <newsgr...(a)gtalbot.org> wrote:
>
>
>
> > On 28 déc, 12:32, moha297 <moha...(a)gmail.com> wrote:
>
> > > I want to get the top and left values for a div on the screen.
>
> > As Peter Michaux replied to you, your description of the problem for
> > which you require assistance is not accurate, too general. An URL
> > would have helped. And maybe, just maybe, you may be wrongly using
> > offsetLeft and offsetTop to get the left and top values of a div on
> > the screen. We can't be sure of this without a real webpage, URL.
>
> > > I have been using the code to calculate the top and left values.
>
> > > var total1 = 0;
> > > var total2 = 0;
> > > while(element){
> > > total1+=element.offsetTop;
> > > total2+=element.offsetLeft;
> > > try{
> > > element=element.offsetParent;
>
> > > }catch(E){
> > > break;
> > > }
> > > }
>
> > First, the while statement does not make sense.
>
> > You want an element (which is going to execute the controlled block)
> > that has offsetTop and offsetLeft values to do the controlled block.
> > Therefore, your while statement should be
>
> > while (element.offsetParent) {..controlled block..}
>
> Just don't pass orphaned elements.


I do not understand your "Just don't pass orphaned elements." .. or
I'm not sure I understand what you mean to say.

If the currently tested element has no offsetParent, then the
controlled block is not executed and the execution continues, carries
on, goes out of the while loop. Isn't that what is sought here?


> > Let's say
> > the assignment fails because the current element being examined in
> > that while block does not have an offsetParent: why should it
> > generates an exception or an error object?
>
> It definitely can.

Yes, you're right. If the assignment fails, then there should be an
exception created. I got mixed up with something else.

Sometimes the assignment succeeds but the resulting expression is
evaluated as false.

if(a = b) {... controlled block ...};

if b == 0, then the controlled block may not be executed even though
the assignment was successfully executed. So, it shouldn't be what the
coder expected.


> > var Element = evt.target ;
> > var CalculatedTotalOffsetLeft = CalculatedTotalOffsetTop = 0 ; while
> > (Element.offsetParent)
> > {
> >   CalculatedTotalOffsetLeft += Element.offsetLeft ;
> >   CalculatedTotalOffsetTop += Element.offsetTop ;
> >   Element = Element.offsetParent ;
>
> > } ;
>
> > OffsetXForNS6 = evt.pageX - CalculatedTotalOffsetLeft ;
> > OffsetYForNS6 = evt.pageY - CalculatedTotalOffsetTop ;


> That doesn't take borders into account.  If you _must_ measure all the
> way to the document origin (virtually never), use
> getBoundingClientRect.


Borders. This is news to me. I'll have to verify this some day.


> > > For the same DOM TREE this code is giving a performance reading of
> > > 30msec in IE8 and 80 to 200msec in IE6. I want to gain a considerable
> > > performance improvement in IE6.
>
> > IE6 <sigh ..  Why do you need to support IE6?>.
>
> Because lots of corporate users are stuck with it?  And because
> there's virtually no difference with IE7.

As far as offsetParent, offsetLeft and offsetTop are involved, there
is very little difference between IE6 and IE7: only 1 difference,
IIRC.
There are some/more differences between IE 6 and IE 7 with regards to
positioniseverything.net bugs

Explorer Exposed
http://www.positioniseverything.net/explorer.html

> And then there are the
> browsers that copied IE6 oddities...
>
> > Imagine that people
> > are less and less using that browser and that IE8 implemented an
> > improved offsetParent, offsetLeft and offsetTop model.
>
> Yes, less people are using IE6.  IE6-8 (and perhaps earlier) all have
> getBoundingClientRect (and other browsers have copied).  But it is
> much simpler and less problematic to measure to the origin of a
> positioned ancestor.

When the ancestor is positioned (non-static), yes. But what happens
when the elements are within a table or within nested tables? I think
you still have to resort to offsetParent.

> > With those numbers, don't you want to tell your IE6 users to upgrade
> > or to switch? It would solve many many problems...
>
> Because you can't tell users to upgrade their browsers.

I try to invite them to upgrade and try to address their intelligence
at all times. Ultimately, it's all up to them to decide. But I don't
hide (or don't try to hide) to them that IE6 is very buggy,
unreliable, not-trustworthy, etc. I certainly want them to know and
understand that web-capable softwares (or any kind of softwares)
should be using the latest stable available version for all kinds of
reasons: security, bug fixes, stability, speed, accessibility and
usability features, etcetctectcc.

> Some can't
> upgrade them.  

Often, these people can still/nevertheless install an alternate
browser.

In June 11th 2009 in the US, television signal stopped being for
analog tv; about 15% of users could no longer get local tv. In Canada,
the deadline for getting ready for digital-only tv signal is august
2011. It's roughly the same for other countries regarding the
transition to digital tv.
If you have to buy a new tv because of technological reasons (and FCC
and government rules), then I don't understand why corporate users can
not upgrade their browser softwares. They certainly were warned in the
past that their applications shouldn't be entirely dependent on
Microsoft products and Microsoft Windows platform.

The top 20 IT mistakes to avoid, November 19, 2004
11. Developing Web apps for IE only
http://www.infoworld.com/d/developer-world/top-20-it-mistakes-avoid-314?page=0,3


> Some don't know what a browser _is_.  ;)

Those (like seniors) are the most difficult portion of the market.
There's very little you can do ... unless you're a friend of them and
you visit them at home.

[snipped]


> > And if you are open to all ideas, then add a IE6nomore or IE6RIP
> > button in your webpage so that people get the message that IE6 is
> > buggy, not recommendable, etc. should upgrade or switch.
>
> Hell no.  You _never_ insult the user's browser.  They may not be able
> (or know how) to upgrade.

If your message is not agressive or on purpose bashing the browser
itself, if you invite diplomatically to upgrade or switch and if you
address their intelligence, then those who can may do so. Those who
can not .. whatever the reasons .. will not.

It is objectively still in the user's best interests to always use the
most updated stable release (for countless of reasons) of any software
(s)he may be using.

regards, Gérard
From: Garrett Smith on 28 Dec 2009 21:38
Peter Michaux wrote:
> On Dec 28, 11:32 am, moha297 <moha...(a)gmail.com> wrote:
>> I want to get the top and left values for a div on the screen.
>
> physical screen or upper-left corner of the page (which may be out of
> view if the page is scrolled.)?
>
> As Richard Cornford has mentioned here many times, this problem is not
> solved in general. If your div has parents that scroll, have table
> elements, is a button, etc, then the calculation of the div's upper-
> left corner relative to the upper-left corner of the page is complex.
>
OffsetTop and offsetParent are really bad legacy features. They're
defined using circular definition. See MSDN:
| OffsetTop:
| Retrieves the calculated top position of the object relative to the
| layout or coordinate parent, as specified by the offsetParent
| property.
http://msdn.microsoft.com/en-us/library/ms534302(VS.85).aspx

| OffsetParent:
| Retrieves a reference to the container object that defines the
| offsetTop and offsetLeft properties of the object.
http://msdn.microsoft.com/en-us/library/ms534302(VS.85).aspx

Other borwsers, desparate to get sites to work, copied the badly defined
features differently.

In addition to the cases you mentioned, the OP's function will fail when
offsetParent has a border (in most browsers).

The CSSOM Views editor had tried to factor in offsetParent's borderWidth
to the equation, and that was implemented for a year or so like that in
Opera (I believe Mac IE had similar behavior). FInally the draft was
changed to match what IE (windows) does. CSSOM Views makes body "magic"
and IE8 changed behavior from IE7 to behave this way.

Recent browsers and IE from version 5 implement
element.getBoundingClientRect.

The method fails miserably on Opera mini by returning Device Pixels
instead of CSS Pixels. Otherwise, it is very fast, simple and easy to use:-

var body = document.body,
box = document.body.getBoundingClientRect();
box.top; // 8
box.left; // 8

// Unreliable.
body.offsetTop;
body.offsetLeft;

Otherwise, if the compatibility with more browsers is needed, consider
solving the problem in a way that allows for your program to function
properly, possibly allowing for addition of borders to the element, but
not measuring offsets of TABLE or BODY.

[snip]
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 28 Dec 2009 21:41
On Dec 28, 8:53 pm, GTalbot <newsgr...(a)gtalbot.org> wrote:
> On 28 déc, 19:33, David Mark <dmark.cins...(a)gmail.com> wrote:
>
>
>
> > On Dec 28, 6:44 pm, GTalbot <newsgr...(a)gtalbot.org> wrote:
>
> > > On 28 déc, 12:32, moha297 <moha...(a)gmail.com> wrote:
>
> > > > I want to get the top and left values for a div on the screen.
>
> > > As Peter Michaux replied to you, your description of the problem for
> > > which you require assistance is not accurate, too general. An URL
> > > would have helped. And maybe, just maybe, you may be wrongly using
> > > offsetLeft and offsetTop to get the left and top values of a div on
> > > the screen. We can't be sure of this without a real webpage, URL.
>
> > > > I have been using the code to calculate the top and left values.
>
> > > > var total1 = 0;
> > > > var total2 = 0;
> > > > while(element){
> > > > total1+=element.offsetTop;
> > > > total2+=element.offsetLeft;
> > > > try{
> > > > element=element.offsetParent;
>
> > > > }catch(E){
> > > > break;
> > > > }
> > > > }
>
> > > First, the while statement does not make sense.
>
> > > You want an element (which is going to execute the controlled block)
> > > that has offsetTop and offsetLeft values to do the controlled block.
> > > Therefore, your while statement should be
>
> > > while (element.offsetParent) {..controlled block..}
>
> > Just don't pass orphaned elements.
>
> I do not understand your "Just don't pass orphaned elements." .. or
> I'm not sure I understand what you mean to say.

Orphaned (removed from the document) elements can become ActiveX
objects behind the scenes. IIRC, orphaning by innerHTML replacement
is a sure bet.

if (typeof element.offsetParent == 'unknown') {
(element.offsetParent); // Boom
}

So you wouldn't normally pass such an element to such a function
(offset position makes no sense for orphans). The try-catch hides
such mistakes.

>
> If the currently tested element has no offsetParent, then the
> controlled block is not executed and the execution continues, carries
> on, goes out of the while loop. Isn't that what is sought here?

See above. Just evaluating it is enough to trigger an exception.

>
> > > Let's say
> > > the assignment fails because the current element being examined in
> > > that while block does not have an offsetParent: why should it
> > > generates an exception or an error object?
>
> > It definitely can.
>
> Yes, you're right. If the assignment fails, then there should be an
> exception created. I got mixed up with something else.
>
> Sometimes the assignment succeeds but the resulting expression is
> evaluated as false.
>
> if(a = b) {... controlled block ...};
>
> if b == 0, then the controlled block may not be executed even though
> the assignment was successfully executed. So, it shouldn't be what the
> coder expected.
>
> > > var Element = evt.target ;
> > > var CalculatedTotalOffsetLeft = CalculatedTotalOffsetTop = 0 ; while
> > > (Element.offsetParent)
> > > {
> > >   CalculatedTotalOffsetLeft += Element.offsetLeft ;
> > >   CalculatedTotalOffsetTop += Element.offsetTop ;
> > >   Element = Element.offsetParent ;
>
> > > } ;
>
> > > OffsetXForNS6 = evt.pageX - CalculatedTotalOffsetLeft ;
> > > OffsetYForNS6 = evt.pageY - CalculatedTotalOffsetTop ;
> > That doesn't take borders into account.  If you _must_ measure all the
> > way to the document origin (virtually never), use
> > getBoundingClientRect.
>
> Borders. This is news to me. I'll have to verify this some day.

Just search the archive or the Web. You have to include the borders
(clientLeft/Top) in most browsers (it's something that has to be
tested). Some older Opera's were broken in this regard.

>
> > > > For the same DOM TREE this code is giving a performance reading of
> > > > 30msec in IE8 and 80 to 200msec in IE6. I want to gain a considerable
> > > > performance improvement in IE6.
>
> > > IE6 <sigh ..  Why do you need to support IE6?>.
>
> > Because lots of corporate users are stuck with it?  And because
> > there's virtually no difference with IE7.
>
> As far as offsetParent, offsetLeft and offsetTop are involved, there
> is very little difference between IE6 and IE7: only 1 difference,
> IIRC.
> There are some/more differences between IE 6 and IE 7 with regards to
> positioniseverything.net bugs

There are a few. Most (if not all) are avoidable.

>
> Explorer Exposedhttp://www.positioniseverything.net/explorer.html
>
> > And then there are the
> > browsers that copied IE6 oddities...
>
> > > Imagine that people
> > > are less and less using that browser and that IE8 implemented an
> > > improved offsetParent, offsetLeft and offsetTop model.
>
> > Yes, less people are using IE6.  IE6-8 (and perhaps earlier) all have
> > getBoundingClientRect (and other browsers have copied).  But it is
> > much simpler and less problematic to measure to the origin of a
> > positioned ancestor.
>
> When the ancestor is positioned (non-static), yes. But what happens
> when the elements are within a table or within nested tables? I think
> you still have to resort to offsetParent.

I didn't mean that you didn't have to use offsetParent at all. I mean
limit the number of "hops" and stop short of the body (unless it has
position:relative).

>
> > > With those numbers, don't you want to tell your IE6 users to upgrade
> > > or to switch? It would solve many many problems...
>
> > Because you can't tell users to upgrade their browsers.
>
> I try to invite them to upgrade and try to address their intelligence
> at all times.

See, the typical user don't want to hear about their intelligence.
Thin ice. :)

> Ultimately, it's all up to them to decide. But I don't
> hide (or don't try to hide) to them that IE6 is very buggy,
> unreliable, not-trustworthy, etc.

That's ridiculous. If your page is buggy and/or unreliable, the user
will (rightfully) blame _you_. No amount of blaming the browser will
move them (as well it should not).

> I certainly want them to know and
> understand that web-capable softwares (or any kind of softwares)
> should be using the latest stable available version for all kinds of
> reasons: security, bug fixes, stability, speed, accessibility and
> usability features, etcetctectcc.
>
> > Some can't
> > upgrade them.  
>
> Often, these people can still/nevertheless install an alternate
> browser.

Some can and some can't.

>
> In June 11th 2009 in the US, television signal stopped being for
> analog tv; about 15% of users could no longer get local tv. In Canada,
> the deadline for getting ready for digital-only tv signal is august
> 2011. It's roughly the same for other countries regarding the
> transition to digital tv.
> If you have to buy a new tv because of technological reasons (and FCC
> and government rules), then I don't understand why corporate users can
> not upgrade their browser softwares.

You don't need to understand everything to be successful. ;)

> They certainly were warned in the
> past that their applications shouldn't be entirely dependent on
> Microsoft products and Microsoft Windows platform.
>
> The top 20 IT mistakes to avoid, November 19, 2004
> 11. Developing Web apps for IE onlyhttp://www.infoworld.com/d/developer-world/top-20-it-mistakes-avoid-3...

That's another topic altogether. Some corporate users are simply
stuck with IE6/7 and will be for years. In most cases, it has nothing
to do with building IE-only websites.

>
> > Some don't know what a browser _is_.  ;)
>
> Those (like seniors) are the most difficult portion of the market.

Lots of PC-savvy corporate users are clueless about browsers and/or
disallowed from making decisions about which browsers to use.

> There's very little you can do ... unless you're a friend of them and
> you visit them at home.

Sounds like a very hard way to go. They won't let you waltz into
corporate sites changing browsers anyway. I don't think you have time
to visit every "senior" at home either. So tackle the problem from
the other end. ;)

>
> [snipped]
>
> > > And if you are open to all ideas, then add a IE6nomore or IE6RIP
> > > button in your webpage so that people get the message that IE6 is
> > > buggy, not recommendable, etc. should upgrade or switch.
>
> > Hell no.  You _never_ insult the user's browser.  They may not be able
> > (or know how) to upgrade.
>
> If your message is not agressive or on purpose bashing the browser
> itself, if you invite diplomatically to upgrade or switch and if you
> address their intelligence, then those who can may do so. Those who
> can not .. whatever the reasons .. will not.

Nobody wants to hear about it from your site, unless your site is
about browsers.

>
> It is objectively still in the user's best interests to always use the
> most updated stable release (for countless of reasons) of any software
> (s)he may be using.

See above for various reasons why not.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: DOM ready, window.onload, etc.
Next: Chrome, canvas, PNG, Save Image As