Why won't my (j)query work?

[David Mark]

For the typical neophyte, CSS selectors are magic.  Put in a selector,
get out a collection of matching elements.  What could be easier?
Turns out, almost anything would be easier.

For the typical library author, attribute handling is also magic, so
they never got close to creating a reliable query solution.  They all
fail in similar ways, varying slightly with the specific
misconceptions of their respective author(s).  Not unexpectedly, years
of slap-dash debugging by hapless users and contributors has failed to
fix the problems (none has a clue what is going on under the hood).
If they can't fix attr, they sure as hell can't fix the queries.

Now they want to deprecate (on paper) every browser that fails to meet
their warped expectations.  It's ironic that such a move makes them
virtually superfluous (take away "Sizzle" and all that is left of
jQuery is an ill-advised, "overloaded" clunker of an OO DOM
interface).

These issues come up over and over in the various mailing lists for
the "major" libraries. They are usually answered with guesswork (e.g.
try this instead) or ignored.

http://groups.google.com/group/jquery-dev/browse_thread/thread/31f159...

http://groups.google.com/group/jquery-en/browse_thread/thread/23d0f3c...

Here's another one. Just look at this nonsense:-

http://groups.google.com/group/jquery-en/browse_thread/thread/670f2d6996e05606

Gee, try it this way--that works in "all browsers". The other way
must expose a bug in Opera. Somehow I doubt it.

This is not programming; it's memorization of patterns. You could
train chimps to do this. Of course...

 

[David Mark]

David has latched on to one very specific issue that he has researched
and apparently understands well, whereas many other javascript authors
do not. He repeatedly argues this same point ad nauseum, twisting it
slightly to make new arguments and making long, repetitive posts here
which could best be summed up in one sentence - "Correctly handling
attributes requires considering some special cases and browser quirks,
which most libraries and js authors do not do correctly."

An addendum. Most library designs wouldn't work even if all browsers
followed the standards (e.g. YUI returning '' for missing
attributes). It's not the "buggy" browsers they are fighting; it's
their own ignorance and over-confident, overly ambitious designs.
Amazing you can't (or won't) see that crucial distinction.

And these days all of the major browsers are on the same footing (with
a few minor exceptions) with regard to low-level DOM operations (e.g.
reading and writing attributes). The browser developers have made
great progress in the last few years, removing the "need" for
monolithic leveling scripts. So how on earth are the "major"
libraries, which aspire only to support the very latest major
browsers, so screwed up at the end of the decade? That's the question
and there's only one answer: incompetence. Why are people still using
them: momentum (which is predictably waning).

So much for "big ideas".

 

[jdalton]

http://javascript.nwbox.com/IEContentLoaded/
....

For one, there's not a shred of documentation anywhere that indicates
this method will throw an exception if the DOM is not ready. For two,
this _will_ throw an exception if the method is unavailable.

Do you mean documentation like the one linked to in the nwbox page
above
http://msdn.microsoft.com/en-us/library/ms531426(VS.85).aspx#Component_Initialization

Or this which suggest errors are thrown on properties/methods that
require the document to be completely parsed
http://msdn.microsoft.com/en-us/library/ms531426(VS.85).aspx#ctl00_MTCS_main_ctl53

Or this implementation which states it may return an error
http://msdn.microsoft.com/en-us/library/aa703983(VS.85).aspx

Or that in reality it's been proven that it throws errors ?

} catch (e) {
setTimeout(arguments.callee, 50);

So, this will never call back in DOM's without a doScroll method.
Hard to imagine a worse result.

This snippet was intended for use on IE only.
Implementers mostly likely use browser sniffs, feature inference, or
feature detection
to determine if the "doScroll" code should be executed.

....

This part is useless in IE (readyState indicates completion at the
same time the load event fires).

d.onreadystatechange = function() {
if (d.readyState == 'complete') {
d.onreadystatechange = null;
init();
}
};

Actually there are instances where onreadystatechange will fire with
readyState "complete" before the load event fires.
I believe it fires early on cached loads but I don't have the
specifics at hand.

This junk has already been copied into jQuery and YUI (and I imagine
others will follow suit).

The script has its limitations, for example doScroll() won't throw
errors on secondary documents such as pages loaded in iframes.
However there are workarounds for that.

- JDD

 

[David Mark]

David Mark wrote:
David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
[...]>> I buy into that pattern.  Works great.

[...]

Typo (missing ev).

       var target = APE.dom.Event.getTarget(ev);

I can't see using a library for this.  And what's with the long-winded
"namespace?"  I don't care for that either.

An abstraction is appropriate here.

I'm fine with abstractions, provided they are well thought out.

Regarding the namespace:-

APE - the library namespace.

dom - the dom module. This module may be used with only dependency of
APE.js. APE.js, fully commented and uncompressed, is about two
screenfulls of code (something like 6k, uncompressed, with comments).

Can we skip the marketing?

dom.Event - for dealing with dom events. If these methods were placed
directly on dom, they would need renaming. Consider:-

   APE.dom.getTarget; // what sort of target?
   APE.dom.Event.getTarget; // gets an event target.

Does APE.dom.getEventTarget look better? I would have to consider other
methods in the dom.Event package (how they woul be renamed, if they
would make sense, etc).

Well, I have found that a "flat" namespace works fine. No collisions
and no self-imposed performance penalties.

Local aliases are often useful things:-

(function(){

   var dom = APE.dom;

Yes, I know. My whole library is based on them. That's why it
"minifies" so well. Also great for performance as my recent TaskSpeed
experiments have shown. My Library is about as close to using "pure
Javascript" as you can get.

   // ...



})();


EventPublisher is designed as a pure AOP event notification system.

That's fine, but you are missing a layer. I would want to be able to
attach events without the extra baggage (and optionally add the AOP
layer if/when needed). The only AOP-like thing I did with My Library
is the debugger.

That
is why "onclick" must be used. EventPublisher provides functionality for
event notification and has nothing to do with the DOM.

Okay, but is there a DOM event layer underneath? ISTM there should
be.

In a way, EventPublisher is like dojo.connect, but without the
complexity buried in the argument typechecking.

The "overloading" stuff? Don't get me started.

EventPublisher also
catches and rethrows errors instead of breaking on the first error, as
many libraries do (or did).

I don't find that particularly useful. One error is all it takes to
throw everything out of whack (so why hide it).

So where with dojo, you would have:-
   dojo.connect(exampleObj, "onfoo", exampleObj, "bar");

- in APE, that is:-
   APE.EventPublisher.addCallback(exampleObj, "onfoo", exampleObj.bar);

It's too much for basic DOM scripting. I say start with a basic API
that abstracts away the basic DOM differences and then build on top of
that. Perhaps that's what you've done. I haven't looked at APE in
ages.

It is odd to design a public interface with the callback as a property,
as exampleObj.bar. Instead, the callback can be hidden, and the result
of adding it would look like:-

   APE.EventPublisher.addCallback(exampleObj, "onfoo", bar);

As with dojo.connect, any object that has a method can use
EventPublisher. For example, an Animation has an onend.

var a = new Animation(1);
a.run = runA;
a.onend = aEndHandler;
function runA(){
   console.log(this.rationalValue); // 0-1.

}

I can't see tangling everything up like this. Inter-dependencies are
best avoided. Modularity and interchangeability are key.

function aEndHandler(){
   alert("all done!");

}

There's nothing wrong with syntactic sugar, but for browser scripting,
you want code to be as simple and lightweight as possible. Can you
peel away these higher-level abstractions?

And so you can take that, now, and use EventPublisher there instead:-

APE.EventPublisher.add(a, "onend", runA);

Any Animation's `onend` can be listened to by anyone interested in
listening for that.

Yes, I get it. It's what YUI calls "custom events". I didn't like
them then and I don't have much use for them now; but that's not to
say that they can't be useful in some contexts.

It should also be possible to extend EventPublisher, so that the code
could be used as:-

a.add("onplay", runA);

I didn't really want a lesson on APE's EventPublisher. But thanks
anyway.

Thought that is not necessary. Besides being unnecessary, the name of
the instance method, `add`, should be renamed to `addCallback`.

My eyes are glazing over now.

APE.dom.Event is a different matter. That is specifically for DOM event
handling.

Aha! Fair enough then. You'll forgive me if I don't go back and
rewrite my previous comments. If it can be deconstructed, then all is
well.

That method seems intended for DOM event handlers.

Yes. It is. And yes, the name is silly. I considered the whole
exercise of writing a GP library silly. The kids seem to like it
though.

The D method should probably be renamed to something sensible.

That's a global constructor. Instead of one "$", I went with:-

E - element (also F for form and I for image)
Q - query (one or more elements)
D - document
W - window

The goal was to make a mockery of jQuery's ridiculous interface. I
think I succeeded in that regard. I have always advised against using
the stock OO layer. Better to write your own on top of the API. The
stock objects are a good starting point.

Ideally, I woul just use:-

ev.target

- but that won't work in IE, and may have problems in Safari 2.

Well...

var el = ev.target || ev.srcElement;
if (el.nodeType == 3) {
el = el.parentNode;
}

And it's not just Safari 2 that allows for non-element targets (e.g.
text nodes). IIRC, another example is NN6.

