Absolute element offsets--exercise in futility

[David Mark]

It was recently opined here that upgrading a complex, interdependent
script like jQuery (or whatever) was only an issue if calling apps
made use of the parts touched by the loosely organized "team" of
developers.

Unfortunately, when you first attempt to take the giant leap from
browser sniffing to feature detection (all at once and ten years
late), you end up with fingerprints all over everything.

I recently noticed a plug for jQuery's reenactment of that favorite of
browser scripting neophytes: calculating offset positions. For the
uninitiated, a cross-browser solution to calculate *absolute* offsets
(from the "origin" of the HTML element) is strictly an academic
exercise. Production apps are *never* designed to rely on such
problematic measurements.

Since the early part of the century, "solutions" involved two
branches, one for IE using the proprietary getBoundingClientRect
(recently adopted by FF and Opera) and a loop adding offsetLeft/Top
(plus clientLeft/Top) properties in everything else. Occasionally, a
third branch would use getBoxObjectFor (now deprecated) in Mozilla-
based browsers. In a few specific contexts, viable solutions are
possible. In a general sense, attempting to solve this "problem" at
all is madness.

As jQuery's old rendition of this classic used browser sniffing
exclusively, the version of the offset method in 1.3x has changed
radically. As would be expected, so has its behavior across the
handful of browsers supported by jQuery. Certainly this is part of
the reason that jQuery only supports browsers released in the last
couple of years.

A useful and pragmatic function would have been one that calculated
the offset from its nearest positioned parent. For example, the body:

http://groups.google.com/group/jquery-dev/browse_thread/thread/5107d8bf230a3721#

"Greetings, fellow developers!

First of all, I would like to thank you guys for putting in so much
time and effort on this amazing framework. This will be basically a
repost of another email I sent to jquery ui, along with a ticket
filled on their bug tracking system, regarding to the behaviour of one
of the widgets in the presence of a positioned body element."

Poor bastard.

"Just write your own function that uses jquery's return value and adds
in your calculations for your offset body.

Matt Kruse"

Sure, use a just-released version of an impossible absolute position
function then adjust to suit!

Two more studied opinions on the OP's dilemna:

"Regardless of jQuery support or not, I am the only one who thinks
positioning the body is kind of weird? what's between the body and the
viewport limits, limbo?"

Yes, silly. That's the part you *don't* want to measure.

"No, you're not the only one. I, too was wondering why someone would
need to position the body."

The OP tried to be sane and asked for help. He got one disinegenuous
detour from a fanboy and tittering from the resident technicians.

More futility on this front:

http://groups.google.com/group/jquery-dev/browse_thread/thread/8f258f8d9ef4a23f#

http://groups.google.com/group/jquery-dev/browse_thread/thread/6b8770d069db1872

http://www.nabble.com/bug-report:-j...-(works-fine-with-1.2.6)-p22889489s27240.html

At least one of those recommends transplanting the 1.2x absolute
position function into 1.3x. Abbie something?

So what will they invent to smooth out the differences between jQuery
versions?

 

[rf]

It was recently opined here that upgrading a complex, interdependent
script like jQuery

Do we really need any more shit about jQuery here?

It's a dog. Let it die.

 

[David Mark]

Do we really need any more shit about jQuery here?

I think this issue is about more than jQuery. Though, as is usually
the case, it is the poster child for futility.

It's a dog. Let it die.

It is going to need some help.

 

[Matt Kruse]

[snip more jQuery ramblings]

Your mantra is getting boring.

Once again, you toss out something to the effect of "look how stupid
these people are!" yet offer no real incite into the problem or the
solution.

Yet I'm kind of flattered that you seem to be following my posts about
jQuery. It's cute.

Production apps are *never* designed to rely on such
problematic measurements.

You are fortunate that you can stay within your box. Not all
developers work in that mode.

Matt Kruse

 

[David Mark]

[snip more jQuery ramblings]

Ramblings?


Your mantra is getting boring.

Once again, you toss out something to the effect of "look how stupid
these people are!" yet offer no real incite into the problem or the
solution.

