Absolute element offsets--exercise in futility

[Lawrence Krubner]

On the other hand...

Inexperienced developers will try stuff that a more experienced
developer would know better to try.

People who are inexperienced often try things that experienced people
know to avoid. This is true about rock climbing. It is true about
investing. It is true about romance. It is true about travel. It is
true about all things that humans can experience. You have no point to
make.

 

[Lawrence Krubner]

Who do you suppose will go back and swap out the entire jQuery library
when the next new browser comes out (or you discover that it doesn't
work that well with the latest releases.)  Think a neophyte can debug
and test this spaghetti factory on top of whatever gibberish they
wrote?  Nobody would bother.  They sites just get thrown out like
disposable diapers.  That is not how the Web works and certainly not
how business works.

And yet, businesses use jQuery. Apparently this is the way business
works.

I've seen it.  It seems to be finally dying out.

BTDT.  As with any large group, some listen, some don't.  Make no
mistake, .NET is history.

There is a delusional quality to much of your writing. That your
exaggerations and bold pronunciations have nothing to do with reality
doesn't seem to bother you at all.

 

[Lawrence Krubner]

Must be, 'cause I still can't see much light in your argument. I have no
interst in any JS library. Thus, I'm not driven by affections, either way..

 > You could have just as


I fail to see how this question would change anything. Isn't it a
classic example of ad populum?


Or: why do flies like shit? Why don't they fancy veggies?

Flies like shit because shit is full of the nutrients they need. Shit
helps flies accomplish their main evolutionary goal of gaining enough
resources to reproduce. Shit is useful to flies.

What you do with this comparison, thoughtlessly and carelessly, is
take the cultural value that humans assign to shit and then mistakenly
assign it to flies. But why would flies care what humans think about
shit? Why would a fly worry whether humans give great value, or little
value, to shit?

The comparison demonstrates a kind of intellectual laziness that has
been rife in this thread.

 

[Andrew Poulos]

In general, designers have a better grasp of what customers, and what

If you don't test with real users using someone trained in usability you
are, at best, guessing.

the actual users of the websites, want. Computer programmers spend all
day thinking about how machines think, but designers spend all day
thinking about humans think. Web sites developed with a design lead
process tend to be more intuitive and usable than the sites where

Without proper usability testing you would never really know if a site
is usable.

programmers have control over the process. Web sites developed in
shops where the programmers dominate tend to deliver the requested
features, but in ways that damage the user experience.

You talk of "user experience" as though there's some absolute one can
ascribe to.

Andrew Poulos

 

[Lawrence Krubner]

It seems that in (1), code reuse implies using a library. I have to
disagree with that. Strongly.

For a search of "code reuse", you might stumble on the first hit:-

http://en.wikipedia.org/wiki/Code_reuse

Did you read the wiki page that you are linking to? The beginning of
the third paragraph says:

"The software library is a good example of code reuse. "

 

[Garrett Smith]

Ah, yes. Because of your courageous willingness to stand against the
conventional wisdom, the world is coming around to your way of seeing
things. The millions of people who carefully read comp.lang.javascript
everyday have been dazzled by the brilliance of your arguments. That
respected publishing houses like O'Reilly have published books saying
positive things about jQuery is of no matter.

Are you referring to the Shelly Powers book again?


They have learned the

errors of their ways. Surely any day now you'll be receiving a
personal letter of apology from O'Reilly himself, asking forgiveness
for the damage he may have caused by publishing books that expressed
opinions you disagree with.

In argument, it is important to distinguish between fact and opinion.

That popular magazines and popular

designers are recommending libraries like jQuery is a point we can,
and should, ignore. All that matters is how daring you've been, and
how you've won over all of society with the strength of your
arguments.

Sarcasm is mpt always conveyed as sarcasm on the Net. Sarcasm can also
be an indirect way of posing an argument. I think I am making the
correct interpretation of what you wrote as being entirely sarcastic.

This is comp.lang.javascript. Popularity means jack shit here. If you
want popular, go visit Ajaxian.

Garrett

 

[Garrett Smith]

Did you read the wiki page that you are linking to? The beginning of
the third paragraph says:

"The software library is a good example of code reuse. "

I read it. I did not assume that someone would make the mistake of
affirming the consequent.