It would not be sensible to write every line of code from scratch.

Obviously. I don't know anybody who does (at least not anybody
successful).

An
abstraction is appropriate here.

Yes. But for a simple example?

Instead of repeating:
   ev = ev || window.event;
   target = ev && ev.target || ev.srcElement;

Why test ev? What are you going to do if it isn't there?

- I prefer an abstraction like:-

// using a local `Event` alias.
var target = Event.getTarget(ev);

Yes. I have API.getEventTarget.

That is much more concise, less cluttered. The method does what it says
and nothing more. I don't have to worry about a browser including text
nodes in the result (Safari 2); the abstraction handles that.

Yes.

 

[Garrett Smith]

I haven't latched on to any specific issue.

[...]

It _is_ justification for throwing them out (the authors too).

We disagree...

Basically, a small group of overconfident neophytes
thought they were starting a revolution... three years later, the Web
is completely fucked and nobody seems to know why. Get it?

You definitely have a flair for the dramatic.

On the contrary, the web is fine and there are a few problems.

The web is fine? In what way? The web seems like a mess to me.

I've personally been on projects that have been a disaster, and even
joined the disaster, hopeful that I could save it from the misguidance.

Quite a good many projects fail and I have been part of that, too.

Many more hobble along, using legacy code, not refactoring, not
improving internal quality.

It is frustrating to see something fail, especially with foresight of
knowing how to avoid that. I do not feel any pride in being a part of
something that came out badly.

A job is taken to procure money. How much professional ethic should be
sacrificed in that process? Where do you draw the line? Is the level of
tolerance for stupidity high, or is the awareness of the stupidity low?

This is

the nature of any evolutionary, iterative process. Very few things
have the luxury of being designed from scratch by experts. Most things
evolve, and are built by those with the time and the big ideas but not
always the expertise, usually on top of what they already know and
built in a way that is familiar to them.

Is not the hardware you are probably using right now built on top of
short-sighted ideas, flawed designs, hacks, etc? No one in their right
mind would design PC hardware from scratch in the form it is now. It's
highly flawed and ends up costing countless dollars in support and
maintenance. Throw a highly flawed, evolved OS on top of the highly
flawed hardware and you have an insane mountain of patches on top of
patches on top of fundamentally short-sighted ideas. Yet somehow it
seems to work, and makes the internet what it is. Amazing, isn't it?
How something useful can come out of such imperfection?

The end result having some positive attribute does not justify the mistakes.

Mistakes are mistakes. We all make them. They can be embarrassing,
costly, and sometimes painful.

A mistake can be addressed by having a positive attitude in recognizing
the mistake for what it is; not candy-coating; not ignoring; but
recognizing it for what it is, how it happened, and how it could have
been avoided.

There are countless examples of projects and products that have
serious flaws and suffer from poor/short-sighted initial design, yet
still function well enough to be useful and beneficial.

With the industry standard (or lack thereof) for quality RIA code, the
mistakes and shortsightedness are so fundamental, so basic, so obvious
to me. Justifying the outcome with the fact that the industry standard
is used; that it meets status quo, changes nothing.

The industry standard is amiss. Well that's not true. There really isn't
any standard.

A majority of the web 2.0 sites suffer from problems in usability,
degradation, accessibility, forwards compatibility? Why do they serve
invalid markup (often with wrong mime-type)? Why is it that so many
projects take too long to complete. Sure, they slop out an initial
prototype in good time, but then when it comes time to fix and change
things, they have so many problems? This is the industry standard.

To the project manager, js libraries resemble something "official"
looking. This is further evidenced byt the fact that these libraries are
called "standard js libraries" and that the definition for that usually
includes jQuery, mootools, YUI, prototype, dojo.

Aside from being something that resembles an industry standard, JS
libraries provide an interface that is appealing to clients of the API.
Not to me, obviously, I wouldn't have labored so hard to write my own if
the others weren't all so atrociously bad. I you'll know that I am
qualified to say this when you notice that in David's code dumps, I
catch more bugs than he does, and that is *after* he went trhough it once).

How do you define internal quality for RIA's? Quality isn't defined by
mistakes, that's for sure. Quality is defined by a lack of mistakes on
all levels (code, process, time efficiency, extensibility, testability,
etc). Identifying the mistakes, or what *not* to do, is a good step in
the right direction.

 