You don't pick up anything on a first read, do you? I offered insight
into several issues.

Yet I'm kind of flattered that you seem to be following my posts about
jQuery. It's cute.

I don't follow your posts. I searched for "jQuery", "offset" and
"bug."

You are fortunate that you can stay within your box. Not all
developers work in that mode.

I know. Some dumbshits would actually measure all the way to the top
of the HTML and then try to work backwards to the positioned body.
Some might even recommend such an approach to newcomers (possibly with
a version of a debunked script that they themselves haven't even
used.) Nothing surprises me anymore.

And, as you know, theirs looks suspiciously like my take, just years
too late. If I am the one who designed the box and I tell you the box
isn't worth getting into, what does that mean to you? Remember what I
said about browser sniffing, attributes vs. properties, etc.? Am I
wrong on this one or shouldn't you be listening?

 

[David Mark]

[snip more jQuery ramblings]

Your mantra is getting boring.

Once again, you toss out something to the effect of "look how stupid
these people are!" yet offer no real incite into the problem or the
solution.

Here's an incite (sic) for you:

New IE branch:

jQuery.fn.offset = function() {
if ( !this[0] ) return { top: 0, left: 0 };
if ( this[0] === this[0].ownerDocument.body ) return
jQuery.offset.bodyOffset( this[0] );
var box = this[0].getBoundingClientRect(), doc = this
[0].ownerDocument, body = doc.body, docElem = doc.documentElement,
clientTop = docElem.clientTop || body.clientTop || 0, clientLeft =
docElem.clientLeft || body.clientLeft || 0,
top = box.top + (self.pageYOffset || jQuery.boxModel &&
docElem.scrollTop || body.scrollTop ) - clientTop,
left = box.left + (self.pageXOffset || jQuery.boxModel &&
docElem.scrollLeft || body.scrollLeft) - clientLeft;
return { top: top, left: left };
};

Old IE branch:

var box = elem.getBoundingClientRect();

// Add the document scroll offsets
add(box.left + Math.max(doc.documentElement.scrollLeft,
doc.body.scrollLeft),
box.top + Math.max(doc.documentElement.scrollTop,
doc.body.scrollTop));

// IE adds the HTML element's border, by default it is medium which is
2px
// IE 6 and 7 quirks mode the border width is overwritable by the
following css html { border: 0; }
// IE 7 standards mode, the border is always 2px
// This border/offset is typically represented by the clientLeft and
clientTop properties
// However, in IE6 and 7 quirks mode the clientLeft and clientTop
properties are not updated when overwriting it via CSS
// Therefore this method will be off by 2px in IE while in quirksmode
add( -doc.documentElement.clientLeft, -
doc.documentElement.clientTop );

Beware of long comments like that. The line that follows is obviously
a mistake and was identified as such to John Resig (as you well
know.) This is the simplest of the two branches (obviously.) Care to
look at the other?

It has been changed (a year and a half later) along with virtually
everything else in this script (e.g. browser sniffing, attributes, XML
documents, etc.), with virtually no documentation of what has changed
and why. No innovation either, just lots of undocumented changes.

Most apps, widgets, etc. didn't need an absolute position function and
there were much better ones written in 2003 (certainly ones that would
work in IE quirks mode!) What possessed you to recommend this re-
imagining, which you have never installed? It's called "jQuery?"

 

[Lawrence Krubner]

Do we really need any more shit about jQuery here?

It's a dog. Let it die.

My sense is that JQuery is growing in popularity. I recall 3 years ago
my graphic designer friends were trying to figure out how to use
prototype/scriptaculous so they could get cool visual transitions into
their pages without having to use Flash. But at some point in the last
18 months, it seems to me there has been some kind of mass conversion
to JQuery. In 2006 I got a lot of phone calls that went "Hey, I can't
get scriptaculous to work, can you help me?" but nowadays it is always
"Hey, I can't get jQuery to work, can you help me?"

Consider what Shelly Powers writes in her 2007 book, Adding Ajax. This
is from page 93:

"One library that's gaining popularity is jQuery, available at
http://jquery.com. It's small, fast, and provides fundamental cross-
browser methods to work with the DOM rather than higher-order effects.

The Interface library, found at http://interface.eyecon.ro, provides
higher-order effects for jQuery, similar to what script.aculo.us
provides for Prototype.

....jQuery provides a high degree of chainability, which is the ability
to chain function calls, one after the other. This type of
functionality requires that the library object methods return a
reference to the object itself, which is used in the next method in
the chain. Creating effects using jQuery is greatly simplified because
of this chaining."

So long as jQuery continues to get favorable press, such as this, I
suspect its popularity will continue to climb. Especially when the
favorable coverage is coming from a respected publishing house such as
O'Reilly.

 

[Lawrence Krubner]

I think this issue is about more than jQuery.  Though, as is usually
the case, it is the poster child for futility.

Surely you are smart enough to understand the rich irony of attacking
"futility" when you are using the newsgroup comp.lang.javascript to
gripe about a library that is getting favorable coverage from major
publishing houses and from the magazines that graphic designers read?
Take, for instance, this article in Smashing Magazine:

http://www.smashingmagazine.com/2009/01/15/45-new-jquery-techniques-for-a-good-user-experience/

At least in my world, the adoption of jQuery is being driven by
graphic designers who want to get cool visual effects on to their web
pages, but without using Flash. And the designers I know read sites
like Smashing Magazine, rather than comp.lang.javascript

The other thing driving the adoption of jQuery is its use in themes
that then become inspirations for other themes. Consider this post by
Darren Hoyt:

http://www.darrenhoyt.com/2008/09/14/notes-on-the-agregado-theme/

"We did run into some trouble here: for the jQuery bit to work, each
<a> tag in the nav needed a class of “trigger”, but wp_list_categories
only attaches a class to the <li>. So Matt was able to use a bit of
jQuery magic to dynamically add the class, although it’s not visible
in the source code unless you’re inspecting with a tool like Firebug.
It was cool to see how that was done and it’s already inspired a
couple more ideas for future themes."

Thousands of designers look to Hoyt's work for inspiration, so the
fact that Hoyt is using jQuery validates the decision to use jQuery in
the minds of all the designers who are imitating him.

 

[David Mark]

My sense is that JQuery is growing in popularity. I recall 3 years ago

Has grown. Is at the apex of its absurdity. In short, jQuery claims
to be "Write Less. Do More." I say, even if it was, it pales in
comparison with "Write Once. Do Nothing." jQuery is introducing
"overhauls" in the year 2009 on issues that were settled in 2001,
still doesn't have them right (as evidenced by the disruption in
upgrading the script and/or its dependencies) and the authors do not
appear to understand most of the issues anyway.

my graphic designer friends were trying to figure out how to use
prototype/scriptaculous so they could get cool visual transitions into

Your graphic designer friends shouldn't play with browser scripting.

their pages without having to use Flash. But at some point in the last