You stated:

| Reuse old code, that is, use a library.

To conclude that using a library means that effective code reuse has
taken place would be incorrect.

1) Using a library might be a form of code reuse, but that would not
necessarily make the reuse effective.

2) Reused code might be new and might not come from a library. This can
happen when creating abstractions for the parts that vary.

Garrett

 

[Thomas 'PointedEars' Lahn]

That's a false over-generalization. If you are trying to be super
accessible and all that, sure, don't hide things by default. But
internal webapps rarely have those types of concerns.

That few businesses and organizations realize that they need accessible
applications on the inside, too, is no argument at all against creating such
applications. For example, since quite a few years in Germany (2002 CE),
Austria (2004), and Switzerland (2004) external and internal Web sites of
state-related organizations must be designed accessible *by law* (they must
meet WCAG 1.0 A+), and at least German and Swiss law also reinforces that
disabled people have to be employed (also in private companies) if they are
qualified for the job.

<http://de.wikipedia.org/wiki/Barrierefreies_Internet>

The U.S. Americans with Disabilities Act (ADA) is dated 1998 as well as
Section 508 of the Rehabilitation Act. Other countries have similar
legislation; if not, they are going to because of globalization.

<http://en.wikipedia.org/wiki/Web_accessibility>

Go tell them that they need to redesign/exchange/update the system because
now both the senior not-disabled field staff and the newly employed
disabled/aged office assistant need to access it, and let them have a good
laugh.

Again, it is your shortsightedness that lets you overlook the
all-too-obvious possibilities.


PointedEars

 

[Thomas 'PointedEars' Lahn]

People who are inexperienced often try things that experienced people
know to avoid. This is true about rock climbing. It is true about
investing. It is true about romance. It is true about travel. It is
true about all things that humans can experience. You have no point to
make.

The point is, Lawrence (if that's your real name), that these things tend to
have much a smaller impact on the lives of everyone. If you alone go climb
a rock inexperienced and fall down or are stuck above, only you are injured
or dead. If you invest in the wrong stocks, only you are going to lose
money (save that you are a hedge funds manager, but who's the greater
fool?). If you go wrong about romance, only you and perhaps the other
person might find yourselves alone. If you book the wrong trip, only you
might find yourself dissatisfied (or captured or killed). (Of course, in
any of those cases, your family, relatives and friends might suffer with you.)

If instead you create a script library that hundreds are supposed to use, if
you don't have the minimum clue, and if your library is advertised so that
those hundreds who are building on it also think they don't need to have a
minimum clue (i.e. if you are John Resig), and thousands of equally clueless
people use that which is built on it on a hundred thousands of Web sites, in
the end millions are going to suffer from your initial and ongoing mistakes.
For the mistakes made from conception to design to implementation to
production do multiply, and it stands to reason (as if it was not evident
already) that they are not easily fixed by then, especially if none of the
involved people had the minimum clue in the first place.


HTH

PointedEars

 

[Gregor Kofler]

Am Tue, 14 Apr 2009 23:07:55 -0700 schrieb Lawrence Krubner:

and some only need very low
levels of quality.

Never met anyone who *needs* (or wants) that. They probably don't want to
pay for it.

Gregor

 

[Gregor Kofler]

Am Tue, 14 Apr 2009 23:13:53 -0700 schrieb Lawrence Krubner:

I'd never argue that Mark should stop criticizing anyone. I'm arguing
that, if his scripts are freely available, and no one uses them, then
perhaps they are not as useful as he thinks they are.

You never heard of this "marketing" thing? Right?

Your use of the word "quality" suggests that there is a single dimension
by which we can measure code.

Not a "single dimension", but several best practices, inherent to the
different programming languages and environments.

However, there are many other, equally valid, dimensions by which code
can be measured. For instance:

1.) How useful do people find this code?

2.) How easy to use do people find this code?

You never heard of this "marketing" thing? Right?

If people find code un-useful, or if they find it hard to work with,
then I'd argue it is worth very little, regardless of its conformance to
some well known standards of software design.

Makes one wonder why BASIC has completely disappeared...

How many "developers" have evaluated the various libraries available? And
how many have just jumped the jQuery bandwagon without second thought?
99%? 99.5%?

Gregor

 

[Garrett Smith]