[David Mark]

Aside from being something that resembles an industry standard, JS
libraries provide an interface that is appealing to clients of the API.
Not to me, obviously, I wouldn't have labored so hard to write my own if
the others weren't all so atrociously bad. I you'll know that I am
qualified to say this when you notice that in David's code dumps, I
catch more bugs than he does, and that is *after* he went trhough it once).

I agree with all of the above, but I want to point out that I don't
endeavor to document every atrocity I paste (some speak for
themselves). I know I can count on others in the group to mop up
(though occasionally you do spot some that I missed or misdiagnosed).
Of course, most of the bugs are so obvious and atrocious that it's
like they are in red and blinking.

 

[Scott Sauyet]

What data were you looking at?

4202     4167    3791    3351    2655    2904    2895    2650    2500
         2251    2280    1790

Do you really need to chart that?

Clearly that means that jQuery is improving, right? Or are you a
different David Mark from the one who wrote the following back in
February?:

| And jQuery's group gets more posts because they are constantly
| going around in circles on the simplest issues (like browser
| detection.) [1]

-- Scott

[1] http://groups.google.com/group/comp.lang.javascript/msg/a32ddeffe37e7245

 

[Garrett Smith]

David Mark wrote:
David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
[...]>> I buy into that pattern. Works great. [...]

Typo (missing ev).
var target = APE.dom.Event.getTarget(ev);
I can't see using a library for this. And what's with the long-winded
"namespace?" I don't care for that either.

An abstraction is appropriate here.

I'm fine with abstractions, provided they are well thought out.

Regarding the namespace:-

APE - the library namespace.

dom - the dom module. This module may be used with only dependency of
APE.js. APE.js, fully commented and uncompressed, is about two
screenfulls of code (something like 6k, uncompressed, with comments).

Can we skip the marketing?

dom.Event - for dealing with dom events. If these methods were placed
directly on dom, they would need renaming. Consider:-

APE.dom.getTarget; // what sort of target?
APE.dom.Event.getTarget; // gets an event target.

Does APE.dom.getEventTarget look better? I would have to consider other
methods in the dom.Event package (how they woul be renamed, if they
would make sense, etc).

Well, I have found that a "flat" namespace works fine. No collisions
and no self-imposed performance penalties.

It might "work", but it doesn't define discreet modules as clearly.

For example, APE's dom is built from several smaller sub modules, one
for reading styles, one for traversal, reading element position, etc.
Each module is focused on one thing and dom module gets lumped together.
There are dependencies on dom file constants.js, but not between other
dom modules.

dom.Event depends on dom in one place, though.

Yes, I know. My whole library is based on them. That's why it
"minifies" so well. Also great for performance as my recent TaskSpeed
experiments have shown. My Library is about as close to using "pure
Javascript" as you can get.

It minifies well and it improves performance, especially in Chrome.

That's fine, but you are missing a layer. I would want to be able to
attach events without the extra baggage (and optionally add the AOP
layer if/when needed). The only AOP-like thing I did with My Library
is the debugger.

What layer is missing?

Okay, but is there a DOM event layer underneath? ISTM there should
be.

No DOM event layer underneath; that would be messy. Other libraries mix
dom and custom and it gets messy. Where do you draw the line with
browser bugs? EventPublisher doesn't do any of that.

The "overloading" stuff? Don't get me started.

Yes, the overloading in dojo.connect makes the method too complicated.

Dojo.connect checks the arguments using dojo.isFunction and
dojo.isString. These methods have several problems and woul not pass
review.

Aside from that, dojo.connect, calls dojo._connect, calls
dojo._listener.add and dojo.hitch. These methods modify other functions
by setting and reading a `_listeners` property to the function, leaking
system side effects.

It is complicated design and it has technical problems.

I don't find that particularly useful. One error is all it takes to
throw everything out of whack (so why hide it).

No error is hidden. Errors are thrown in a setTimeout so that all other
callbacks will fire. One error does not break the registry.

With dojo.connect, one error throws everything out of whack.

It's too much for basic DOM scripting.

EventPublisher doesn't have anything to do with the DOM.

I say start with a basic API

that abstracts away the basic DOM differences and then build on top of
that. Perhaps that's what you've done. I haven't looked at APE in
ages.


I can't see tangling everything up like this. Inter-dependencies are
best avoided. Modularity and interchangeability are key.

What interdependencies do you see there?

There's nothing wrong with syntactic sugar, but for browser scripting,
you want code to be as simple and lightweight as possible. Can you
peel away these higher-level abstractions?

What higher level abstractions do you see?

Yes, I get it. It's what YUI calls "custom events". I didn't like
them then and I don't have much use for them now; but that's not to
say that they can't be useful in some contexts.

An object that publishes a message "I'm done" and manages its internals
reduces coupling.

[...]

Aha! Fair enough then. You'll forgive me if I don't go back and
rewrite my previous comments. If it can be deconstructed, then all is
well.

What do you mean by deconstructed?

Yes. It is. And yes, the name is silly. I considered the whole
exercise of writing a GP library silly. The kids seem to like it
though.

It isn't necessarily a silly endeavor. Abstractions are useful and
defining and organizing them is a real challenge.

That's a global constructor. Instead of one "$", I went with:-

E - element (also F for form and I for image)
Q - query (one or more elements)
D - document
W - window

The goal was to make a mockery of jQuery's ridiculous interface. I
think I succeeded in that regard. I have always advised against using
the stock OO layer. Better to write your own on top of the API. The
stock objects are a good starting point.

My goal is to define a library of good abstractions to build widgets. I
want those abstractions to be well-organized.

Other libraries have goals of attracting user. It often seems is if they
spend a lot more effort on marketing then on the actual code.

My objective is based on organizing and testing abstractions for real
things I have built or that I am building. I did use APE on a project.

I am not building a library for what the user of this library want to
do. If and when the need for that abstraction comes, it will get built.
If it is not used, it doesn't exist. There is no speculation.

Well...

var el = ev.target || ev.srcElement;
if (el.nodeType == 3) {
el = el.parentNode;
}

Don't forgot the preceeding:-

ev = ev||window.event;

And it's not just Safari 2 that allows for non-element targets (e.g.
text nodes). IIRC, another example is NN6.

yes, I remember somewhere around or before Mozilla 1.0, maybe 0.9.7

Obviously. I don't know anybody who does (at least not anybody
successful).


Yes. But for a simple example?

For an example, no, not necessary, and possibly unfamiliar to someone
who does not know what a `getTarget` method might do. For the purpose of
the NG, a good idea to show the code get the event target prior to
showing the abstraction that does that.