Admirable ambition. Of course, they likely shouldn't play with Flash
either (usually involves Other People's Scripts.)

18 months, it seems to me there has been some kind of mass conversion
to JQuery. In 2006 I got a lot of phone calls that went "Hey, I can't
get scriptaculous to work, can you help me?" but nowadays it is always
"Hey, I can't get jQuery to work, can you help me?"

Prototype died out. jQuery is next. That's what happens to bad
ideas.

Consider what Shelly Powers writes in her 2007 book, Adding Ajax. This
is from page 93:
Who?


"One library that's gaining popularity is jQuery, available athttp://jquery.com. It's small, fast, and provides fundamental cross-
browser methods to work with the DOM rather than higher-order effects.

Small is relative. So is fast. Compared to any context-specific
solution, jQuery is bloated and slow. No app actually needs to query
by all of those selectors, set attributes directly, calculate absolute
positions on arrays of elements, XML and HTML alike, etc. Certainly
no app needs to do all of those things that slowly, that expensively
and that *badly*.

Cross-browser? Not even close. With the rate that jQuery apps rot,
tickets ripen on the vine and the list of supported browsers shortens,
it won't be long before every supported browser will have QSA and
animations built-in. So it is a multi-browser mechanical Turk, manned
by neophytes with features rapidly approaching superfluous.

Even worse, as we have seen, the miserable thing introduced its own
list of jQuery quirks and incompatibilities, negating the recent
stability among the quasi-standards-based browsers and somehow failing
to grasp basic issues present in IE6/7 prior to the release of IE8.

Shelly shouldn't write books about browser scripting.

The Interface library, found athttp://interface.eyecon.ro, provides
higher-order effects for jQuery, similar to what script.aculo.us
provides for Prototype.

Who cares?

...jQuery provides a high degree of chainability, which is the ability
to chain function calls, one after the other. This type of
functionality requires that the library object methods return a
reference to the object itself, which is used in the next method in
the chain. Creating effects using jQuery is greatly simplified because
of this chaining."

The chaining strategy is completely idiotic and ill-advised
(especially for beginners.) It requires the use of a debugger in IE
and, as we have seen, such debuggers are not even in use by the jQuery
developers.

Still, any object method can be chained in Javascript, they just have
to:

return this;

That's it. It's stupid. Don't do it. Doesn't matter if it is the
primary allure of a terrible script that has Shelly and others under
its spell. It is still a terrible idea.

So long as jQuery continues to get favorable press, such as this, I

From Shelly? I wouldn't listen to her.

suspect its popularity will continue to climb. Especially when the
favorable coverage is coming from a respected publishing house such as
O'Reilly.

Have to talk to them.

 

[Garrett Smith]

[...]


I know. Some dumbshits would actually measure all the way to the top
of the HTML and then try to work backwards to the positioned body.
Some might even recommend such an approach to newcomers (possibly with
a version of a debunked script that they themselves haven't even
used.) Nothing surprises me anymore.

And, as you know, theirs looks suspiciously like my take, just years
too late. If I am the one who designed the box and I tell you the box
isn't worth getting into, what does that mean to you? Remember what I
said about browser sniffing, attributes vs. properties, etc.? Am I
wrong on this one or shouldn't you be listening?

What I understand you are saying is that the jQuery offsets plugin was
inspired by code you wrote. Did I get that right?

If I understand you correctly: Why do you think so?

Garrett

 

[David Mark]

On Apr 12, 5:19 am, David Mark <[email protected]> wrote:

[...]



I know.  Some dumbshits would actually measure all the way to the top
of the HTML and then try to work backwards to the positioned body.
Some might even recommend such an approach to newcomers (possibly with
a version of a debunked script that they themselves haven't even
used.)  Nothing surprises me anymore.

And, as you know, theirs looks suspiciously like my take, just years
too late.  If I am the one who designed the box and I tell you the box
isn't worth getting into, what does that mean to you?  Remember what I
said about browser sniffing, attributes vs. properties, etc.?  Am I
wrong on this one or shouldn't you be listening?

What I understand you are saying is that the jQuery offsets plugin was
inspired by code you wrote. Did I get that right?

What plugin? I am talking about the offset function in the jQuery
script.

If I understand you correctly: Why do you think so?

It is obvious.

 

[Garrett Smith]

From Shelly? I wouldn't listen to her.

Her book is full of the most outlandish factual falsehoods.

Aside from that, I can't even agree with general opinion, either.

| In an ideal world, everyone who visits your website would use the same
| type of operating system and browser and would have JavaScript
| enabled. Your site would never be acessed via a mobile phone...

Can't agree at all! I'm a NoScript user. I like using different browsers
and OS's.

Garrett

 

[Garrett Smith]

What plugin? I am talking about the offset function in the jQuery
script.


It is obvious.

Apparently, according to you, it is not obvious that we are talking
about the same thing.

In fact, we are talking about the same thing. jquery offset was a plugin
before it became part of core. Calling jQuery.fn.offset a "plugin" was
not the best way to communicate what I was talking about.

SO. Now that we're clear on that, please clarify if it is in fact your
claim that the jQuery offset plugin was inspired by your code and if it
is your claim, then please explain.

Garrett

 

[Lawrence Krubner]

Has grown.  Is at the apex of its absurdity.  In short, jQuery claims
to be "Write Less. Do More."  I say, even if it was, it pales in
comparison with "Write Once. Do Nothing."  jQuery is introducing
"overhauls" in the year 2009 on issues that were settled in 2001,
still doesn't have them right (as evidenced by the disruption in
upgrading the script and/or its dependencies) and the authors do not
appear to understand most of the issues anyway.