Her books are listed here:

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

I already stated that the Shelly Powers book is full of factually false
statements.

An earlier post you made discussed "opinions" in books published by
O'Reilly. As I said in response to that, it is important to distinguish
between facts and opinions.

Facts are things like:-

| In addition to the ECMAScript reserved words, there are
| JavaScript-specific words implemented in most browsers that are
| considered reserved by implementation. Many are based in the
| Browser Object Model--objects such as document and window. Though
| not a definitive list, Table 2-3 includes the more common words.
|
| Table 2-3. Typical reserved words in browsers
| alert eval location open
| array focus math
....

a factual statement regarding reserved words of the "Browser Object Model".

Another fact:-

| Many times, variables and functions have one or more words
| concatenated into a unique identifier, following a format
| popularized in other languages, and frequently referred to as
| /CamelCase/:
|
| validateName
| firstName
|
| This approach makes the varible much more readable, though
| dashes or underscores between the variable "words" works as
| well:
|
| validate-name
| first_name

another factual statement, this time regarding syntax, not reserved words.

That statement is followed by:-

| Though you can use $, number, or underscore to begin a variable, your
| best bet is to start with a letter.

That is two pages of Shelly Powers. Practically every page is loaded
with stuff like that.

| Null and Undefined.
| The division between literals, simple data types, and objects
| is blurred in JavaScript, nowhere more so then when looking at two
| that represent nonexistannce or incomplete existance: null and
| undefined.
|
| A /null/ variable is one that has been defined but hasn't been
| assigned a value. The following is an example of a null variable:
|
| alert(sValue); //results in JavaScript error because sValue is
| // (wrapped) not declared first.


On the proceeding page, she provides advice for how to handle this
problem when using several JS libraries:-

| When using several JS libraries and fairly complex code, it's not
| unusual for a variable to not get set, and trying to use it in an
| expression can have adverse effects -- usually a JavaScript error. One
| approach to test variables if you're unsure of their state is to use
| the variable in a conditional test, such as the following:
|
| if(sValue) ... // if not null and initialized, expression is true;
| // (wrapped) otherwise false.
|
| We'll look at conditional statements in the next chapter, but the
| expression consisting of just the variable sValue evaluates to |true|
| if sValue has been declared and initialized; otherwise, the result of
| the expression is false.
|
| if (sValue) // not true, as variable has not been declared, and
| // (wrapped) is therefore null
|
| var sValue;
| if (sValue) // variable is not null, but it's still not true, as
| // (wrapped) variable has not been defined (initialized with a value)
|
| var sValue = 1;
|
| if(sValue) // true now, as the variable has been set, which
| automatically declares it.
|

Opinions, OTOH, expresses personal or unproven belief.

For example:-

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

- could be considered your opinion and would serve as an example of
"opinion" in the general sense.

Another meaning of opinion applies to professional expert advice. (My
doctor's opinion, the judge's opinion, etc). I don't see how that would
be relevant here; Shelly Powers is not an authoritative expert.

Garrett

 

[Matt Kruse]

I already stated that the Shelly Powers book is full of factually false
statements.

Wow... the quotes you cite are awesome. This is for real? Seriously?

No wonder people have the perception that javascript is funky and hard
to understand, when the people who get paid to write books about it
can't even get it right.

I can imagine a person new to js, after reading her advice, writing a
simple test script...

var 123-abc = "test";

WTF!? Why doesn't this work? There must be something really obscure
happening here. Man, Javascript is HARD! jQuery to the rescue!!!

Matt Kruse

 

[Garrett Smith]

Wow... the quotes you cite are awesome. This is for real? Seriously?

No wonder people have the perception that javascript is funky and hard
to understand, when the people who get paid to write books about it
can't even get it right.

I can imagine a person new to js, after reading her advice, writing a
simple test script...

var 123-abc = "test";

WTF!? Why doesn't this work? There must be something really obscure
happening here. Man, Javascript is HARD! jQuery to the rescue!!!

LOL. You've got to have a sense of humor!

The funny thing is she contradicts herself in a few places on what a
valid identifier is.

That is not the only O'Reilly javascript book you'll find advocating the
use of jquery. Take a look at: JavaScript, The Missing Manual, by David
McFarland.