I posted my reaction of a contrast to the jQuery code as I would write
it, using an abstraction for getting the event target.

I could have omitted using that abstraction.

Why test ev? What are you going to do if it isn't there?

Nothing.

 

[Garrett Smith]

David Mark wrote:
David Mark wrote:
David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
[...]>> I buy into that pattern. Works great.

[...]
I am not building a library for what the user of this library want to
do. If and when the need for that abstraction comes, it will get built.
If it is not used, it doesn't exist. There is no speculation.

Correction:-
I am not building a library for what the user of this library *might*
want to do...

 

[David Mark]

What data were you looking at?

4202     4167    3791    3351    2655    2904    2895    2650    2500
         2251    2280    1790

Do you really need to chart that?

Clearly that means that jQuery is improving, right?  Or are you a
different David Mark from the one who wrote the following back in
February?:

| And jQuery's group gets more posts because they are constantly
| going around in circles on the simplest issues (like browser
| detection.) [1]

"More" is relative. If there are n active code monkeys using jQuery,
call their posting output n squared. But if there are n active
posters here, the total posts will be considerably less.

Or do you think they don't go around in circles over there? Or
perhaps less posts (relative to _their_ group's history) indicates
more potential posters? Or maybe you just want to sound smart?
Didn't work.

 

[David Mark]

David Mark wrote:
David Mark wrote:
David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
[...]>> I buy into that pattern.  Works great.
[...]
Typo (missing ev).
       var target = APE.dom.Event.getTarget(ev);
I can't see using a library for this.  And what's with the long-winded
"namespace?"  I don't care for that either.
An abstraction is appropriate here.

I'm fine with abstractions, provided they are well thought out.

Can we skip the marketing?

Well, I have found that a "flat" namespace works fine.  No collisions
and no self-imposed performance penalties.  

It might "work", but it doesn't define discreet modules as clearly.

No, it works (not "works"). But I see what you are saying (it can
help you develop the library). Might want to think about how you
could filter that stuff out in the release process.

For example, APE's dom is built from several smaller sub modules, one
for reading styles, one for traversal, reading element position, etc.

Yes, that's how mine works as well.

http://www.cinsoft.net/mylib-builder.asp

Each module is focused on one thing and dom module gets lumped together.
There are dependencies on dom file constants.js, but not between other
dom modules.

Yes. I know the pattern well.

dom.Event depends on dom in one place, though.
Okay.



It minifies well and it improves performance, especially in Chrome.

Yes. Chrome is clearly faster than the rest. The whole (insane) test
page loads and is ready in a split second, whereas others can take
multiple times as long. I've got to get into the habit of using that
browser as FF3.5 is driving me out of my skull (always bogging down).
It's partially the code monkeys' fault of course (piling ten tons of
JS, sync XHR, Flash, a million http connections, etc. on the simplest
of documents--often ruining them in the process).

What layer is missing?

See further down. It's fine. I just didn't care to go back and
rewrite my comments.

No DOM event layer underneath; that would be messy. Other libraries mix
dom and custom and it gets messy.

I was saying not to mix them, but the higher-level should certainly
call upon the lower to attach the listeners. Are you saying you don't
do that?

Where do you draw the line with
browser bugs? EventPublisher doesn't do any of that.

Any of what?

Yes, the overloading in dojo.connect makes the method too complicated.

And - like seemingly all JS written these days - it plows straight
into a language-imposed roadblock for no reason at all.

Dojo.connect checks the arguments using dojo.isFunction and
dojo.isString. These methods have several problems and woul not pass
review.

No kidding. I've already reviewed them (and changed them in my
branch, of course). There's an isArray too and all three are called
from all over the place (but not in my branch). I've tried to tell
them. Some people don't want to hear that they are wrong so many
times and will make any excuse to stick with what they are doing. In
open source, every contributor wants to be a genius. One guy ran off
and wrote his own loader to mimic the one I did for them. Copied all
of the is* crap, including typeof xyz == 'array'. He wanted "proof"
that that wouldn't work in "all browsers" (hard to even phrase
it). Of course, he quietly changed it after making me beat him
over the head repeatedly with it and then bitched like an obsessive
schoolgirl that it was my poor "social skills" that caused all of the
problems. Yeah, I don't need to make friends with incompetent
twits with ego issues. I haven't posted there in months and he is
_still_ over there writing fucking _books_ about me.

Aside from that, dojo.connect, calls dojo._connect, calls
dojo._listener.add and dojo.hitch. These methods modify other functions
by setting and reading a `_listeners` property to the function, leaking
system side effects.

Yeah, tell me something I don't know. I tried to start by explaining
the very simplest and lowest-level issues (e.g. window.eval). Got
nowhere. **** it if they don't want to listen (or just copy what I
did). Everyone wants to invent the next great thing. Nobody wants to
do actual work. One guy said, "I'd rather be relevant than right".
I'm sure that was a "swipe" at my library (LOL).

It is complicated design and it has technical problems.

No kidding. I never asserted it didn't. All you have to do is
compare the branch to the trunk. It's like night and day. For one, I
removed _all_ of the browser sniffing. Unsurprisingly, a side effect
is that it loads and runs much faster (obvious to anyone looking at
it) and is considerably smaller as well. They wanted me to draw
pictures (e.g charts) for them and I didn't have the time or
interest. Other than a couple of people near the top of the
structure, they want nothing to do with it (because they _had_ nothing
to do with it).

No error is hidden. Errors are thrown in a setTimeout so that all other
callbacks will fire.  One error does not break the registry.

With dojo.connect, one error throws everything out of whack.

I consider that a very minor issue (if an error at all). If the
calling app has errors, it has errors.

EventPublisher doesn't have anything to do with the DOM.

Sure it does. I saw you attach a click to the document with it. (?)

I say start with a basic API





What interdependencies do you see there?

See below. It seems that you have it right, though I am a bit
confused at this point.

What higher level abstractions do you see?



An object that publishes a message "I'm done" and manages its internals
reduces coupling.

Can be useful, but most scripts are so simple that it's overkill.

[...]

Aha!  Fair enough then.  You'll forgive me if I don't go back and
rewrite my previous comments.  If it can be deconstructed, then all is
well.

What do you mean by deconstructed?

Is there an event layer with a "custom event" layer on top of it? If
not, there is either tangling or redundancy.

It isn't necessarily a silly endeavor. Abstractions are useful and
defining and organizing them is a real challenge.

You sound like them now. Abstractions !== GP Library.

My goal is to define a library of good abstractions to build widgets. I
want those abstractions to be well-organized.

I think the above is very well-organized. Just so happens it makes a
mockery of jQuery, which is organized for shit.

Other libraries have goals of attracting user. It often seems is if they
spend a lot more effort on marketing then on the actual code.
Clearly.