Your graphic designer friends shouldn't play with browser scripting.


Admirable ambition.  Of course, they likely shouldn't play with Flash
either (usually involves Other People's Scripts.)


Prototype died out.  jQuery is next.  That's what happens to bad
ideas.

There is a strange kind of unreality haunting this newsgroup. The
attitude seems to be "I don't want people to use these libraries, so I
will close my eyes and cover my ears and say nyah nyah nyah nyah until
people stop using them."

When I say I'm getting more requests for help from designers who are
using jQuery, I'm simply reporting what has actually happened.

 

[David Mark]

Her book is full of the most outlandish factual falsehoods.

Aside from that, I can't even agree with general opinion, either.

| In an ideal world, everyone who visits your website would use the same
|  type of operating system and browser and would have JavaScript
| enabled. Your site would never be acessed via a mobile phone...

Can't agree at all! I'm a NoScript user. I like using different browsers
and OS's.

Yes, how is that the "ideal" world? I'm sure Shelly goes on to
explain how the "real" world is very scary, jQuery is your friend,
etc.

Amazing how so many books became instantly obsolete on this latest
rewrite. All of those plugins that are breaking were obviously based
on examples from books like this. Now that everything has changed
(again), I guess you have to buy the revised editions.

As for the browsers, I don't know what phone Shelly is using, but most
have decent browsers now. Of course, most don't work very well (if at
all) with jQuery.

And why should I care if an end-user disables scripting? Though I
suppose for jQuery users, disabled scripting is a leg up.

 

[Lawrence Krubner]

Has grown.  Is at the apex of its absurdity.  In short, jQuery claims
to be "Write Less. Do More."  I say, even if it was, it pales in
comparison with "Write Once. Do Nothing."  jQuery is introducing
"overhauls" in the year 2009 on issues that were settled in 2001,
still doesn't have them right (as evidenced by the disruption in
upgrading the script and/or its dependencies) and the authors do not
appear to understand most of the issues anyway.


Your graphic designer friends shouldn't play with browser scripting.


Admirable ambition.  Of course, they likely shouldn't play with Flash
either (usually involves Other People's Scripts.)


Prototype died out.  jQuery is next.  That's what happens to bad
ideas.




Who?

Her books are listed here:

http://www.amazon.com/exec/obidos/s...pe=ss&index=books&field-author=Shelley Powers

 

[Lawrence Krubner]

Has grown.  Is at the apex of its absurdity.  In short, jQuery claims
to be "Write Less. Do More."  I say, even if it was, it pales in
comparison with "Write Once. Do Nothing."  jQuery is introducing
"overhauls" in the year 2009 on issues that were settled in 2001,
still doesn't have them right (as evidenced by the disruption in
upgrading the script and/or its dependencies) and the authors do not
appear to understand most of the issues anyway.


Your graphic designer friends shouldn't play with browser scripting.

No doubt no one should write a line of code, even in a light weight
scripting language, until they have completed their Ph.d in computer
science at Stanford, yet in the real world, people often do write code
before their Ph.d is complete.

 

[David Mark]

David Mark wrote:
[...]
I know.  Some dumbshits would actually measure all the way to the top
of the HTML and then try to work backwards to the positioned body.
Some might even recommend such an approach to newcomers (possibly with
a version of a debunked script that they themselves haven't even
used.)  Nothing surprises me anymore.
And, as you know, theirs looks suspiciously like my take, just years
too late.  If I am the one who designed the box and I tell you the box
isn't worth getting into, what does that mean to you?  Remember what I
said about browser sniffing, attributes vs. properties, etc.?  Am I
wrong on this one or shouldn't you be listening?
What I understand you are saying is that the jQuery offsets plugin was
inspired by code you wrote. Did I get that right?