Another book that is chock full of bs from cover to cover.

This is what it has come to.

Matt Kruse

Garrett

 

[Lawrence Krubner]

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/5107d8...

"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!

I think this blog post by Drew McLellan offers a good point about why
libraries like jQuery are useful:

"Despite some efforts to make my script play nice and integrate with
other JavaScript that may be in use on the page, a lot of users still
found the script problematic. Whilst I was checking for existing
onload event handlers in the page before adding mine, other scripts
don’t necessarily do that and so could overwrite my event handler
causing the script not to work. Not my fault, but still not good for
those with the problem.

With the rise of JavaScript libraries over the last couple of years,
the ecosystem has got a lot more friendly. Rather than having a page
running a mishmash of different scripts running in different
methodologies, the adoption of a library brings with it shared
methodology and infrastructure. That means you can do things like set
an onload handler and not worry that your code will not get executed –
the library is managing that across all the JavaScript that may be on
the page. This also means that there’s a lot less code that needs to
be written per-script, as you can tap into what the library already
has on offer. So it made sense to me to re-implement SuperSleight
using a common JavaScript library."

http://allinthehead.com/retro/338/supersleight-jquery-plugin

 

[RobG]

I think this blog post by Drew McLellan offers a good point about why
libraries like jQuery are useful:

"Despite some efforts to make my script play nice and integrate with
other JavaScript that may be in use on the page, a lot of users still
found the script problematic. Whilst I was checking for existing
onload event handlers in the page before adding mine, other scripts
don’t necessarily do that and so could overwrite my event handler
causing the script not to work. Not my fault, but still not good for
those with the problem.

Apparently Drew's choice of jQuery was motivated by difficulty adding
an event listener that was not affected by other scripts. Given the
small number of modern browsers supported by jQuery, it surely would
not have been too much work to add a listener using a bog standard
addEventListener/attachEvent function.

With the rise of JavaScript libraries over the last couple of years,
the ecosystem has got a lot more friendly. Rather than having a page
running a mishmash of different scripts running in different
methodologies, the adoption of a library brings with it shared
methodology and infrastructure.

The key here is "the adoption of *a* library". Apparently the use of
a single library or framework is a strategy to enforce a particular
coding style or design strategy. There are a couple of flaws in that:

1. Not everyone may agree on the use of the same library, they often
bump into each other.

2. Using a library doesn't force any particular design paradigm on
developers, though there are similarities of how they are used. If
you add a listener directly to a DOM property, it doesn't matter what
library has been used, someone else can easily replace it. If you add
it using host DOM methods (e.g. addEventListener or attachEvent) the
listener can't be removed without a reference. The fact that a
library was or wan't used (most probably[1]) makes no difference.

3. Even if the users of a particular library all use the same
implementation methodology with the same library, it has nothing to do
with his issue.

A simple, generic answer to Drew's dilema is to include a simple
(perhaps 6 lines of code[2]) function or routine to add his listener.
But instead he's chosen to re-write is code to fit with jQuery, then
impose a restriction that it can only be used in browsers that jQuery
supports. He doesn't even have to write it, there are plenty already
published in this group (though searching for one will likey take
longer than writing it).

The funniest part is that his code is only needed in one browser
version - IE 6 - so his addListener function can be maybe 3 lines of
code and in any case can be done with conditional comments - no onload
listener needed at all. Where's the need for a library now?

That means you can do things like set
an onload handler and not worry that your code will not get executed –
the library is managing that across all the JavaScript that may be on
the page.

Rubbish. If an element is replaced with a clone of itself, whether
handlers are kept depends on the browser and how the listener was
attached. A library doesn't help at all there[1].