My objective is based on organizing and testing abstractions for real
things I have built or that I am building. I did use APE on a project.
Okay.


I am not building a library for what the user of this library want to
do. If and when the need for that abstraction comes, it will get built.
If it is not used, it doesn't exist. There is no speculation.

Sounds sensible. I just built one to show that it isn't magic (and
that they can last more than one round of browser releases).

Don't forgot the preceeding:-

ev = ev||window.event;


yes, I remember somewhere around or before Mozilla 1.0, maybe 0.9.7

No idea. Haven't looked at those in ages.

For an example, no, not necessary, and possibly unfamiliar to someone
who does not know what a `getTarget` method might do. For the purpose of
the NG, a good idea to show the code get the event...

read more »

I hate GG.

 

[David Mark]

Well said, thank you. The fact that David is correct doesn't make his
apparent obsession with the topic any less tiresome. More to the point,
said obsession is damaging his credibility in the eyes of some who may
have otherwise been willing to listen to him.

As the saying goes, you catch more flies with honey than with vinegar.

There are a few holes in your theory:-

1. Sugar hasn't worked either (see Matt Kruse)
2. I'm not selling _anything_. My book (other than the "cheat sheets"
in the appendix) is not about _other_ libraries.
3. I don't even sell My Library. I've always given it away to those
clever enough to ask (or contribute).
4. Most importantly, my audience is not code monkeys, but the people
who waste precious time and money on their care and feeding.

 

[Garrett Smith]

David Mark wrote:
David Mark wrote:
David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
[...]>> I buy into that pattern. Works great.
[...]
Typo (missing ev).
var target = APE.dom.Event.getTarget(ev);
I can't see using a library for this. And what's with the long-winded
"namespace?" I don't care for that either.
An abstraction is appropriate here.
I'm fine with abstractions, provided they are well thought out.
Regarding the namespace:-
APE - the library namespace.
dom - the dom module. This module may be used with only dependency of
APE.js. APE.js, fully commented and uncompressed, is about two
screenfulls of code (something like 6k, uncompressed, with comments).
Can we skip the marketing?
dom.Event - for dealing with dom events. If these methods were placed
directly on dom, they would need renaming. Consider:-
APE.dom.getTarget; // what sort of target?
APE.dom.Event.getTarget; // gets an event target.
Does APE.dom.getEventTarget look better? I would have to consider other
methods in the dom.Event package (how they woul be renamed, if they
would make sense, etc).
Well, I have found that a "flat" namespace works fine. No collisions
and no self-imposed performance penalties.

It might "work", but it doesn't define discreet modules as clearly.

No, it works (not "works"). But I see what you are saying (it can
help you develop the library). Might want to think about how you
could filter that stuff out in the release process.

I want to know what is defined where and what depends on what.

What should be filtered? I don't have much idea for wanting to filter
things. Even the rollup ape-ep-dom-min.js is something like 15k. That is
before gzip, of course. After gzip it is smaller.

For something that small, there isn't really much need to try and filter
out unused functions.

[...]

Yes. Chrome is clearly faster than the rest.

CHrome may have some sort of upvar optimization.


....]

I was saying not to mix them, but the higher-level should certainly
call upon the lower to attach the listeners. Are you saying you don't
do that?


Any of what?

Browser bugs/issues. EventPublisher doesn't know about any quirks of
events, bubbling. NOne of that.

And - like seemingly all JS written these days - it plows straight
into a language-imposed roadblock for no reason at all.

The solution to the dojo problem has side effects even after going to so
much effort try try and work, even borrowing code from others, trying to
make sense of it, trying to get it to work, yet still causing system
side effects and still relying on faulty abstractions and complicating
the entire mess with all that wacko typechecking stuff.

No kidding. I've already reviewed them (and changed them in my
branch, of course). There's an isArray too and all three are called
from all over the place (but not in my branch). I've tried to tell
them. Some people don't want to hear that they are wrong so many
times and will make any excuse to stick with what they are doing. In
open source, every contributor wants to be a genius. One guy ran off
and wrote his own loader to mimic the one I did for them. Copied all
of the is* crap, including typeof xyz == 'array'. He wanted "proof"
that that wouldn't work in "all browsers" (hard to even phrase
it). Of course, he quietly changed it after making me beat him
over the head repeatedly with it and then bitched like an obsessive
schoolgirl that it was my poor "social skills" that caused all of the
problems. Yeah, I don't need to make friends with incompetent
twits with ego issues. I haven't posted there in months and he is
_still_ over there writing fucking _books_ about me.


Yeah, tell me something I don't know. I tried to start by explaining
the very simplest and lowest-level issues (e.g. window.eval). Got
nowhere. **** it if they don't want to listen (or just copy what I
did). Everyone wants to invent the next great thing. Nobody wants to
do actual work. One guy said, "I'd rather be relevant than right".
I'm sure that was a "swipe" at my library (LOL).

Supercilious comments such as "lets be pragmatic" or "lets try and just
get it done" turn a blind eye to a problem.

No kidding. I never asserted it didn't. All you have to do is
compare the branch to the trunk. It's like night and day. For one, I
removed _all_ of the browser sniffing. Unsurprisingly, a side effect
is that it loads and runs much faster (obvious to anyone looking at
it) and is considerably smaller as well. They wanted me to draw
pictures (e.g charts) for them and I didn't have the time or
interest. Other than a couple of people near the top of the
structure, they want nothing to do with it (because they _had_ nothing
to do with it).

The code of dojo 1.3 is of very poor quality. It appears to have
borrowed from various sources, yet still manages silliness like the
isFunction below. I've interspersed my comments with (GS):-

| dojo.isFunction = (function(){
| var _isFunction = function(/*anything*/ it){
| // must evaluate separately due to bizarre Opera bug. See #8937
|
| var t = typeof it;
|
|
| // (GS) `it can *never* be false-ish?
| // (GS) `it instanceof Function` is superfluous; if t == "function" is
| // false, then `it instanceof Function` can never be true.
| // Boolean
| return it && (t == "function" || it instanceof Function);
| };
|
| return dojo.isSafari ?
| // only slow this down w/ gratuitious casting in Safari (not WebKit)
| function(/*anything*/ it){
|
| // (GS) Serializing an object to see does not convert to string
| // (GS) "[object NodeList]" does not mean the object is a function.
| if(typeof it == "function" && it == "[object NodeList]"){
| return false;
| }
| return _isFunction(it); // Boolean
| } : _isFunction;
| })();

The isSafari thing checks to see if an object's toString results in
"[object NodeList]". As most of us know, Safari implements callable
objects such as forms and images:-

javascript: alert(typeof document.images)

