Why won't my (j)query work?

[David Mark]

David,

Oh, the "oncontentready" event.  Get the feeling you are reading the
wrong docs?  

Therefore, an event handler should be attached to this event in a
Literal Content component that retrieves the innerHTML property of the
custom element. Otherwise, an error occurs, which indicates that the
innerHTML property is not yet available.

Yep.  Definitely the wrong docs.  Literal Content component?!

The documentation is targeted toward behaviors/htc files but reference[/QUOTE]

Thank you. Do we need to continue?

the doScroll method of the element API.
Testing confirms that the documentation, related to doScroll, holds
for regular use in browsers and has remained consistent for 11 years.

Your tests proved nothing of the sort. And it would be no guarantee
for the future if they did. As mentioned, there are other
possibilities that do not rely on such blind faith.

I disagree. A specific object inference on the method should be
enough.

An object inference? I think you mean you would _detect_ the method.
That would be valid if it implied the behavior you assert.

You have similar in your own code.

I certainly do not detect a method and then assume the circumstances
(if any) that would cause it to throw an exception.

About the "onreadystate" comment:

You don't really need the title cards.

The dropbox example I posted is a basic example designed to provide
confirmation that technique works.
So?

A more robust solution could stop repeated calls to the function in an
onload event handler (worse case).

I think you misunderstood (a couple of things). The hack would never
call the "onload event handler" (or even a listener attached to that
event) in the case I describe.

It shows your initial lack of context as you failed to properly read
the post and jumped to unrealistic conclusions.

Hardly as it is meaningless so it doesn't imply any context. And I'm
growing tired of this bantering. Please give it a rest.

Again object inference with the "shreds" of documentation and tests
are enough here.

There's the whole problem summed up in one sentence. You just don't
know what you are doing and I can't seem to help you.

No I did.

That's good.

I was stating you can fire up a virtual machine/pc and test it on an
image if you had one handy.



It was the age of IE 5.0.

Great. That's another browser where jQuery will drop dead.

The code reviewed was not jQuery code.

But jQuery and others use that code (among many other bad things).
Isn't that the Elephant in the Room here? Certainly nobody cares what
Diego Perrini uses on his test page.

I am not defending jQuery's coding practices.

Good. I've got an inside tip that it's a lost cause.

Developers influence browser development all the time.

What do you mean by developers? What do you mean by influence? What
do you mean by "all the time?" And what do you mean by wasting my
time like this?

The popularity of selecting elements by css selectors helped pave the
way for querySelectorAll().

No kidding. As I've mentioned, it was a really bizarre and unneeded
development. And ironically, it is going to kill jQuery.

Some browsers even allow per site compatibility patching.http://blogs.msdn.com/ie/archive/2008/12/03/compatibility-view-improv...

I'm not going to fetch an MSDN blog. I'll just speculate that it is
more irrelevance unless you indicate what it is supposed to mean in
context.

I am referring to your review over IEContentLoaded not the various
others.http://groups.google.com/group/comp.lang.javascript/msg/c8a115d7d7cf87b4

Well, take it or leave it.

Look again

:\

 

[jdalton]

David,

Your tests proved nothing of the sort.

Does to

And it would be no guarantee
for the future if they did.

The tests don't guarantee future use but having documentation doesn’t
either as the case with Firefox removing document.getBoxObjectFor()
proves.
The doScroll method and it's behavior have a very long history which
strengthens the argument for its continued use.

As mentioned, there are other
possibilities that do not rely on such blind faith.

You don’t mean your solution (http://www.cinsoft.net/mylib-
domready.js) which limits script placement, uses IE conditional
comments (ruined by some minification), and will cause a false
positive (more than likely resulting in an error) if part of the page
is flushed to the output buffer early.

I think you misunderstood (a couple of things). The hack would never
call the "onload event handler" (or even a listener attached to that
event) in the case I describe.

Your case isn’t based in reality.
No one is calling the function without some kind of condition in place
first.

There's the whole problem summed up in one sentence. You just don't
know what you are doing and I can't seem to help you.

I don’t know if insults would qualify as help.

What do you mean by developers? What do you mean by
influence? What
do you mean by "all the time?" And what do you mean by
wasting my
time like this?

Heh, I am not sure how to respond to that.
I guess google is your friend.

I'm not going to fetch an MSDN blog. I'll just speculate that it is
more irrelevance unless you indicate what it is supposed to mean in
context.

Putting your head in the sand doesn’t help.

-JDD

 

[jdalton]

David,

if part of the page is flushed to the output buffer early.

* if the pages output buffer is flushed early.

Additional info on flushing for better perceived page load
performance.
http://www.phpied.com/progressive-rendering-via-multiple-flushes/
http://developer.yahoo.com/performance/rules.html#flush

However, the "doScroll" technique works (as in it won't produce a
false positive) under these conditions.

-JDD

 

[Garrett Smith]

I run several Drupal sites, and Comcast always rejects
registration emails from them, so no Comcast mail user can ever
register on any of my sites.

Note that my mail server is elaborately set up, with valid SPF,
Domainkeys, six nameservers, etc. They have no excuse.

Of course, Comcast never reacts to postmaster email either.

They won't give you any real answers over the phone, either.

I have been personally lied to during initial signup representative gave
me false rates over the phone.

Comcast is an American business. They are also cable company. They have
money for marketing and money for lawyers.

(this is not my Comcast acct).

 

[David Mark]

David,



Does to

*PLONK*

 

[Garrett Smith]

[...]

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.

By "it", you meant "doScroll", but I had thought you meant "IEContentLoaded"

IEContentLoaded won't throw errors; doScroll will. Relying on doScroll
throwing errors seems risky because the documentation for doScroll does
not explicitly state that it will throw errors.

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

That is a problem. The object inference should test for presence of
doScroll using typeof.

var docEl = document.documentElement;
var HAS_DO_SCROLL = typeof docEl .doScroll != "undefined";

If the doScroll method ends up not throwing an error, then the callback
function fires, possibly too early. That would bad.

 

[Diego Perini]

David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:

[...]

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.

By "it", you meant "doScroll", but I had thought you meant "IEContentLoaded"

IEContentLoaded won't throw errors; doScroll will. Relying on doScroll
throwing errors seems risky because the documentation for doScroll does
not explicitly state that it will throw errors.

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

That is a problem. The object inference should test for presence of
doScroll using typeof.

var docEl = document.documentElement;
var HAS_DO_SCROLL = typeof docEl .doScroll != "undefined";

If the doScroll method ends up not throwing an error, then the callback
function fires, possibly too early. That would bad.

Thank you Garret, you are correct it is on my todo list, even if I am
sure only IE will ever go through there an extra check for the method
to exists wouldn't hurt, it will be included in next revision. In
that, I am actually testing a solution to cover IFRAME's ContentLoaded
(IE only too).