If the issue is stopping other code from removing his listener, if he
uses addEventListener or attachEvent then the possibility of that
occurring is reduced to near zero (other listeners might affect event
propigation, but libraries don't help with that[1]).

This also means that there’s a lot less code that needs to
be written per-script, as you can tap into what the library already
has on offer. So it made sense to me to re-implement SuperSleight
using a common JavaScript library."

So rather then using well known standard methodologies for development
to avoid clashes between scripts written by different authors,
McLellan thinks that if you mandate everyone use the same library
somehow side effects wont happen. Wishful thinking.

McLellan has the classic "general case" dilema - the more general the
code is written, the more difficult it is to cover every case. Rather
than either write his code to be useful in a reasonably wide set of
browsers or state the restrictions on its use, he simply uses jQuery
to provide a filter of unsuitable browsers. Don't blame him if your
browser isn't supported, blame the jQuery development team!


1. Some libraries may have their own cache of the listeners that have
been added using the library's functions and may allow those listeners
to be carried over to replaced nodes. Some attempt their own version
of propigation.

2. Given the limited set of modern browsers supported by libraries
like jQuery

 

[Garrett Smith]

I think this blog post by Drew McLellan offers a good point about why
libraries like jQuery are useful:

"Despite some efforts to make my script play nice and integrate with
other JavaScript that may be in use on the page, a lot of users still
found the script problematic. Whilst I was checking for existing
onload event handlers in the page before adding mine, other scripts
don’t necessarily do that and so could overwrite my event handler
causing the script not to work. Not my fault, but still not good for
those with the problem.

Not knowing how to handle event registration? Oh, jQUery, that has to be
the answer.

With the rise of JavaScript libraries over the last couple of years,
the ecosystem has got a lot more friendly. Rather than having a page
running a mishmash of different scripts running in different

Mishmash of different scripts running in different methodologies?

I'm not 100% sure what "running in different methodologies" means.

Of what is described, I'm getting the picture like a mess of incompetence.

methodologies, the adoption of a library brings with it shared
methodology and infrastructure. That means you can do things like set
an onload handler and not worry that your code will not get executed –

Funny. I don't have that problem.

the library is managing that across all the JavaScript that may be on
the page. This also means that there’s a lot less code that needs to
be written per-script, as you can tap into what the library already
has on offer. So it made sense to me to re-implement SuperSleight
using a common JavaScript library."

http://allinthehead.com/retro/338/supersleight-jquery-plugin

| Of course, if you wanted to fix PNGs for the entire page, you can just
| apply it to the body element. For all sorts of reasons, it’s better to
| be specific if you can.

Using a |for in| loop would onload be a bad idea (locks up browser
momentarily). Putting it inside a jQuery.each is a much worse idea. I
don't have time for much of a code review of that.

Reading more Drew McClellan:-
http://allinthehead.com/retro/337/the-cost-of-accessibility

| As a web developer, there’s little I dislike more than building sites
| to be accessible.

Yikes! He goes on to say how accessibility is a pain in the "backside".

THen he goes on to discuss "The Magical World of JavaScript"

| The Magical World of JavaScript
|
| A big challenge we face as web developers is dealing with unknown
| variables.

(LOL, just got a Shelly Powers/Alpha Bits deja vu there).

To which the answer is:
| Enter Cappuccino and Atlas
| This is the space that the Cappuccino framework operates in. The team
| behind Cappuccino, 280 North bill it as a framework for building
| “desktop-caliber applications that run in a web browser”. They
| certainly seem to deliver on that promise, too. Just take a look at
| their demonstration 280 Slides product – an amazingly desktop-like
| tool in the style of Apple Keynote. This stuff is mind-blowingly cool.

"mind-blowingly cool".

That is about as interesting or useful as anything else Lawrence Krubner
has posted.

Garrett

 

[Andrew Poulos]

Reading more Drew McClellan:-
http://allinthehead.com/retro/337/the-cost-of-accessibility

| As a web developer, there’s little I dislike more than building sites
| to be accessible.

Yikes! He goes on to say how accessibility is a pain in the "backside".

I took him to mean; although accessibility is important, building an
accessible web site can be difficult.

Andrew Poulos

 

[Thomas 'PointedEars' Lahn]

I took him to mean; although accessibility is important, building an
accessible web site can be difficult.

Not more difficult as writing proper HTML in the first place.


PointedEars

 

[Jeremy J Starcher]

Not more difficult as writing proper HTML in the first place.

Valid HTML 4.01 strict is a good start and making an accessible page[1],
but it isn't the end. Full accessibility includes providing alternative
content for images, audio and video as well as careful, for example.

< http://www.jan.wvu.edu/media/webpages.html > makes a nice summary of
several different things to keep in mind.

[1] Accessible in this context meaning more than just "can" be used. It
means "designed for" alternative (non-visual) user agents.