"function" in Safari, so the dojo isFunction doesn't let Safari's
document.childNOdes pass, but lets pass document.images. It makes one
wonder what they would want this function to actually do.

You'll also get that function returning true for Callable RegExp in some
browsers, false for callable regexp in other versions.
javascript: alert(typeof /a/)

Safari 4, FF2 "function"
(it is is callable)

FF3.5
"object"
(it is callable)

So the dojo.isFunction is not defined, has inconsistent results.

They also have the isString function used:-

| dojo.isString = function(/*anything*/ it){
| // summary:
| // Return true if it is a String
| return !!arguments.length && it != null && (typeof it == "string" ||
| it instanceof String); // Boolean
| }
|

Again, we have the check `it instanceof String` which is superflous.

And the isArray:-

| dojo.isArray = function(/*anything*/ it){
| // summary:
| // Return true if it is an Array
| return it && (it instanceof Array || typeof it == "array");
| // Boolean
}

- which I recently commented on in ES-discuss.

See my reply to Mike Samuel's post:
https://mail.mozilla.org/pipermail/es-discuss/2009-December/010406.html

Mike Samuel actually seems a bit upset that I pointed out that his
argument is based off a very poor standard.

What is really sad is that discussions of this very same `isFunction`
function from dojo over two years ago. Two years and SOS.

What is even more sad is that the isFunction checks are totally
unnecessary.

When you get yourself in that position where you have to try and figure
out if the object's toString looks like "[object Nodelist]" it's time to
wake the **** up and realize that "this is dumb" and "lets not do that".

What's even more absurd is that developers readily accept this dumb
code, for which the shortcomings have been explicitly and specifically
discussed, with failure cases demonstrated. Yet developers accept this
as de facto industry standard.

What is even more absurd, these developers actually try to make Web
Standards proposals based on this shit.

I consider that a very minor issue (if an error at all). If the
calling app has errors, it has errors.

The issue I experienced one day, when my manager asked me to hide a
button on a certain condition. It was the day before build. I told him
that it sounded like a simple change, but that I would not be willingto
do it before the build (how about not wing it into production?)

No good, the boss says. Put that in and hide the button on this page.

i did it and showed it to him and he thanked me. I left to go early that
day. Early means before 7pm and that was really early. Often I left
after 8.

So I was on my way and I had an appointment. I had a massage scheduled.
Well I'm on my way, and I have a few minutes so I stop at the park to
stretch out and the phone rings. My boss calls me back in t owork.

Turns out that change broke the entire page, during one user story. I
got back and realize the cause problem pretty quickly.

In that user story, the button had been hidden by another guy on the
team, but on the server, in the JSP as:-

<c:if test="${!someStrangeCondition}">
<button id="newRecord">new</button>
</c:if>

Turns out my boss asked him to hide the button in one user story and me
to hide it in another.

And so my code, which was having:-

YAHOO.util.event.onDOMReady(hideNewRecordButton);

- was throwing errors in the callback. Obviously that woud have been
avoided if I had done careful test to make sure the element existed as:-

if(newButton && newButton.style) {

}

But I didn't and so the error was on the page and was causing all the
domReady callbacks to fail, breaking the entire page.

I thought about it and realized that the same phenomenon does not occur
with dom events.

document.addEventListener("click", errFunc, false);
document.addEventListener("click", goodFunc, false);


if errFunc throws, then goodFunc still runs. The error is thrown
asynchronously. That makse perfect sense so I copied that.

Sure it does. I saw you attach a click to the document with it. (?)

That is about the *usage*. EventPublisher does not know anything about
document. It only knows that it adds a property to an object and the
property is function. It doesn't discern between host object or native
object. You could probably, though I wouldn't recommend, ad a callback
for Math.round. I have no idea why you would want to do that, but I
think it should work.
[...]

Can be useful, but most scripts are so simple that it's overkill.

It actually keeps everything separate and simple. EventPublisher is one
thing I got very right.

It is not confusing at all. I learned that from Dan Steinmann about 10
years ago.

You can have an object:-

function Car(){

}