What plugin?  I am talking about the offset function in the jQuery
script.

It is obvious.

Apparently, according to you, it is not obvious that we are talking
about the same thing.

I only know of one thing and that is what I was talking about. I
assumed you were talking about something else.

In fact, we are talking about the same thing. jquery offset was a plugin
before it became part of core. Calling jQuery.fn.offset a "plugin" was
not the best way to communicate what I was talking about.
Okay.


SO. Now that we're clear on that, please clarify if it is in fact your
claim that the jQuery offset plugin was inspired by your code and if it
is your claim, then please explain.

We've been over this ad nauseum. The original offset code was all
browser sniffing. God only knows what "inspired" that mish-mash. I
don't care to go over this endlessly, but this is yet another function
critiqued in the Fall of 2007. A couple of months after that, we (you
included) had a long talk about these absolute positioning functions,
including discussions of the one in my library. I've since seen
similar code pop up in other absolute positioning functions, including
jQuery's latest stab. I've seen Resig refer to the feature testing
technique as "detect and inject." Of course, he had it backwards.

Sample from jQuery offset circa October 2007:

// Mozilla and Safari > 2 does not include the border on offset
parents
// However Mozilla adds the border for table or table cells
if ( mozilla && !/^t(able|d|h)$/i.test(offsetParent.tagName) || safari
&& !safari2 )
border( offsetParent );

if ( jQuery.offset.doesNotAddBorder && !
(jQuery.offset.doesAddBorderForTableAndCells && /^t(able|d|h)$/i.test
(elem.tagName)) )
top += parseInt( computedStyle.borderTopWidth, 10) || 0,
left += parseInt( computedStyle.borderLeftWidth, 10) || 0;

Those long-winded offset.* properties are figured by styling and
injecting created DIV's and then measuring their computed styles
against expected outcomes. My last (and most absurdly unneeded)
version of this function, which had evolved since before the turn of
the century, did the same thing in the same way with similarly named
variables. Why they are exposing these properties to outside
intervention is anyone's guess though.

So mine was published in February of last year. It was discussed here
and certainly compared to jQuery at some point. In fact, this is one
of the functions that Matt Kruse kept demanding that I publish to
"prove" that I could write better code than Resig (as if that
mattered.) Resig himself asked where my version of this was when I
first panned his script. You think he suddenly lost interest two
months later? Another demand was the also unneeded getAttribute
wrapper, which was apparently less than inspirational.

The jQuery people are known to read this group and are certainly not
unfamiliar with my criticism. I suppose it is possible that some
third party was inspired, making this an indirect homage.

SO, there you go.

[snip]

 

[David Mark]

No doubt no one should write a line of code, even in a light weight
scripting language, until they have completed their Ph.d in computer
science at Stanford, yet in the real world, people often do write code
before their Ph.d is complete.

There's that "real world" again. In this world, do all programmers
have advanced degrees from Stanford? Regardless, it is a fact that
most people who play with Javascript are ill-advised to do so.
Furthermore, most Websites are degraded, rather than enhanced by
browser scripting. In extreme cases, perfectly good documents are
rendered unusable. Why should a graphic designer want to do something
like that?

 

[Lawrence Krubner]

There's that "real world" again.  In this world, do all programmers
have advanced degrees from Stanford?  Regardless, it is a fact that
most people who play with Javascript are ill-advised to do so.
Furthermore, most Websites are degraded, rather than enhanced by
browser scripting.  In extreme cases, perfectly good documents are
rendered unusable.  Why should a graphic designer want to do something
like that?

Good designers build usable sites that degrade gracefully. Bad
designers build sites that are unusable for a significant portion of
the people who visit their sites. Good designers, such as Darren Hoyt
(darrenhoyt.com) insist on valid markup, clean CSS, minimal HTML and
Javascript that enhances a site, but which in no way limits the use of
the site. And Darren Hoyt uses jQuery in the themes that he builds.
And the designers who imitate him probably do as well.