(function(){

// Private static.
function cancelCarAnimation(){ }

Car.prototype = {

onstop : Function.prototype,
stop : function(){
if(this.isRunning) {
cancelAnimation(this)
this.isRunning = false;
this.onstop;
}
};

[...]

APE.dom.Event is a different matter. That is specifically for DOM event
handling.
Aha! Fair enough then. You'll forgive me if I don't go back and
rewrite my previous comments. If it can be deconstructed, then all is
well.

What do you mean by deconstructed?

Is there an event layer with a "custom event" layer on top of it? If
not, there is either tangling or redundancy.

No, there is no layer with "custom event" layer on top of it.
APE.dom.Event is just a few functions for things like getTarget,
addDelegatedFocusCallback, and such.

[...]

I hate GG.

Then go download Thunderbird and sign up for an account on
eternal-september.org.

Time for new years!

 

[David Mark]

The solution to the dojo problem has side effects even after going to so
much effort try try and work, even borrowing code from others, trying to
make sense of it, trying to get it to work, yet still causing system
side effects and still relying on faulty abstractions and complicating
the entire mess with all that wacko typechecking stuff.

Yeah, I had to deal with all of it at once. That's what they could
never seem to grasp. It absolutely infuriated me after I spent half
the summer rewriting and re-testing. Fix things in the basement and
you have to go from bottom to top as people write bizarre workarounds
for the flawed code below. Resig calls his similar and stunningly
ineffective patchwork approach as "test-driven development". You have
to first _understand_ the code, then you can write effective
tests.

What's that they say about doing the same thing over and over and
expecting different results? Whatever. There's at least a few people
over there that get it, but they are outnumbered.

[...]

Supercilious comments such as "lets be pragmatic" or "lets try and just
get it done" turn a blind eye to a problem.

It's pure insanity. The problem is that if you don't understand the
problems, you don't understand the solutions. If you've seen bad code
"work" in a handful of browsers (in their default configurations),
it's easy to assume that it has merit.

No kidding.  I never asserted it didn't.  All you have to do is
compare the branch to the trunk.  It's like night and day.  For one, I
removed _all_ of the browser sniffing.  Unsurprisingly, a side effect
is that it loads and runs much faster (obvious to anyone looking at
it) and is considerably smaller as well.  They wanted me to draw
pictures (e.g charts) for them and I didn't have the time or
interest.  Other than a couple of people near the top of the
structure, they want nothing to do with it (because they _had_ nothing
to do with it).  

The code of dojo 1.3 is of very poor quality. It appears to have
borrowed from various sources, yet still manages silliness like the
isFunction below. I've interspersed my comments with (GS):-

| dojo.isFunction = (function(){
|   var _isFunction = function(/*anything*/ it){
| // must evaluate separately due to bizarre Opera bug. See #8937
|
|     var t = typeof it;
|
|
| // (GS) `it can *never* be false-ish?
| // (GS) `it instanceof Function` is superfluous; if t == "function"is
| // false, then `it instanceof Function` can never be true.
|     // Boolean
|     return it && (t == "function" || it instanceof Function);
|   };
|
|   return dojo.isSafari ?
|   // only slow this down w/ gratuitious casting in Safari (not WebKit)
|     function(/*anything*/ it){
|
|  // (GS) Serializing an object to see does not convert to string
|  // (GS) "[object NodeList]" does not mean the object is a function.
|       if(typeof it == "function" && it == "[object NodeList]"){
|         return false;
|       }
|       return _isFunction(it); // Boolean
|     } : _isFunction;
| })();

The isSafari thing checks to see if an object's toString results in
"[object NodeList]". As most of us know, Safari implements callable
objects such as forms and images:-

javascript: alert(typeof document.images)

"function" in Safari, so the dojo isFunction doesn't let Safari's
document.childNOdes pass, but lets pass document.images. It makes one
wonder what they would want this function to actually do.

That's exactly what I wondered.

You'll also get that function returning true for Callable RegExp in some
browsers, false for callable regexp in other versions.
javascript: alert(typeof /a/)

Safari 4, FF2  "function"
(it is is callable)

FF3.5
"object"
(it is callable)

So the dojo.isFunction is not defined, has inconsistent results.

So I got rid of it globally. As expected, it was a completely
unnecessary function. I did remove the superfluous and obviously
incorrect bits for legacy code, of course. That's the solution.

They also have the isString function used:-

| dojo.isString = function(/*anything*/ it){
|   //  summary:
|   //          Return true if it is a String
|   return !!arguments.length && it != null && (typeof it == "string" ||
|     it instanceof String); // Boolean
| }
|

Again, we have the check `it instanceof String` which is superflous.

Only they call String as a constructor in a few places. Guess what
the solution to that was. Same as above. String objects are
definitely "bad parts".

And the isArray:-

| dojo.isArray = function(/*anything*/ it){
|   //  summary:
|   //          Return true if it is an Array
|   return it && (it instanceof Array || typeof it == "array");
| // Boolean

}

I know. I wasted a whole day arguing about that. Somehow, some way,
the consensus was that the typeof it == 'array' was needed for some
non-existent browser. It was _very_ depressing. How many days are
there in the year? How many problems are there like this in a project
that size? You can't make progress when everyone wants to argue
endlessly about nothing. It's not just Dojo of course. All of these
projects operate like this.

- which I recently commented on in ES-discuss.

See my reply to Mike Samuel's post:https://mail.mozilla.org/pipermail/es-discuss/2009-December/010406.html

Yes, I read it. I don't know who he is, but he sounds like Resig in
disguise (the word "Strawman" appears in every other sentence). Life
is too short to suffer such fools.

Mike Samuel actually seems a bit upset that I pointed out that his
argument is based off a very poor standard.

Most would-be smart-asses act like that. Then they start bitching
about "social skills" and "lets get back to having fun".

What is really sad is that discussions of this very same `isFunction`
function from dojo over two years ago. Two years and SOS.

Sounds familiar (e.g. jQuery). What can you do when people refuse to
do their homework (something one ass tried to accuse me of).

What is even more sad is that the isFunction checks are totally
unnecessary.

Absolutely. They always are and I had no problem adapting _all_ of
Dojo to work without them. But see, that means you have to change
more than one file at once, which offends some people's
"sensibilities". Suffice to say, I got very angry very quickly as I
know that it is possible to teach people who are _willing_ to learn.
It was disappointing for those who sincerely wanted to improve the
thing too. Lose-lose-lose.

When you get yourself in that position where you have to try and figure
out if the object's toString looks like "[object Nodelist]" it's time to
wake the **** up and realize that "this is dumb" and "lets not do that".

I said as much, but not in such terms. Still, that's basically what
they heard and it wasn't long before the subject changed from bad code
to what they consider "good manners" (i.e. stroking egos instead of
fixing things). Call me crazy, but I don't see software development
projects as social clubs (pointing out obvious gaffes is not a fzux
pas).

What's even more absurd is that developers readily accept this dumb
code, for which the shortcomings have been explicitly and specifically
discussed, with failure cases demonstrated.

I know. Even worse, they demand that the same demonstrations be
performed over and over, rather than just reading the specs and
admitting they made mistakes. It's not a crime to make mistakes. It
doesn't mean they are stupid. But it is a crime to stand by ignorance
in the face of overwhelming evidence. As we ring in 2010, that typeof
it == 'array' is still nestled in the bowels of the project.

Yet developers accept this
as de facto industry standard.

It's absolutely surreal.

What is even more absurd, these developers actually try to make Web
Standards proposals based on this shit.

I know (see John Resig).

The issue I experienced one day, when my manager asked me to hide a
button on a certain condition. It was the day before build. I told him
that it sounded like a simple change, but that I would not be willingto
do it before the build (how about not wing it into production?)
Right.


No good, the boss says. Put that in and hide the button on this page.

I've heard that before. That's why I do independent consulting where
they are paying me as an expert and are therefore hesitant to dismiss
my concerns out of hand.

i did it and showed it to him and he thanked me. I left to go early that
day. Early means before 7pm and that was really early. Often I left
after 8.

So I was on my way and I had an appointment. I had a massage scheduled.
Well I'm on my way, and I have a few minutes so I stop at the park to
stretch out and the phone rings. My boss calls me back in t owork.

What a shock.

Turns out that change broke the entire page, during one user story. I
got back and realize the cause problem pretty quickly.

In that user story, the button had been hidden by another guy on the
team, but on the server, in the JSP as:-

<c:if test="${!someStrangeCondition}">
   <button id="newRecord">new</button>
</c:if>

Turns out my boss asked him to hide the button in one user story and me
to hide it in another.
Oops.


And so my code, which was having:-

YAHOO.util.event.onDOMReady(hideNewRecordButton);

- was throwing errors in the callback. Obviously that woud have been
avoided if I had done careful test to make sure the element existed as:-

if(newButton && newButton.style) {

}

Yes, best to be defensive, especially when working with a team.

But I didn't and so the error was on the page and was causing all the
domReady callbacks to fail, breaking the entire page.
Right.


I thought about it and realized that the same phenomenon does not occur
with dom events.
Right.


document.addEventListener("click", errFunc, false);
document.addEventListener("click", goodFunc, false);

if errFunc throws, then goodFunc still runs. The error is thrown
asynchronously. That makse perfect sense so I copied that.

It's not a bad idea. I just don't find it necessary for most
projects.

That is about the *usage*. EventPublisher does not know anything about
document. It only knows that it adds a property to an object and the
property is function. It doesn't discern between host object or native
object. You could probably, though I wouldn't recommend, ad a callback
for Math.round. I have no idea why you would want to do that, but I
think it should work.

I get it.

[...]

Can be useful, but most scripts are so simple that it's overkill.

It actually keeps everything separate and simple. EventPublisher is one
thing I got very right.

I can't comment on that as I haven't looked at it.

It is not confusing at all. I learned that from Dan Steinmann about 10
years ago.

You can have an object:-

function Car(){

}

(function(){

// Private static.
function cancelCarAnimation(){ }

Car.prototype = {

   onstop : Function.prototype,
   stop : function(){
     if(this.isRunning) {
       cancelAnimation(this)
       this.isRunning = false;
       this.onstop;
   }

};

[...]
APE.dom.Event is a different matter. That is specifically for DOM event
handling.
Aha!  Fair enough then.  You'll forgive me if I don't go back and
rewrite my previous comments.  If it can be deconstructed, then allis
well.
What do you mean by deconstructed?

Is there an event layer with a "custom event" layer on top of it?  If
not, there is either tangling or redundancy.

No, there is no layer with "custom event" layer on top of it.
APE.dom.Event is just a few functions for things like getTarget,
addDelegatedFocusCallback, and such.

I see.

[...]

I hate GG.  

Then go download Thunderbird and sign up for an account on
eternal-september.org.

I have Thunderbird. My stupid provider canceled NNTP years ago
(idiots). Duh, they can you just use Google Groups.

Time for new years!

Yes, I'm off too. I think next year is going to see more progress
than the last. It couldn't get much worse.

 

[Garrett Smith]

[...]

Posted code should use spaces, never tabs.

function IEContentLoaded (w, fn) {
var d = w.document, done = false,
// only fire once

// (GS) Assignment to undeclared identifier (don't forget var).

init = function () {
if (!done) {
done = true;
fn();
}
};
// polling for no errors
(function () {
try {
// throws errors until after ondocumentready
d.documentElement.doScroll('left');

For one, there's not a shred of documentation anywhere that indicates
this method will throw an exception if the DOM is not ready. For two,
this _will_ throw an exception if the method is unavailable.

Why should it? This method doesn't throw errors.

 

[Garrett Smith]

[...]

Posted code should use spaces, never tabs.

function IEContentLoaded (w, fn) {
var d = w.document, done = false,
// only fire once

// (GS) Assignment to undeclared identifier (don't forget var).

init = function () {

Ah, no that is within the var declaration, no problem there.

 

[David Mark]

[...]

Posted code should use spaces, never tabs.

function IEContentLoaded (w, fn) {
   var d = w.document, done = false,
   // only fire once

// (GS) Assignment to undeclared identifier (don't forget var).

   init = function () {
           if (!done) {
                   done = true;
                   fn();
           }
   };
   // polling for no errors
   (function () {
           try {
                   // throws errors until after ondocumentready
                   d.documentElement.doScroll('left');

For one, there's not a shred of documentation anywhere that indicates
this method will throw an exception if the DOM is not ready.  For two,
this _will_ throw an exception if the method is unavailable.

Why should it? This method doesn't throw errors.

I am not saying it should. The assumption here is that it _will_
throw errors. So if it doesn't (in every browser), the whole thing
falls apart.

And, of course, if it isn't there the thing will go around in circles
forever.

 

[Scott Sauyet]

"More" is relative.  If there are n active code monkeys using jQuery,
call their posting output n squared.  But if there are n active
posters here, the total posts will be considerably less.

Just out of curiosity, do you ever even *try* to make sense?

[ ... ]  Or maybe you just want to sound smart?
Didn't work.  

Only compared to some.

-- Scott

 

[David Mark]

David,

are you sure that readyState doesn't become "complete" some time
before window.onload fires?

In IE? Absolutely.

I haven't really measured it, but it
would mean that the people who invented these states
("interactive", "complete") did not really know what the web
designers need, which would be a rather sad state of affairs.

Yes. IE is/was sad.

What I need for my current projects is perfectly clear. I need
to know when the DOM is completely built in memory, but I need
to know that before all auxiliary files, like images, are loaded
and also, if possible, before the DOM is actually rendered to
screen. I would also like to know when the DOM is completely
rendered to screen, but still before all auxiliary files are
loaded. I actually want four states: interactive, built,
rendered, complete.
Okay.


I want the last three of these states again after each dynamic
DOM modification. Every modification should change the
readyState back and then fire the event, as the DOM again goes
through the states, just like after the initial loading of the
page. Seems the designers didn't have any idea about these needs
and no desire to cater to them.

Your design is too ambitious for cross-browser scripting as browsers
sit today. Step back and reconsider what it is you are trying to
accomplish.

I fear that we currently don't have any reliable way at all to
determine when a dynamic change has been completely rendered to
screen, as the window.onload and the document.onreadystatechange
events probably don't fire again after a dynamic change. I guess
they fire only during the initial loading of the page. Can
anybody confirm or deny this?

Yes. Denied.

Has anybody here done any experiments in this regard? Like
dynamically appending a one-pixel-high element at the bottom of
the page and then checking if or when the total page height
increases by 1 pixel? There is always some work to do. -)

The height changes immediately (i.e. DOM properties reflect the
addition). The change to the layout happens some time after (usually
on exiting an execution context). Again, what is it you are trying to
do?

 

[David Mark]

Just out of curiosity, do you ever even *try* to make sense?

You didn't understand that? Let me paint you a simple picture. If
there were 10 jQuery users and they produced 100 posts in a month and
the same number of CLJ participants produced only 10 posts in the same
period of time, what would that tell you? That's point #1 (from the
post you cited). They got _more_ posts (relative to CLJ) because they
go around in circles on basic issues (e.g. attributes, browser
sniffing, etc.) Make sense?

Now, if there were - for example - only fifty jQuery posts the next
month, what would that tell you? Do the math and realize that if
there were lots of new jQuery users coming on board, the posts
wouldn't be down 50%. Seems more likely that there are more users
jumping overboard (or being forced to walk the plank).

Now, such evidence is hardly a rock-solid indicator, but even allowing
for a very wide margin for error (Google is involved after all), these
results can't indicate anything good for jQuery:-

http://groups.google.com/group/jquery-en/about

Total posts last month: 1824

That's their lowest total since August 2006 and down by almost half
from last December (right before IE8 came out). Seeing as 30% of the
questions go unanswered, nobody knows what core methods are defined to
do (e.g. attr) and IE8 breaks jQuery, it is _highly_ unlikely that
this can be attributed to a sudden bout of proficiency and/or luck
among the remaining developers.

In contrast, CLJ had 1838, which is up slightly from last year.