Why won't my (j)query work?
David Mark
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/31f1592d11c3bbe6
http://groups.google.com/group/jquery-en/browse_thread/thread/23d0f3c908410e3f#
This bit says it all:-
$(':checkbox[name=number]').click(function() {
if ($(this).is(':checked')) alert($(this).val());
});
This is the sort of thing that is sold as "simpler" than basic DOM
scripting. Sure looks like the function body - for example - could be
reduced to something like:-
if (this.checked) alert(this.value);
Smaller, more readable, no function calls, no guesswork about what
goes on in those functions and it's impervious to jQuery "upgrades".
It's even less typing (as if that was ever a rational concern).
A demonstration:-
http://www.cinsoft.net/queries.html
The example uses jQuery, but the rest will fail in similar fashion.
And these issues are just the tip of the iceberg for most of them.
They could even be considered "edge cases" (a recurring theme for
these things), except that there are tons of other mistakes in-
between. These are simply the easiest to demonstrate.
The worst implementation has got to be YUI as its hasAttribute wrapper
treats empty attribute values the same as missing attributes. (!)
<input type="checkbox" checked>
elCheckbox.getAttribute('checked') // '' in most browsers
<input type="checkbox">
elCheckbox.getAttribute('checked') // null in most browsers
YUI3, the latest and "greatest" time-saver from Yahoo will report an
empty string for both. How is that helping? All it does is reinforce
the myth that cross-browser scripting is impossible. I guess for
Yahoo (and the rest of these bums), it _is_ impossible.
No, the query engine in My Library is not perfect either (though it is
much closer than the rest of these things), but then I never advocated
using CSS selectors to query the DOM in the first place. I spent a
weekend putting the thing together just to see what was involved. My
advice is to avoid it (there are plenty of simpler alternatives for
finding elements).
Furthermore, I didn't bother trying to support _all_ of the selector
types as that's just silly. The "majors" love to tick off the
selectors they "support", but it doesn't really count if they don't
work _reliably_ cross-browser (like gEBI and gEBTN). For those
wondering, if a selector type is on the speed test page, it's
supported.
For aspiring library luminaries, start with a foundation like this:-
http://www.cinsoft.net/attributes.html
...and you can write a serviceable query engine (and have some hope of
success in "old" browsers like IE7 and Opera 9). I will transplant
these functions back into My Library when I have a chance (or if there
is a specific request.).
But I still say it is a waste of time (three years and counting for
the "majors" and a couple of weekends for me). ;)
Thomas 'PointedEars' Lahn
> 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/31f1592d11c3bbe6>
>
> <http://groups.google.com/group/jquery
> en/browse_thread/thread/23d0f3c908410e3f#>
>
> This bit says it all:-
>
> $(':checkbox[name=number]').click(function() {
> if ($(this).is(':checked')) alert($(this).val());
> });
>
> This is the sort of thing that is sold as "simpler" than basic DOM
> scripting. Sure looks like the function body - for example - could be
> reduced to something like:-
>
> if (this.checked) alert(this.value);
>
> Smaller, more readable, no function calls, no guesswork about what
> goes on in those functions and it's impervious to jQuery "upgrades".
> It's even less typing (as if that was ever a rational concern).
JFTR: For those who still buy into the potentially error-prone "Unobtrusive
JavaScript" pattern, since the `click' event bubbles, the rest of it can be
replaced by more efficient code, too (only minimal feature tests included,
not yet optimized):
document.body.onclick = function(e) {
if (!e) e = window.event;
if (e)
{
var t = e.target || e.srcElement;
if (t && t.tagName.toUpperCase() == "INPUT"
&& t.type.toLowerCase() == "checkbox"
&& t.name == "number")
{
if (t.checked) alert(t.value);
}
}
};
Of course, a more reasonable approach would be to handle the `click' event
at the form or fieldset level, preferably through the standards-compliant
backwards-compatible event-handler attribute:
<fieldset onclick="if (typeof event != 'undefined') fsClick(event)">
<input type="checkbox" name="number" value="...">
<input type="checkbox" name="number" value="...">
<input type="checkbox" name="number" value="...">
</fieldset>
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
David Mark
wrote:
No harm done, but I consider it safe to skip this check.
> var t = e.target || e.srcElement;
> if (t && t.tagName.toUpperCase() == "INPUT"
> && t.type.toLowerCase() == "checkbox"
> && t.name == "number")
> {
> if (t.checked) alert(t.value);
> }
> }
> };
But where programmers are architects, Web developers are paper hangers
(they only deal in patterns). This example will make them shriek
about writing assembly language and such. :)
>
> Of course, a more reasonable approach would be to handle the `click' event
> at the form or fieldset level, preferably through the standards-compliant
> backwards-compatible event-handler attribute:
>
> <fieldset onclick="if (typeof event != 'undefined') fsClick(event)">
> <input type="checkbox" name="number" value="...">
> <input type="checkbox" name="number" value="...">
> <input type="checkbox" name="number" value="...">
> </fieldset>
>
Absolutely. But to the indoctrinated Web developer/code monkey, this
is "old-fashioned" and "obtrusive". They want to play Chess, but
haven't yet mastered Checkers. ;)
The biggest problem I see here is that many of these aspiring
developers refuse to test anything but the latest browsers (it is
considered a waste of time as they just want to Get Things Done). And
since most of the latest now have QSA, it is very easy to write a
script that works perfectly in - for example - IE8, but fails when you
click the Compatibility Mode button (or in IE < 8). Somehow they
think if they blow up enough documents in "broken" browsers/modes,
everyone will upgrade and catch up to their "progressive" designs. :)
Garrett Smith
I buy into that pattern. Works great.
It would be pretty odd to have two elements with different type, yet
same name. Instead, why not have the "number" named elements be the
checkboxes?
Using the getTarget function from APE:-
function bodyClickHandler(ev) {
var target = APE.dom.Event.getTarget(ev);
if(target && target.checked && target.name === "number") {
alert(target.value);
}
}
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
S.T.
> For the typical neophyte, CSS selectors are magic. Put in a selector,
Your crusade against libraries is well past the boring stage. Ramble
about something else that might actually be interesting to read.
Here ya go:
http://www.nczonline.net/blog/2009/12/29/feature-detection-is-not-browser-detection/
Makes sense to me. Well articulated. Points out flaws of some libraries
(JACKPOT!!!!) but manages to be informative at the same time. Seems
like a good role model for you.
David Mark
The problem is that document.body is unavailable while the HEAD is
parsing. As most developers insist on putting SCRIPT elements in the
HEAD, this cannot run until the DOM is ready. As IE (among others)
has no DOMContentLoaded event, you must use the load event, which can
delay execution for documents bloated with too many images, IFrames,
flash, etc., so bizarre hacks have come into vogue. Like this "fine
script for the window.onload problem":-
http://javascript.nwbox.com/IEContentLoaded/
function IEContentLoaded (w, fn) {
var d = w.document, done = false,
// only fire once
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.
} 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.
return;
}
// no errors, fire
Fire when ready? Cancel that order. :)
init();
})();
// trying to always fire before onload
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();
}
};
}
This junk has already been copied into jQuery and YUI (and I imagine
others will follow suit). Ostensibly, it is less likely to cause the
dreaded "Operation Aborted" error in IE. Such "logic" has no place in
programming (especially not in browser scripting). Why not design
with reality in mind?
Asen Bozhilov
> Here ya go:http://www.nczonline.net/blog/2009/12/29/feature-detection-is-not-bro...
<URL: http://jibbering.com/faq/faq_notes/not_browser_detect.html>
Posted url from you, doesn't says anything new. Looks like a bad
reverse engineering of article in FAQ. Moreover article in FAQ doesn't
make PR of MooTools or anything other libs.
David Mark
> On 12/29/2009 3:34 PM, David Mark wrote:
>
> > For the typical neophyte, CSS selectors are magic. Put in a selector,
> > get out a collection of matching elements...
>
> Your crusade against libraries is well past the boring stage. Ramble
> about something else that might actually be interesting to read.
As usual, you want to change the subject. :)
(Very) old news.
http://www.jibbering.com/faq/faq_notes/not_browser_detect.html
>
> Makes sense to me. Well articulated. Points out flaws of some libraries
> (JACKPOT!!!!) but manages to be informative at the same time.
You find my postings uninformative compared to that basic
regurgitation?
From one of the comments:-
"For instance, there’s no way to feature-detect if a particular flavor
of CSS opacity is supported or not, since there’s no way in JavaScript
to tell if the opacity was rendered or not."
It seems something was lost in translation. ;) And that guy is
promoting his own browser sniffing code (of course).
Then there's this comment:-
"I’d also caution that user-agent sniffing isn’t as fragile as you
make it out to be. Any program, when written poorly and without the
proper amount of insight, is bound to fail. Many user-agent sniffs do
fall into that category but that doesn’t mean it can’t be done
properly (for instance, I show a safe way to do so in my book)."
LOL. Don't buy _that_ book. And BTW, these comments are from
_today_.
> Seems
> like a good role model for you.
More like another wannabe. ;)
JR
> 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-en/browse_thread/thread/23d0f3c...
I had a very sad realization after reading that Microsoft and Nokia
have adopted jQuery (I didn't know that):
http://www.eweek.com/c/a/Application-Development/Microsoft-Adopts-OpenSource-jQuery-JavaScript-Library/
The worse part is that the jQuery team will keep control.
On top of that, the jQuery's creator, John Resig, works side by side
with Brendan Eich, the creator of Javascript and CTO at the Mozilla
Corporation. Geez, I had goose bumps just for thinking about what all
these facts could interfere with the development of the next versions
of IE and Firefox. If these two companies adapt their browsers to work
smoothly with jQuery, or at least to not fail with jQuery, then I
suppose the rest of the browser vendors would blindly follow the
giants.
It's not a promising start for 2010...
--
JR
David Mark
Speaking of MooTools. Remember they used getBoxObjectFor to
"identify" FF? Then they found out that particular method was
deprecated. They actually issued a _recall_ with this statement:-
"We have overhauled our browser detection to be based on the user
agent string. This has become the standard practice among JavaScript
libraries because of potential issues as Firefox 3.6 demonstrates."
Browser detection has _become_ the standard practice? Who knew? I
thought it went out with the last century. :)
"As browsers grow closer together, looking at “features” to separate
them will become more difficult and risky. From this point forward,
browser detection will only be used where it would be impossible not
to, in order to give the consistent experience across browsers that
one would expect from a world-class JavaScript framework."
Unbelievable. But then, I suppose such confused waffling is
predictable as the authors of MooTools have no idea what they are
doing. ;)
http://www.flickr.com/photos/7825776@N04/2347642183/sizes/o/
David Mark
[...]
>
> I had a very sad realization after reading that Microsoft and Nokia
> have adopted jQuery (I didn't know that):http://www.eweek.com/c/a/Application-Development/Microsoft-Adopts-Ope...
AFAIK, they just include the script (whatever version is handy) in
their Visual Studio distribution. But there was much rejoicing in
jQuery-land when this was announced. They seemed sure they "won"
something.
>
> The worse part is that the jQuery team will keep control.
Yeah, that's some team they've got there. I'm reminded of the
football coach who, when asked about his team's execution, responded:
"I'm all for it." :)
>
> On top of that, the jQuery's creator, John Resig, works side by side
> with Brendan Eich, the creator of Javascript and CTO at the Mozilla
> Corporation.
Then how is it he is so clueless about the language? And, as for side
by side, I imagine Resig's office is nowhere near the executive floor
(probably in the evangelical complex).
> Geez, I had goose bumps just for thinking about what all
> these facts could interfere with the development of the next versions
> of IE and Firefox.
Don't worry, browser developers don't bend for code monkeys.
> If these two companies adapt their browsers to work
> smoothly with jQuery, or at least to not fail with jQuery, then I
> suppose the rest of the browser vendors would blindly follow the
> giants.
There's no way to pin down what jQuery does. It changes constantly as
they "discover" new issues (e.g. the decade-old MSHTML attribute
problem was recently a hot topic).
>
> It's not a promising start for 2010...
No, I think interest in jQuery (and things like it) is waning.
Ironically IE8, which came out just after the MS announcement, is a
big reason.
Garrett Smith
Pointing out the logical fallacy of affirming the consequent.
The "I didn't mean to pick on moo" is limp.
Garrett Smith
> On Dec 29, 7:52 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> David Mark wrote:
[...]
>> I buy into that pattern. Works great.
>
> The problem is that document.body is unavailable while the HEAD is
> parsing. As most developers insist on putting SCRIPT elements in the
> HEAD, this cannot run until the DOM is ready. As IE (among others)
> has no DOMContentLoaded event, you must use the load event, which can
> delay execution for documents bloated with too many images, IFrames,
> flash, etc., so bizarre hacks have come into vogue. Like this "fine
> script for the window.onload problem":-
>
That is not a problem.
Either add the callback to `document` or put the script at the bottom.
No problem.
David Mark
> S.T. wrote:
> > On 12/29/2009 3:34 PM, David Mark wrote:
> >> For the typical neophyte, CSS selectors are magic. Put in a selector,
> >> get out a collection of matching elements...
>
> > Your crusade against libraries is well past the boring stage. Ramble
> > about something else that might actually be interesting to read.
>
> > Here ya go:
>
> > Makes sense to me. Well articulated. Points out flaws of some libraries
> > (JACKPOT!!!!) but manages to be informative at the same time. Seems
> > like a good role model for you.
>
> Pointing out the logical fallacy of affirming the consequent.
>
> The "I didn't mean to pick on moo" is limp.
No question, especially given what follows:-
"I really didn’t mean to pick on MooTools when I first started writing
this post. It just happens to present a really good learning
opportunity for other developers. The MooTools developers are smart
folks who I’m sure are continuing to work to improve their library and
actively support their large user base. We all go through a similar
learning curve, and we can all learn from one another."
Why are these guys so obsequious? The MooTools developers are
incompetent and never mind their "large user base". And the "learning
curve" comment is priceless. It's almost 2010. Perhaps it is the
year they make contact (with reality).
I posted a comment, but according to the author (who is trying to sell
a book), comments are "heavily moderated". I bet. ;)
"You are both (very) late to the ball. This (very similar) article is
from the turn of the century. ;)
http://www.jibbering.com/faq/faq_notes/not_browser_detect.html
And yes, you can detect which opacity style to use:-
http://perfectionkills.com/feature-testing-css-properties/
http://www.cinsoft.net/mylib.html
...and the idea of a script loader (another one?!) using browser
sniffing is crazy. Change the design to suit reality; don’t impose
your delusions on the general public. Or just forget it."
David Mark
You mean window.onload? Sure. But you still end up with two
different behaviors (one before and one after load), which often
mandates hiding parts of the document during load.
But I was presenting the "problem" as the typical framework developer
sees it. I suggested the bottom dwelling script recently and was told
that the "progressive enhancement folks" would have a fit over it (and
requiring two pastes is such an ugly imposition). ;)
>
> No problem.
They'll carp about DOMContentLoaded too.
Garrett Smith
> On Dec 29, 9:58 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> David Mark wrote:
>>> On Dec 29, 7:52 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> David Mark wrote:
>> [...]>> I buy into that pattern. Works great.
>>
>>> The problem is that document.body is unavailable while the HEAD is
>>> parsing. As most developers insist on putting SCRIPT elements in the
>>> HEAD, this cannot run until the DOM is ready. As IE (among others)
>>> has no DOMContentLoaded event, you must use the load event, which can
>>> delay execution for documents bloated with too many images, IFrames,
>>> flash, etc., so bizarre hacks have come into vogue. Like this "fine
>>> script for the window.onload problem":-
>> That is not a problem.
>>
>> Either add the callback to `document` or put the script at the bottom.
>
> You mean window.onload?
No, I meant document. As in document.onclick, not document.body.onclick.
The function can be placed anywhere, but must come after whereever
APE.dom is defined (dom.js).
<script type="text/javascript" src="dom.js"></script>
<script type="text/javascript">
document.onclick = documentClickHandler;
function documentClickHandler() {
var target = APE.dom.Event.getTarget(ev);
if(target && target.checked && target.name === "number") {
alert(target.value);
}
}
</script>
I would not add a global "documentClickHandler" function. I would also
not add the callback that way. Instead, I would use an event registry.
For example:-
EventPublisher.add(document, "onclick", documentClickHandler);
The reason for using EventPublisher for that is to avoid potential
conflict with other script that uses document.onclick. EventPublisher
replaces document's onclick callback. If an event handler property by
that name already exists, then it is added first to the callbacks array.
David Mark
> David Mark wrote:
> > On Dec 29, 9:58 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> >> David Mark wrote:
> >>> On Dec 29, 7:52 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> >>>> Thomas 'PointedEars' Lahn wrote:
> >>>>> David Mark wrote:
> >> [...]>> I buy into that pattern. Works great.
>
> >>> The problem is that document.body is unavailable while the HEAD is
> >>> parsing. As most developers insist on putting SCRIPT elements in the
> >>> HEAD, this cannot run until the DOM is ready. As IE (among others)
> >>> has no DOMContentLoaded event, you must use the load event, which can
> >>> delay execution for documents bloated with too many images, IFrames,
> >>> flash, etc., so bizarre hacks have come into vogue. Like this "fine
> >>> script for the window.onload problem":-
> >> That is not a problem.
>
> >> Either add the callback to `document` or put the script at the bottom.
>
> > You mean window.onload?
>
> No, I meant document. As in document.onclick, not document.body.onclick.
Oh. That will work for this example, but it's not a typical
delegation strategy. I don't care for using body either (in most
cases). A fieldset (or other container) would be the best bet.
>
> The function can be placed anywhere, but must come after whereever
> APE.dom is defined (dom.js).
Yes, if you are using that script.
>
> <script type="text/javascript" src="dom.js"></script>
> <script type="text/javascript">
> document.onclick = documentClickHandler;
>
> function documentClickHandler() {
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.
> if(target && target.checked && target.name === "number") {
> alert(target.value);
> }
> }
> </script>
>
> I would not add a global "documentClickHandler" function. I would also
> not add the callback that way. Instead, I would use an event registry.
> For example:-
>
> EventPublisher.add(document, "onclick", documentClickHandler);
Or just use addEventListener/attachEvent. ;) And why do you have to
pass "onclick"? ISTM that "click" would suffice (as in My Library):-
API.attachDocumentListener('click', documentClickHandler);
And if you act now, I'll throw in:-
D(document).on('click', documentClickHandler);
...you just pay the extra shipping and handling.
>
> The reason for using EventPublisher for that is to avoid potential
> conflict with other script that uses document.onclick.
I think this example is getting a little too APE-centric. :)
Andrew Poulos
> On 12/29/2009 3:34 PM, David Mark wrote:
>> For the typical neophyte, CSS selectors are magic. Put in a selector,
>> get out a collection of matching elements...
>
> Your crusade against libraries is well past the boring stage. Ramble
> about something else that might actually be interesting to read.
How about, instead of making emotional comments about the person, trying
to refute some of the many factual points that are raised.
Andrew Poulos
Garrett Smith
> On Dec 30, 3:00 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> David Mark wrote:
>>> On Dec 29, 9:58 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>>>> David Mark wrote:
>>>>> On Dec 29, 7:52 pm, Garrett Smith <dhtmlkitc...@gmail.com> 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.
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).
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).
Local aliases are often useful things:-
(function(){
var dom = APE.dom;
// ...
})();
>> if(target && target.checked && target.name === "number") {
>> alert(target.value);
>> }
>> }
>> </script>
>>
>> I would not add a global "documentClickHandler" function. I would also
>> not add the callback that way. Instead, I would use an event registry.
>> For example:-
>>
>> EventPublisher.add(document, "onclick", documentClickHandler);
>
> Or just use addEventListener/attachEvent. ;) And why do you have to
> pass "onclick"? ISTM that "click" would suffice (as in My Library):-
>
EventPublisher is designed as a pure AOP event notification system. That
is why "onclick" must be used. EventPublisher provides functionality for
event notification and has nothing to do with the DOM.
In a way, EventPublisher is like dojo.connect, but without the
complexity buried in the argument typechecking. EventPublisher also
catches and rethrows errors instead of breaking on the first error, as
many libraries do (or did).
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 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.
}
function aEndHandler(){
alert("all done!");
}
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.
It should also be possible to extend EventPublisher, so that the code
could be used as:-
a.add("onplay", runA);
Thought that is not necessary. Besides being unnecessary, the name of
the instance method, `add`, should be renamed to `addCallback`.
APE.dom.Event is a different matter. That is specifically for DOM event
handling.
> API.attachDocumentListener('click', documentClickHandler);
>
> And if you act now, I'll throw in:-
>
> D(document).on('click', documentClickHandler);
>
That method seems intended for DOM event handlers.
The D method should probably be renamed to something sensible.
> ...you just pay the extra shipping and handling.
>
>> The reason for using EventPublisher for that is to avoid potential
>> conflict with other script that uses document.onclick.
>
> I think this example is getting a little too APE-centric. :)
Ideally, I woul just use:-
ev.target
- but that won't work in IE, and may have problems in Safari 2.
It would not be sensible to write every line of code from scratch. An
abstraction is appropriate here.
Instead of repeating:
ev = ev || window.event;
target = ev && ev.target || ev.srcElement;
- I prefer an abstraction like:-
// using a local `Event` alias.
var target = Event.getTarget(ev);
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.
Matt Kruse
> How about, instead of making emotional comments about the person, trying
> to refute some of the many factual points that are raised.
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."
Okay, we get it. Can we move on? Clearly, David has identified some
problems in major libraries. Clearly, these problems are not as show-
stopping as he makes them out to be, otherwise the bug trackers for
each project would be filled with complaints from users. If the error
results in a css selector engine returning an incorrect result in a
specific case using an attribute selector for a specific tag and
specific attribute, then that's a problem. But clearly not one that
most users will ever encounter, nor justification for throwing out
libraries entirely or declaring their authors inept. Again, "don't
throw the baby out with the bathwater."
He reminds me a bit of Gomer Pyle issuing a citizen's arrest:
http://www.youtube.com/watch?v=9efgLHgsBmM
What David is doing is publicity, nothing more. He's said he's writing
a book about this stuff, and he is an independent js author trying to
seek attention. He believes that destroying the reputation of the js
libraries will boost his credibility and put him in the position of
respected authority on the matter, which will help him push whatever
it is that he has to sell. It's so transparent that it's just worthy
of an eye-roll at this point.
Matt Kruse
An ignorant person is one who doesn't know what you have just found
out.
-- Will Rogers
Nothing can be so amusingly arrogant as a young man who has just
discovered an old idea and thinks it is his own.
-- Sidney J. Harris
Sherm Pendley
> On Dec 30, 3:00�am, Andrew Poulos <ap_p...@hotmail.com> wrote:
>> How about, instead of making emotional comments about the person, trying
>> to refute some of the many factual points that are raised.
>
> 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."
>
> Okay, we get it. Can we move on?
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.
sherm--
S.T.
> <URL: http://jibbering.com/faq/faq_notes/not_browser_detect.html>
>
> Posted url from you, doesn't says anything new. Looks like a bad
> reverse engineering of article in FAQ.
I found it to be a quality article, though I didn't necessarily expect
posters in this particular thread to think so. The 'quickly dismiss'
type reaction from said posters was expected as well.
> Moreover article in FAQ doesn't
> make PR of MooTools or anything other libs.
>
That highly technical ~16 page FAQ article on a topic of such narrow
scope *is* the PR for MooTools, jQuery, YUI, etc.
If a thorough understanding of CLJ FAQ represents the alternative to
libraries -- particularly what's related to DOM and AJAX -- the
libraries have an exceptionally bright future.
Andrew Poulos
> On Dec 30, 3:00 am, Andrew Poulos<ap_p...@hotmail.com> wrote:
>> How about, instead of making emotional comments about the person, trying
>> to refute some of the many factual points that are raised.
>
> 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."
Surely you know you are trying to hide the many, many valid factual
criticisms by claiming they are all one point.
> Okay, we get it. Can we move on?
No, I don't think you do get it.
Andrew Poulos
Andrew Poulos
Calling DM an obsessive and tiresome doesn't mean its right to ignore
all the valid factual criticisms that have been freely given. For me,
his credibility is at an extremely high level until, I guess, such time
that you can point out flaws in the logic.
Andrew Poulos
David Mark
> On Dec 30, 3:00 am, Andrew Poulos <ap_p...@hotmail.com> wrote:
>
> > How about, instead of making emotional comments about the person, trying
> > to refute some of the many factual points that are raised.
>
> David has latched on to one very specific issue that he has researched
> and apparently understands well, whereas many other javascript authors
> do not.
I haven't latched on to any specific issue. I've pointed out
_hundreds_ of issues in your favorite script (much to your chagrin).
The problems are systemic and (as you well know) the authors are
incapable of solving them in a timely fashion (or at all). Why do you
keep popping up and blithering the same nonsense?
It is clear that a CSS selector based interface was a terrible idea
from the start and none of the various libraries came close to
realizing it (in three years!) As this is the primary interface that
is supposed to make it easy for neophytes to "Ajaxify" Web pages, I
think the point is clear.
And, of course, now that we have QSA (and no backward compatible
alternative), time has passed these things by (as evidenced by the
three-year low activity in the jQuery group.) ;)
> 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."
Don't be stupid. That was the discussion I had with - for example -
John Resig, over two fucking years ago. You were around for that.
Amnesia? And where does he get off designing something he can't write
and then slathering it all over the Web? What a mess. :(
And there couldn't be anything less useful than DOM libraries/
frameworks that can't even _read_ documents. What does that tell you
about the progress on those fronts? These are supposed to be the
magic solutions that take all the guesswork out of it for neophytes.
But the authors are guessing themselves (and not very successfully).
Do you not understand that everything is built on top of documents and
attributes?
>
> Okay, we get it. Can we move on? Clearly, David has identified some
> problems in major libraries.
Clearly you want attention. :)
> Clearly, these problems are not as show-
> stopping as he makes them out to be, otherwise the bug trackers for
> each project would be filled with complaints from users.
They _are_ and you know it. I've posted _hundreds_ of links to just
such examples (and you bitch every time that I'm "making fun"). So
what are you trying to say now?!
And it is perfectly possible to waste tons of time working around the
land mines in something like jQuery, resulting in an app that
_appears_ to work, but will break when the next browser (or jQuery
version) comes out. We've been over this a million times.
> If the error
> results in a css selector engine returning an incorrect result in a
> specific case using an attribute selector for a specific tag and
> specific attribute, then that's a problem.
Obviously that's a problem, especially when it is correct in half and
wrong in the other half. Web developers aren't particularly vigilant
when it comes to testing you know.
> But clearly not one that
> most users will ever encounter,
What in the hell are you talking about? You should see the result map
for jQuery, YUI, etc. They are more red than green in anything but
the very latest browsers in standards mode. Great leveler those are.
But back up a second, even without the map, you should be able to
predict the spottiness based on what I've already told you. And you
know damned well that the typical jQuery user is clueless about such
things, so what will they do when things go wrong? Waste a bunch of
time furrowing their brows, post to the jQuery group and get a few
guesses in response, or perhaps give up and re-work their app to use
some other part of jQuery? Or maybe they try a wholesale substitution
hoping that jQuery has fixed itself. It's all a waste of time and
money. The marketing says the opposite and I'm tired of hearing you
parrot that message.
> nor justification for throwing out
> libraries entirely or declaring their authors inept.
It _is_ justification for throwing them out (the authors too). It's
been three years (going on four) of wasted time due to incompetence
(and blithering idiots like you). Do the world a favor and shut up
about this stuff.
> Again, "don't
> throw the baby out with the bathwater."
You always say that. What sort of baby is jQuery? Rosemary's baby?
>
> He reminds me a bit of Gomer Pyle issuing a citizen's arrest:http://www.youtube.com/watch?v=9efgLHgsBmM
You know you don't want to start up with that sort of shit,
Haney. ;) And this ain't about some hick town. These issues affect
the whole world. 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?
>
> What David is doing is publicity, nothing more.
That makes no sense at all. Why is it that my code and ideas always
end up (in some form) in jQuery, Prototype, etc. It's usually years
later after I've beat the authors over the head with them. Why should
it take such an effort to get people to see straight? And why are you
bitching about it? Oh, that's right. You want publicity for whatever
bullshit you are doing these days. ;)
> He's said he's writing
> a book about this stuff,
I am and several samples have already been posted (and appear to be
quite popular, thank you very much!)
> and he is an independent js author trying to
> seek attention.
What's an "independent js author?" I do a lot of consulting for Web-
centric companies, if that is what you mean. Yes, JS is typically
involved. Sue me!
> He believes that destroying the reputation of the js
> libraries will boost his credibility and put him in the position of
> respected authority on the matter, which will help him push whatever
> it is that he has to sell.
Fait accompli. :)
> It's so transparent that it's just worthy
> of an eye-roll at this point.
And the more you protest...
[...]
>
> Nothing can be so amusingly arrogant as a young man who has just
> discovered an old idea and thinks it is his own.
> -- Sidney J. Harris
Now that sounds like Resig and the rest. They "found" something that
existed years before (and then completely screwed it up for years,
eventually admitting they didn't understand it at all).
David Mark
> Matt Kruse <m...@thekrusefamily.com> writes:
> > On Dec 30, 3:00 am, Andrew Poulos <ap_p...@hotmail.com> wrote:
> >> How about, instead of making emotional comments about the person, trying
> >> to refute some of the many factual points that are raised.
>
> > 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."
>
> > Okay, we get it. Can we move on?
>
> Well said, thank you.
And which part did you _get_ before I posted it? ISTM that Matt Kruse
has been saying for years that there's nothing wrong with jQuery.
Then every time I point out another fatal flaw, he goes nuts and
blames me for "obsessing" about _his_ favorite library.
David Mark
> On 12/29/2009 5:45 PM, Asen Bozhilov wrote:
>
> > <URL:http://jibbering.com/faq/faq_notes/not_browser_detect.html>
>
> > Posted url from you, doesn't says anything new. Looks like a bad
> > reverse engineering of article in FAQ.
>
> I found it to be a quality article, though I didn't necessarily expect
> posters in this particular thread to think so. The 'quickly dismiss'
> type reaction from said posters was expected as well.
It is _not_ a quality article. It's a step backwards. Read it again.
>
> > Moreover article in FAQ doesn't
> > make PR of MooTools or anything other libs.
>
> That highly technical ~16 page FAQ article on a topic of such narrow
> scope *is* the PR for MooTools, jQuery, YUI, etc.
What highly technical article? The one on browser sniffing? Is it
your contention that it is so thick as to drive people to use God-
awful scripts like jQuery, MooTools, YUI, etc.? Sounds like mass
hysteria to me. Just learn to read instead. ;)
>
> If a thorough understanding of CLJ FAQ represents the alternative to
> libraries -- particularly what's related to DOM and AJAX -- the
> libraries have an exceptionally bright future.
Don't be silly (a tall order I know).
Matt Kruse
> Surely you know you are trying to hide the many, many valid factual
> criticisms by claiming they are all one point.
There are lots of valid criticisms. The relentless hammering of the
attribute issue is what has gotten tiresome. First in the form of
criticizing jQuery's attr(), then in jQuery's selectors, then
MooTools, then YUI, etc, etc.
> > Okay, we get it. Can we move on?
> No, I don't think you do get it.
Could you be more vague?
Matt Kruse
Matt Kruse
> ISTM that Matt Kruse
> has been saying for years that there's nothing wrong with jQuery.
If you check the archives, I believe you will find just the opposite.
Rather, I think I realize its flaws yet still acknowledge its value
and position in the world of browser scripting.
Matt Kruse
David Mark
> On Dec 30, 1:53 pm, Andrew Poulos <ap_p...@hotmail.com> wrote:
>
> > Surely you know you are trying to hide the many, many valid factual
> > criticisms by claiming they are all one point.
>
> There are lots of valid criticisms. The relentless hammering of the
> attribute issue is what has gotten tiresome. First in the form of
> criticizing jQuery's attr(), then in jQuery's selectors, then
> MooTools, then YUI, etc, etc.
They all have the same basic problems in their lowest-level code.
Sounds like a plague? And none of them have fixed a bit of it in
three years (as you well know).
http://groups.google.com/group/jquery-dev/browse_thread/thread/baef5e91bd714033#
http://groups.google.com/group/jquery-dev/browse_thread/thread/fe658871a8bff208#
http://groups.google.com/group/jquery-dev/browse_thread/thread/db8554d10e2c1899#
>
> > > Okay, we get it. Can we move on?
> > No, I don't think you do get it.
>
> Could you be more vague?
Could you be more blind? But that's an insult to blind people. The
first of the above linked examples is titled:-
"attr() is still very broken in 1.4a1" (By Matt Kruse)
...and this was two years since the original "argument" (here) between
you, me and Resig. It couldn't be a more critical issue. Of course,
your main concern seems to be PR at this point. ;)
David Mark
> On Dec 30, 2:59 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > ISTM that Matt Kruse
> > has been saying for years that there's nothing wrong with jQuery.
>
> If you check the archives, I believe you will find just the opposite.
Hardly. First there was no browser sniffing, then voila! there was
tons of it (and you raced off to tell Resig why this was bad). Then
there were no "major bugs", no problems with attributes or queries,
etc. If I didn't tell you what to tell them, they'd be worse off than
they are now (hard to imagine).
From the fall of 2007:-
Ever since, every time I point out another flaw in your "argument" for
jQuery (and things like it), you assert that "nobody would do that" or
it's an "edge case" or "I never had a problem like that". It's all
bullshit and you know it.
It's a 60K (approx.) blob of JS that you have been stuck with for
years because you made a terrible decision to use it in the first
place. As you have admitted, you are now _stuck_ with some old
version (one that uses UA sniffing) because there's just no way to
upgrade the thing without breaking your apps. You should rightfully
be out on the street for such buffoonery. Even if you are self-
employed, you should throw yourself out. :)
>
> Rather, I think I realize its flaws yet still acknowledge its value
> and position in the world of browser scripting.
And for that you look like a deluded jackass. Apparently I can't help
you recognize that.
David Mark
Oh, and it appears that position is slipping fast:-
http://groups.google.com/group/jquery-en/about
...the nosedive trend seems to coincide with the release of IE8. What
a remarkable coincidence. ;)
S.T.
> Oh, and it appears that position is slipping fast:-
>
> http://groups.google.com/group/jquery-en/about
>
> ...the nosedive trend seems to coincide with the release of IE8. What
> a remarkable coincidence. ;)
Matt Kruse
> I haven't latched on to any specific issue.
> And there couldn't be anything less useful than DOM libraries/
> frameworks that can't even _read_ documents.
Well, there you go. See?
> Do you not understand that everything is built on top of documents and
> attributes?
Clearly, not everything, as I have never had issues with jQuery
accessing attributes.
> What in the hell are you talking about? You should see the result map
> for jQuery, YUI, etc. They are more red than green in anything but
> the very latest browsers in standards mode. Great leveler those are.
Because your tests focus on the problems. If your tests covered all
attributes and every situation you could dream up, the reds would be a
very small percentage of the total. The fact that they exist means
something should be fixed, but you're over-dramatic about it.
> > nor justification for throwing out
> > libraries entirely or declaring their authors inept.
> 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. 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?
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. If you
measured all devices and solutions by the same stringent requirement
of perfection that you expect of js libraries, you would surely be
living without any technology at all, for it is _all_ flawed in a
similar manner.
And this is the real nature of the disagreement all along - I
acknowledge your technical criticisms of these libraries. However, you
think these problems are their achilles heel and should prove them
unworthy of any use, while I accept the flaws as an unavoidable by-
product of progress and move forward in spite of them. This really
isn't much of a technical discussion at all (the flaws are quite
demonstratable) but more a philosophical one.
> That makes no sense at all. Why is it that my code and ideas always
> end up (in some form) in jQuery, Prototype, etc.
Because you imagine it to be so? It's not like you are the only person
in the world capable of coming up with ideas and code similar to your
own.
> You want publicity for whatever
> bullshit you are doing these days. ;)
Yes! Definitely, for all that stuff that I am doing. All of it. And
wow, let me tell you, there's a lot of it. So I need a lot of
publicity. For all the bullshit.
> > He's said he's writing
> > a book about this stuff,
> I am and several samples have already been posted (and appear to be
> quite popular, thank you very much!)
Writing a book is a good thing. Being clear about your motivation for
all this criticism is important.
> > Nothing can be so amusingly arrogant as a young man who has just
> > discovered an old idea and thinks it is his own.
> > -- Sidney J. Harris
> Now that sounds like Resig and the rest.
Certainly, and "the rest" surely includes most people in these
discussions as well.
Matt Kruse
David Mark
Whatever you think that says, it only represents the sordid past (and
what do you think I have been complaining about?) But the future is
not bright for jQuery at all. Maybe if Resig had been paying
attention instead of hiding all these years...
Matt Kruse
Indeed, if you chart the # of posts in a graph (assuming you even
accept the theory that # of posts is an indicator of use) it doesn't
look like there is a nose-dive at all. Empirical evidence points to
the same conclusion for me. *shrug*
Matt Kruse
David Mark
> On Dec 30, 2:57 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > I haven't latched on to any specific issue.
> > ...
> > And there couldn't be anything less useful than DOM libraries/
> > frameworks that can't even _read_ documents.
>
> Well, there you go. See?
No. As you well know, there are at least a hundred others, starting
with browser sniffing. Go back and read my reviews over the years as
you seem to have focused on just one issue. ;)
>
> > Do you not understand that everything is built on top of documents and
> > attributes?
>
> Clearly, not everything, as I have never had issues with jQuery
> accessing attributes.
There you go again. It doesn't matter what problems you and your
v1.2x preserve have run into. As you are using a UA-sniffing version
in an IE6-only environment (!), you really have no idea what issues
are present.
>
> > What in the hell are you talking about? You should see the result map
> > for jQuery, YUI, etc. They are more red than green in anything but
> > the very latest browsers in standards mode. Great leveler those are.
>
> Because your tests focus on the problems.
Certainly not.
> If your tests covered all
> attributes and every situation you could dream up, the reds would be a
> very small percentage of the total.
It doesn't get much more comprehensive than this:-
http://www.cinsoft.net/attributes.html
...and I have a similar one for queries that will be posted early in
the new year. It's just as comprehensive and jQuery's plot has more
than a spatter of red (and the freckles change position on clicking
the Compatibility Mode button in IE8). So they aren't even close in
the _latest_ version of IE.
Also, if you had an ounce of competence, you could predict the results
as I've already shown you the (one line of) code that throws
everything off.
> The fact that they exist means
> something should be fixed, but you're over-dramatic about it.
Don't be naive. Lots of things need to be fixed and you've tried to
convince them to do so. Years have gone by and nothing has changed.
They don't _understand_ the problems and their "reasoning" is always
very child-like. What are you clinging to?
And what if they did suddenly fix the most basic problems? How would
that help all of the sites and apps built with older versions? Are
they all to re-download the stupid thing and re-test everything? That
wasn't the deal, was it?
How much work did they have to do to make the thing work with IE8?
Seemed like an epic struggle to me. In contrast, I didn't lift a
finger to change My Library (or even bother to test it with IE8 until
six months later). Unsurprisingly, it all worked (yes, even the
attribute-based queries). That's how cross-browser scripting is
_supposed_ to work. It's "write once, do nothing" when done right.
Downloading a new set of misconceptions from Resig and co. every six
months is the antithesis. And you realize that his attribute queries
(among many other things) are completely fucked up _to this day_, with
no hope in sight of a resolution? So even if you downloaded it
_yesterday_, you are still waiting for him to wake up and solve
problems that should never have existed in the first place (IE6 came
out last century after all).
>
> > > nor justification for throwing out
> > > libraries entirely or declaring their authors inept.
> > 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.
Oh shut up. I'm tired of you changing the subject to _me_. That's a
loser's resigned stance.
>
> On the contrary, the web is fine and there are a few problems.
Oh brother. What does that even mean?
> This is
> the nature of any evolutionary, iterative process.
No, fucking up trivial little scripts for years is not some noble
scientific pursuit. It's just plain fucking up (and on a huge scale
as JS has grown in popularity due to the Ajax hysteria).
> Very few things
> have the luxury of being designed from scratch by experts.
I could write that miserable script from scratch every weekend if I
wanted to. Hell, I wrote a much better one in a weekend and it is
still standing.
http://www.cinsoft.net/mylib.html
And I'm certainly not alone in this ability. Why do we need a million
monkeys on this case?
> 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.
Big ideas?! Like browser sniffing? And whose ideas replaced those
for most of these scripts?
I've said this before, but you are a blithering fucking idiot.
There's just not much else to say at this point. How many years are
you going to keep your head in the sand? If you can't see reality,
reality can't see you?
>
> Is not the hardware you are probably using right now built on top of
> short-sighted ideas, flawed designs, hacks, etc?
Off in the weeds again. There's no parallel between jQuery and PC's.
There is a parallel between jQuery and the collected works of Ed Wood.
[snip rambling about PC's]
>
> 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.
jQuery was like "inventing" an eight-track player a decade after CD's
came out (and then bitching about critics for years while slowly,
painfully changing the design until it actually is a CD player). But
this ain't about entertainment is it? ;)
> If you
> measured all devices and solutions by the same stringent requirement
> of perfection that you expect of js libraries, you would surely be
> living without any technology at all, for it is _all_ flawed in a
> similar manner.
No, stupid. This is about software. There are very definite
parameters for success. jQuery is an abject failure, even as a
hobbyist creation.
>
> And this is the real nature of the disagreement all along - I
> acknowledge your technical criticisms of these libraries.
Only after I beat you over the head with them for months and years.
You can't go back in time and change history.
> However, you
> think these problems are their achilles heel and should prove them
> unworthy of any use, while I accept the flaws as an unavoidable by-
> product of progress and move forward in spite of them.
See above (the blithering idiot comment).
> This really
> isn't much of a technical discussion at all (the flaws are quite
> demonstratable) but more a philosophical one.
It's more like one person banging their head against the same wall for
years while rational observers try to talk them out of it. At this
point, I say knock yourself out. ;)
>
> > That makes no sense at all. Why is it that my code and ideas always
> > end up (in some form) in jQuery, Prototype, etc.
>
> Because you imagine it to be so?
You are such a disingenuous ass. You _know_ it to be so. You've been
the proxy numerous times.
> It's not like you are the only person
> in the world capable of coming up with ideas and code similar to your
> own.
Don't be an ass. There are plenty of examples where the cites lead
back to me (and many more where ideas were obviously appropriated
without permission). It's all a matter of public record. Start with
the browser sniffing and all of the various feature testing (and
attempts at it) that replaced it in jQuery (and others). Now who beat
those ideas into the public consciousness for _years_ to make that
happen?
>
> > You want publicity for whatever
> > bullshit you are doing these days. ;)
>
> Yes! Definitely, for all that stuff that I am doing. All of it. And
> wow, let me tell you, there's a lot of it. So I need a lot of
> publicity. For all the bullshit.
Do you have to blither so? It gives me a headache. :(
>
> > > He's said he's writing
> > > a book about this stuff,
> > I am and several samples have already been posted (and appear to be
> > quite popular, thank you very much!)
>
> Writing a book is a good thing. Being clear about your motivation for
> all this criticism is important.
Again. The criticism and resulting change in attitudes started long
before the book project. So what are you saying? It's all been a big
conspiracy to sell some stupid book? Hint: there's no real money in
books (that's one reason mine is overdue).
>
> > > Nothing can be so amusingly arrogant as a young man who has just
> > > discovered an old idea and thinks it is his own.
> > > -- Sidney J. Harris
> > Now that sounds like Resig and the rest.
>
> Certainly, and "the rest" surely includes most people in these
> discussions as well.
>
What are you talking about?
Andrew Poulos
Are the charts on that page showing anything real? For example, in the
'Distribution of the top web technologies' there's no mention of Dojo or
ExtJS. Surely Dojo or ExtJS would be as big, if not bigger than,
prototype, scriptaculous, or mootools?
Andrew Poulos
David Mark
> On Dec 30, 4:01 pm, "S.T." <a...@anon.com> wrote:
>
> > On 12/30/2009 1:55 PM, David Mark wrote:
> > > Oh, and it appears that position is slipping fast:-
> > >http://groups.google.com/group/jquery-en/about
> > > ...the nosedive trend seems to coincide with the release of IE8. What
> > > a remarkable coincidence. ;)
> >http://trends.builtwith.com/javascript/JQuery
>
> Indeed, if you chart the # of posts in a graph (assuming you even
> accept the theory that # of posts is an indicator of use)
That was always your theory, genius. Well, until the slide started.
Now it's nonsense I guess. I say it makes sense that the more rubes
out there trying to use jQuery, the more questions will be posted (and
unanswered of course).
> it doesn't
> look like there is a nose-dive at all.
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?
> Empirical evidence points to
> the same conclusion for me. *shrug*
What does that mean?
David Mark
> On 31/12/2009 9:15 AM, Matt Kruse wrote:
>
> > On Dec 30, 4:01 pm, "S.T."<a...@anon.com> wrote:
> >> On 12/30/2009 1:55 PM, David Mark wrote:
> >>> Oh, and it appears that position is slipping fast:-
> >>>http://groups.google.com/group/jquery-en/about
> >>> ...the nosedive trend seems to coincide with the release of IE8. What
> >>> a remarkable coincidence. ;)
> >>http://trends.builtwith.com/javascript/JQuery
>
> > Indeed, if you chart the # of posts in a graph (assuming you even
> > accept the theory that # of posts is an indicator of use) it doesn't
> > look like there is a nose-dive at all. Empirical evidence points to
> > the same conclusion for me. *shrug*
>
> Are the charts on that page showing anything real?
Almost certainly not.
> For example, in the
> 'Distribution of the top web technologies' there's no mention of Dojo or
> ExtJS. Surely Dojo or ExtJS would be as big, if not bigger than,
> prototype, scriptaculous, or mootools?
To be fair, you don't see those two much on the public Web. But I
would expect at least a blip for each. Whatever.
And I contend that jQueery, Cowtools, Prototripe, FUI, etc. are more
public blunders than technologies. Yeah, we've got a little pet name
for everybody. ;)
S.T.
> Are the charts on that page showing anything real? For example, in the
> 'Distribution of the top web technologies' there's no mention of Dojo or
> ExtJS. Surely Dojo or ExtJS would be as big, if not bigger than,
> prototype, scriptaculous, or mootools?
http://trends.builtwith.com/javascript/Ext-JS
http://trends.builtwith.com/javascript/Dojo-Toolkit
There are no perfect web analytics but there methodology seems
reasonable. Spider a couple pages on a couple million domains on a
regular basis looking for a presest list of libraries, MIME types, etc.
and log the results.
S.T.
>>> On 12/30/2009 1:55 PM, David Mark wrote:
>>>> Oh, and it appears that position is slipping fast:-
>>>> http://groups.google.com/group/jquery-en/about
>>>> ...the nosedive trend seems to coincide with the release of IE8. What
>>>> a remarkable coincidence.
...
> That was always your theory, genius. Well, until the slide started.
> Now it's nonsense I guess. I say it makes sense that the more rubes
> out there trying to use jQuery, the more questions will be posted (and
> unanswered of course).
Your contention is that when IE8 came out, there were such problems with
jQuery that the support forum... began to dry up? Does that make any sense?
Guessing fluctuations are more related to jQuery admin concluding Google
Groups is an awful support forum at 20K+ subscribers and beginning to
look elsewhere:
http://ejohn.org/blog/google-groups-is-dead/
... along with typical yearly trends:
http://www.google.com/trends?q=jquery&ctab=0&geo=all&date=all&sort=0
David Mark
[...]
>
> Because you imagine it to be so? It's not like you are the only person
> in the world capable of coming up with ideas and code similar to your
> own.
* isOwnProperty, isHostMethod, etc. (nod to Thomas on the latter)
* Detecting broken attribute implementations (e.g. MSHTML)
Remember Resig's question about a "magic flag" for attributes? I
do. ;)
http://groups.google.com/group/comp.lang.javascript/msg/56d22b30b168fbb5
A salient quote:-
"Error-prone? Doubtful. Where's your test suite-backed attribute/css
manipulation code, I'd love to see it!"
And before anyone chimes in about "helping out" (I'm the devil and
thank God for people like Matt Kruse). I gave him (Resig) the answer
later in that very thread. But he doesn't seem to understand
abstractions; he wants pictures. Then again, the pictures didn't help
either. :)
http://www.cinsoft.net/attributes.html
Here's another quote from him in that same thread:-
"Yawwwwnnnnn.... this is, quite possibly, the most inane set of
ramblings set up by someone who has obviously never created a
JavaScript library of any kind, nor has used JavaScript code in any
sort of production environment."
Yeah, the primary topics of those "ramblings" were that his browser
sniffing was unnecessary and error-prone (as he announced almost
exactly a year later) and that he was mixed up about attributes and
properties (never figured that one out).
* Detecting supported events (e.g. how do I know if mouseenter is
supported)
http://perfectionkills.com/detecting-event-support-without-browser-sniffing/
* Detecting proprietary styles (e.g. How do I set opacity cross-
browser?)
* The inject-and-detect pattern (mangled a year later by Resig as
"detect-and-inject")
I came up with those last two and Peter helped to refine them. Of
course, both of those ideas can be traced back further to Richard
Cornford. I don't think I've made any secret of the fact that his
ideas have influenced mine.
http://peter.michaux.ca/articles/feature-detection-state-of-the-art-browser-scripting
http://peter.michaux.ca/articles/cross-browser-widgets
And then there is the CWR project, which was discussed endlessly
here. I estimate I wrote 98% of _that_ code (and certainly influenced
the other 2).
* Virtually anything to do with the "unknown" properties in MSHTML ;)
Who else even knew about those, let alone made the connection to the
IUnknown interface? Every time I brought those up in here, it was
"what are you talking about?" And I mean even in the last year or
so. Perhaps that explanation should be in the FAQ as I have to repeat
it so often.
* Dynamic API to simplify feature detection
It seems like that last one is taking _forever_ to percolate. It
should be patently obvious that you can't abstract an unknown
environment with a static set of methods. Most inventions are simple
(sometimes too simple to recognize). ;)
Unfortunately, rubes like you like to chime in with "Maybe that's what
people are more comfortable with". Well, it's completely _impossible_
to do progressive enhancement (supposedly jQuery's reason for being)
that way. Think.
Example using My Library:-
if (Q.prototype.fadeIn) { // Obscure DOM tests behind the scenes
// Cool fading enhancement here
}
Now what would that look like in jQuery or any of the others? Like
this:-
// Cool fading enhancement here come hell or high water
...which is nothing but progressive destruction. That's why they keep
"raising the bar" for browsers (e.g. only supporting the very latest
versions). They are living in 2001 and the sequel is about to
hit. :)
Want to know what the future holds for JS libraries? Just follow my
posts. ;)
The last word on attributes:-
http://www.cinsoft.net/attributes.html
The last word on viewport measurement:-
http://www.cinsoft.net/viewport.asp
Further last words on keyboard monitoring and other hot topics coming
soon to a Website (and book) near you. Be sure to tell Resig to tune
in for the lesson on box models. :)
The epitaph for jQuery and the like:-
http://www.cinsoft.net/queries.html
And, of course, the mother of all JS libraries, which has been aped
endlessly:-
http://www.cinsoft.net/mylib.html
If I left anything out, it's likely in there. :)
David Mark
> On 12/30/2009 2:57 PM, Andrew Poulos wrote:
>
> > Are the charts on that page showing anything real? For example, in the
> > 'Distribution of the top web technologies' there's no mention of Dojo or
> > ExtJS. Surely Dojo or ExtJS would be as big, if not bigger than,
> > prototype, scriptaculous, or mootools?
>
>
> There are no perfect web analytics but there methodology seems
> reasonable.
What methodology, S.T.?
> Spider a couple pages on a couple million domains on a
> regular basis looking for a presest list of libraries, MIME types, etc.
> and log the results.
Oh, that methodology. :)
David Mark
> On 12/30/2009 3:37 PM, David Mark wrote:
>
> >>> On 12/30/2009 1:55 PM, David Mark wrote:
> >>>> Oh, and it appears that position is slipping fast:-
> >>>>http://groups.google.com/group/jquery-en/about
> >>>> ...the nosedive trend seems to coincide with the release of IE8. What
> >>>> a remarkable coincidence.
>
> ...
>
> > That was always your theory, genius. Well, until the slide started.
> > Now it's nonsense I guess. I say it makes sense that the more rubes
> > out there trying to use jQuery, the more questions will be posted (and
> > unanswered of course).
>
> Your contention is that when IE8 came out, there were such problems with
> jQuery that the support forum... began to dry up? Does that make any sense?
For one, it's not exactly a support forum (they have one of those
too). For two, there's no way in hell that IE8's arrival caused
anything good to happen for those who had staked their careers on
jQuery. Seems there are a lot fewer of them around these days. I
don't need GG to tell me that. ;)
>
> Guessing fluctuations are more related to jQuery admin concluding Google
> Groups is an awful support forum at 20K+ subscribers and beginning to
> look elsewhere:http://ejohn.org/blog/google-groups-is-dead/
The number of people who clicked the "subscribe" button in the past is
irrelevant. It doesn't mean they read (or even receive) messages from
the group. And that rant from Resig sounds like an excuse for the
decline in participation.
>
> ... along with typical yearly trends:http://www.google.com/trends?q=jquery&ctab=0&geo=all&date=all&sort=0
Posting a graph without drawing conclusions is pretty useless. What
are you trying to say? For example, one trend is that a lot of people
are reading articles critical of jQuery. ;)
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
> On Dec 30, 3:00 am, Andrew Poulos <ap_p...@hotmail.com> wrote:
>
> > How about, instead of making emotional comments about the person, trying
> > to refute some of the many factual points that are raised.
>
> 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%28VS.85%29.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%28VS.85%29.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:
> > On Dec 30, 3:00 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> >> David Mark wrote:
> >>> On Dec 29, 9:58 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> >>>> David Mark wrote:
> >>>>> On Dec 29, 7:52 pm, Garrett Smith <dhtmlkitc...@gmail.com> 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. ;)
> // ...
>
>
>
> })();
> >> if(target && target.checked && target.name === "number") {
> >> alert(target.value);
> >> }
> >> }
> >> </script>
>
> >> I would not add a global "documentClickHandler" function. I would also
> >> not add the callback that way. Instead, I would use an event registry.
> >> For example:-
>
> >> EventPublisher.add(document, "onclick", documentClickHandler);
>
> > Or just use addEventListener/attachEvent. ;) And why do you have to
> > pass "onclick"? ISTM that "click" would suffice (as in My Library):-
>
> 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.
>
> > API.attachDocumentListener('click', documentClickHandler);
>
> > And if you act now, I'll throw in:-
>
> > D(document).on('click', documentClickHandler);
>
> 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.
>
> > ...you just pay the extra shipping and handling.
>
> >> The reason for using EventPublisher for that is to avoid potential
> >> conflict with other script that uses document.onclick.
>
> > I think this example is getting a little too APE-centric. :)
>
> 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
> On Dec 30, 2:57 pm, David Mark <dmark.cins...@gmail.com> wrote:
>> I haven't latched on to any specific issue.
>
>>> nor justification for throwing out
>>> libraries entirely or declaring their authors inept.
>> 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.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
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
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
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.
>> 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. ;)
>
It minifies well and it improves performance, especially in Chrome.
>> // ...
>>
>>
>>
>> })();
>>>> if(target && target.checked && target.name === "number") {
>>>> alert(target.value);
>>>> }
>>>> }
>>>> </script>
>>>> I would not add a global "documentClickHandler" function. I would also
>>>> not add the callback that way. Instead, I would use an event registry.
>>>> For example:-
>>>> EventPublisher.add(document, "onclick", documentClickHandler);
>>> Or just use addEventListener/attachEvent. ;) And why do you have to
>>> pass "onclick"? ISTM that "click" would suffice (as in My Library):-
>> 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.
>
What layer is missing?
>> 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.
>
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.
>> 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. :)
>
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.
>> 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).
>
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.
>> 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.
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.
>
>> 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.
>
What interdependencies do you see there?
>> 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?
>
What higher level abstractions do you see?
>> 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.
>
An object that publishes a message "I'm done" and manages its internals
reduces coupling.
[...]
>
>> 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?
>>> API.attachDocumentListener('click', documentClickHandler);
>>> And if you act now, I'll throw in:-
>>> D(document).on('click', documentClickHandler);
>> 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. :)
>
It isn't necessarily a silly endeavor. Abstractions are useful and
defining and organizing them is a real challenge.
>> 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.
>
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.
>>> ...you just pay the extra shipping and handling.
>>>> The reason for using EventPublisher for that is to avoid potential
>>>> conflict with other script that uses document.onclick.
>>> I think this example is getting a little too APE-centric. :)
>> 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;
> }
>
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
>> 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?
>
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.
>> 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?
>
Nothing.
Garrett Smith
> David Mark wrote:
>> On Dec 30, 4:54 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>>> David Mark wrote:
>>>> On Dec 30, 3:00 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>>>>> David Mark wrote:
>>>>>> On Dec 29, 9:58 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>>>>>>> David Mark wrote:
>>>>>>>> On Dec 29, 7:52 pm, Garrett Smith <dhtmlkitc...@gmail.com> 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
> On Dec 30, 6:37 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Dec 30, 5:15 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> >> it doesn't look like there is a nose-dive at all.
>
> > 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
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.
>
> >> 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. ;)
>
> 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).
>
>
>
> >> // ...
>
> >> })();
> >>>> if(target && target.checked && target.name === "number") {
> >>>> alert(target.value);
> >>>> }
> >>>> }
> >>>> </script>
> >>>> I would not add a global "documentClickHandler" function. I would also
> >>>> not add the callback that way. Instead, I would use an event registry.
> >>>> For example:-
> >>>> EventPublisher.add(document, "onclick", documentClickHandler);
> >>> Or just use addEventListener/attachEvent. ;) And why do you have to
> >>> pass "onclick"? ISTM that "click" would suffice (as in My Library):-
> >> 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.
>
> What layer is missing?
See further down. It's fine. I just didn't care to go back and
rewrite my comments.
>
> >> 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.
>
> 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?
>
> >> 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. :)
>
> 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. Fuck 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). ;)
>
> >> 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).
>
> 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.
>
> >> 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.
>
> 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
>
>
>
> > 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.
>
> What interdependencies do you see there?
See below. It seems that you have it right, though I am a bit
confused at this point.
>
> >> 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?
>
> What higher level abstractions do you see?
>
> >> 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.
>
> 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.
>
> [...]
>
>
>
> >> 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.
>
> >>> API.attachDocumentListener('click', documentClickHandler);
> >>> And if you act now, I'll throw in:-
> >>> D(document).on('click', documentClickHandler);
> >> 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. :)
>
> 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. ;)
>
> >> 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.
>
> 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).
>
>
>
> >>> ...you just pay the extra shipping and handling.
> >>>> The reason for using EventPublisher for that is to avoid potential
> >>>> conflict with other script that uses document.onclick.
> >>> I think this example is getting a little too APE-centric. :)
> >> 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;
> > }
>
> 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
No idea. Haven't looked at those in ages.
>
> >> 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?
>
> 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
> Matt Kruse <m...@thekrusefamily.com> writes:
> > On Dec 30, 3:00 am, Andrew Poulos <ap_p...@hotmail.com> wrote:
> >> How about, instead of making emotional comments about the person, trying
> >> to refute some of the many factual points that are raised.
>
> > 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."
>
>
> 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
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.
[...]
>
>>>> 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. ;)
>> It minifies well and it improves performance, especially in Chrome.
>
> 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?
>
>> Where do you draw the line with
>> browser bugs? EventPublisher doesn't do any of that.
>
> Any of what?
>
Browser bugs/issues. EventPublisher doesn't know about any quirks of
events, bubbling. NOne of that.
>>>> 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. :)
>> 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.
>
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.
Supercilious comments such as "lets be pragmatic" or "lets try and just
get it done" turn a blind eye to a problem.
>> 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). ;)
>
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 fuck 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.
>>>> 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).
>> 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.
>
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.
>>>> 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.
>> EventPublisher doesn't have anything to do with the DOM.
>
> 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.
[...]
>>> 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.
>
> 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.
[...]
>> read more �
>
> 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.
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 fuck 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).
>
> >>>> 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).
> >> 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.
>
> 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.
>
> >>>> 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.
> >> EventPublisher doesn't have anything to do with the DOM.
>
> > 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.
I get it.
> [...]
>
> >>> 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.
>
> > 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.
I see.
>
> [...]
>
> >> read more �
>
> > 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
> On Dec 29, 7:52 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> David Mark wrote:
[...]
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
> David Mark wrote:
>> On Dec 29, 7:52 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> David Mark wrote:
>
> [...]
>
> 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
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
> On Dec 31, 10:35 am, ScottSauyet<scott.sau...@gmail.com> wrote:
> "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
Hans-Georg Michna
>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();
> }
> };
David,
are you sure that readyState doesn't become "complete" some time
before window.onload fires? 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.
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.
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.
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?
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. (:-)
Hans-Georg
David Mark
georgNoEmailPle...@michna.com> wrote:
> On Tue, 29 Dec 2009 17:44:09 -0800 (PST), David Mark wrote:
> >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();
> > }
> > };
>
> 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
> On Dec 31 2009, 6:09 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Dec 31, 10:35 am, ScottSauyet<scott.sau...@gmail.com> wrote:
> > "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?
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. ;)
Diego Perini
> On Jan 1, 3:04 pm, Hans-Georg Michna <hans-
>
>
>
> georgNoEmailPle...@michna.com> wrote:
> > On Tue, 29 Dec 2009 17:44:09 -0800 (PST), David Mark wrote:
> > >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();
> > > }
> > > };
>
> > David,
>
> > are you sure that readyState doesn't become "complete" some time
> > before window.onload fires?
>
> In IE? Absolutely.
>
In IE the "onreadystatechange" event, notifying "complete" state, is
reached before "onload" even if the page has already being cached,
sometime just few milliseconds but enough for the objective of
IEContentLoaded. There are tests showing that bit. Read the
accompanying instructions and vendor reference before using it
http://javascript.nwbox.com/IEContentLoaded .
David Mark
> On 1 Gen, 21:15, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
> > On Jan 1, 3:04 pm, Hans-Georg Michna <hans-
>
> > georgNoEmailPle...@michna.com> wrote:
> > > On Tue, 29 Dec 2009 17:44:09 -0800 (PST), David Mark wrote:
> > > >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();
> > > > }
> > > > };
>
> > > David,
>
> > > are you sure that readyState doesn't become "complete" some time
> > > before window.onload fires?
>
> > In IE? Absolutely.
>
> In IE the "onreadystatechange" event, notifying "complete" state, is
> reached before "onload" even if the page has already being cached,
> sometime just few milliseconds but enough for the objective of
> IEContentLoaded.
No, a few milliseconds is worthless for the purpose of simulating
DOMContentLoaded (obviously). That's why you have the doScroll hack
in there. BTW, I hope you read my review of _that_ "logic".
Diego Perini
It is not worthless, it accomplish the required task: fire before
"onload". Nobody needs timing there, just need to ensure they can get
ALL the nodes they need at that point without risking (query the
document) !
Yes, that's why I use the "doScroll" which is needed to fire much
early if possible. If not then the "complete" state is used as a fall
back notification. And contrary to what you said it is documented in
the Microsoft references I link to (true or not).
David Mark
That's not what people are looking for in a script like this. They
want something to fire when the DOM is ready, which could be seconds
(or even minutes) before the load event fires.
> Nobody needs timing there, just need to ensure they can get
> ALL the nodes they need at that point without risking (query the
> document) !
You might as well use the load event then. ;)
<body onload="...">
Or, if you must look foolish and behind the times, you can go the
"Unobtrusive" (bunk) route:-
window.onload = function() { ... };
>
> Yes, that's why I use the "doScroll" which is needed to fire much
> early if possible.
And you can't see the problem with that? Please read my review and
recall that ill-conceived code immediately. You are giving the
library lemmings more bad ideas (and they weren't exactly in short
supply).
> If not then the "complete" state is used as a fall
> back notification.
Which is tantamount to using onload in IE. Sorry, but there's nothing
new here.
> And contrary to what you said it is documented in
> the Microsoft references I link to (true or not).
What is documented where?
Hans-Georg Michna
>Your crusade against libraries is well past the boring stage. Ramble
>about something else that might actually be interesting to read.
>
>Here ya go:
>http://www.nczonline.net/blog/2009/12/29/feature-detection-is-not-browser-detection/
>
>Makes sense to me. Well articulated. Points out flaws of some libraries
>(JACKPOT!!!!) but manages to be informative at the same time. ...
Hey, if even a newcomer like me finds the article boring, then
you shouldn't be so sure.
The only few tidbits I found interesting were in the comments,
not in the article itself.
Hans-Georg
Hans-Georg Michna
>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.
That still leaves a niche for jQuery---it allows to write quite
a few operations in short, nice-to-look-at, easy-to-understand,
functional code.
That code may not be very efficient, but in many cases it is
still nicer than raw JavaScript.
As long as this is so, many newcomers and even intermediate
coders will flock to jQuery, no matter how many problems they
may (or in many simple cases may not) incur.
I think you should write a plug-compatible replacement for
jQuery. The $ object should make this very easy. Use those parts
of the API that make sense in jQuery, keep the rest for
compatibility, and add your own parts, like .att(), .prop(),
whatever you think is better.
This would make for interesting times, because then people could
instantly test jQuery against the new competition.
I don't think the API can be protected with copyright, but if
there are any problems here, you could use a fundamentally
different one to start with and leave the $ replacement to the
user.
Good new project for 2010?
Hans-Georg
Diego Perini
Right, "doScroll" can fire seconds or even minutes before "onload".
I was looking exactly for what I wrote, I can't really say what other
needs really, but I assumed they probably needed the same thing. If
they don't get any help from it they can avoid using it.
> > Nobody needs timing there, just need to ensure they can get
> > ALL the nodes they need at that point without risking (query the
> > document) !
>
No because then I cannot the snippet will notify BEFORE "onload", I
would need to change the wording and say "you will be notified at
onload" which as you said already exists, I am currently saying that I
give them a chance to do something before that precise moment...
Maybe hard to understand but that is what I have seen people use it
for, and I have not being given proof of it failing by users up to
now. If you have a test showing it fails I would surely agree with
you.
> You might as well use the load event then. ;)
>
> <body onload="...">
>
Already said that, I want to precede the above handler, and in a cross-
browser moment !
> Or, if you must look foolish and behind the times, you can go the
> "Unobtrusive" (bunk) route:-
>
> window.onload = function() { ... };
>
>
Really, if you know this stuff you perfectly understand there is no
need of waiting an "onload" event either for most things. You can
append elements to body much before the "onload" event. In every
browser that I tested.
IEContentLoaded/DOMContentLoaded serves for a different purpose, they
are needed just to ensure your queries will be executed when all
elements are available. If you used NWEvents delegation you will have
no need for that either. ;-) It doesn't matter how it is used in other
libraries, my scope was clear before the many attempt and test I did
and is clearly written in the few notes.
>
> > Yes, that's why I use the "doScroll" which is needed to fire much
> > early if possible.
>
> And you can't see the problem with that? Please read my review and
> recall that ill-conceived code immediately. You are giving the
> library lemmings more bad ideas (and they weren't exactly in short
> supply).
>
> > If not then the "complete" state is used as a fall
> > back notification.
>
> Which is tantamount to using onload in IE. Sorry, but there's nothing
> new here.
>
I repeat, if you want to ensure users to have a chance to precede
<body onload="..."> or "window.onload =" events on IE browsers I have
found a way to ensure that, if not you don't need it.
> > And contrary to what you said it is documented in
> > the Microsoft references I link to (true or not).
>
> What is documented where?
That "doScroll" behavior is documented here:
http://msdn.microsoft.com/en-us/library/ms531426(VS.85).aspx
these info were already in the link I sent you above. Please read !
I am sure you can easily run the static/dynamic test found in the
original project site.
Hans-Georg Michna
>On Jan 1, 3:04�pm, Hans-Georg Michna <hans-
>georgNoEmailPle...@michna.com> wrote:
>> 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.
Ah, I should have tested. Anyway, thanks for saving me the work.
So you are saying that, when JavaScript code makes a change to
the DOM, the document.readyState changes back from "complete" to
"interactive", then again to "complete"?
>> 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?
Interesting that the DOM already "knows" the height, before it
is actually rendered to screen. I guess that is what you meant.
It could also mean that we have no way to tell when the screen
rendering is complete. Is that so?
My original intention was merely to let some JavaScript code be
able to read the entire DOM and make changes to it as early as
possible. The bad solution would be to wait until all auxiliary
files, like images, are loaded. I was hoping that
document.readyState === "complete" would help me there. But
apparently that is not the case, or not much, anyway.
My second intention is to learn. I'm still somewhat new to
JavaScript, but find it both useful and quite interesting.
Hans-Georg
jdalton
Please read ( http://groups.google.com/group/comp.lang.javascript/msg/db3f64d3edb78a2d
)
for some issues I had with your "IEContentLoaded" review.
It got lost in between some other rather long replies.
http://groups.google.com/group/comp.lang.javascript/msg/db3f64d3edb78a2d
Thanks,
-JDD
David Mark
georgNoEmailPle...@michna.com> wrote:
> On Wed, 30 Dec 2009 20:50:09 -0800 (PST), David Mark wrote:
> >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.
>
> That still leaves a niche for jQuery---it allows to write quite
> a few operations in short, nice-to-look-at, easy-to-understand,
> functional code.
It is neither nice-to-look-at, nor easy-to-understand. Look at any
non-trivial app and it reads like alphabet soup.
>
> That code may not be very efficient, but in many cases it is
> still nicer than raw JavaScript.
Nicer? And it is still _calling_ tons of complex "raw JavaScript".
What does the neophyte do when something goes wrong? The usual
strategy is to "upgrade" the whole interdependent mess, effectively
setting testing back to ground zero. It's a mad strategy (and doomed
to fail).
>
> As long as this is so, many newcomers and even intermediate
> coders will flock to jQuery, no matter how many problems they
> may (or in many simple cases may not) incur.
Even the simplest jQuery scripts are susceptible to problems.
Virtually every "simple" example out there uses the attr method, which
even the jQuery authors don't understand. The problem is that
newcomers typically test in a few browsers and declare their scripts
working in "all browsers". Also madness.
>
> I think you should write a plug-compatible replacement for
> jQuery.
A what?
http://www.cinsoft.net/mylib.html
For reference, that is modular where jQuery is monolithic. It makes
it trivial to do progressive enhancement where jQuery makes it
impossible (unless you consider PE to be script or no script). :)
Also, the OO interface is _optional_ allowing for any "face" to be
painted on top of the functional API. And, last but not least, and
most important for business applications, the cost of ownership is
virtually nil (i.e. it doesn't require wholesale changes every few
months to "keep up" with the latest major browsers). It works with
ten-year-old browsers, just as it works with today's. How many jQuery
authors does it take to support IE8? Read their forum(s) and you will
see that it has been a long, slow, agonizing process to get anywhere
near competent results in just that one browser. In contrast, I
didn't do _anything_ to mine, which was written over a year before the
first IE8 Betas showed up. And most ironic of all, I told Resig
himself what the biggest problem would be with IE8 and how he could
avoid it. Here it is in 2010 and that problem is still biting jQuery
users (hard) while the developers struggle to grasp basic DOM
scripting issues (like _reading_ documents).
http://groups.google.com/group/jquery-dev/browse_thread/thread/e020458f8983fb9a#
http://groups.google.com/group/jquery-dev/browse_thread/thread/fe658871a8bff208#
http://groups.google.com/group/jquery-dev/browse_thread/thread/db8554d10e2c1899#
http://groups.google.com/group/jquery-dev/browse_thread/thread/24c57d4a3a862239#
> The $ object should make this very easy.
Mine has that (if you really want it).
http://www.cinsoft.net/mylib-builder.asp
It's an alias for API.getEBCS (get element by CSS selector).
Furthermore, it has the requisite wrapper objects, which are actually
(drum roll please) object-oriented (e.g. you can create new objects
that inherit from them). In contrast, jQuery's single object is just
that. And what an awkward interface it is. Everything is a
collection of nodes, even a single node? :)
> Use those parts
> of the API that make sense in jQuery, keep the rest for
> compatibility, and add your own parts, like .att(), .prop(),
> whatever you think is better.
Way ahead of you. :) My Library, Too is a new project that is much
like My Library, but smaller, faster, friendlier, more efficient and
incorporating browser advances made in the last couple of years (e.g.
CSS transitions, QSA, etc.) The first two methods I added to the
element wrapper objects were attr and prop, from:-
http://www.cinsoft.net/attributes.html
That's the lowest level. There are higher level methods on top of
those, of course. As for the window wrapper, dimensions (and scroll
position) top the list:-
http://www.cinsoft.net/viewport.asp
And there's the new keyboard monitor, built-in event and proprietary
style detection, etc. None of it should come as much of a surprise.
It's pretty much the last word on all of the basic problems that have
been incompetently re-invented over and over by the various "major"
libraries. ;)
>
> This would make for interesting times, because then people could
> instantly test jQuery against the new competition.
jQuery is not a benchmark. And you can already test at least one
aspect of mine (queries) against jQuery and the rest:-
http://www.cinsoft.net/mylib-testspeed.html
Those are all of the pre-QSA versions. Add QSA (about a dozen lines
of code) to My Library and it will trounce all of the latest ones too
(and will actually be _compatible_ for browsers _without_ QSA, which
still must be supported). And watch for a TaskSpeed test page. The
results are quite predictable (mine topsy, jQuery turvy).
Or just go to the builder and click "Test HTML". You can't do (most
of) that with jQuery at all. jQuery doesn't even support multiple box
models, for God's sake (so IE quirks mode is out). ;)
>
> I don't think the API can be protected with copyright, but if
> there are any problems here, you could use a fundamentally
> different one to start with and leave the $ replacement to the
> user.
I wouldn't ape their API. It's a waste of time.
>
> Good new project for 2010?
>
Sort of. :)
David Mark
> On Dec 29, 7:44 pm, David Mark <dmark.cins...@gmail.com> wrote:
> ...
>
> >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.
>
> abovehttp://msdn.microsoft.com/en-us/library/ms531426%28VS.85%29.aspx#Comp...
LOL. That's the reference for C++ developers. You are reaching so
far that you've toppled over. It doesn't mean that the IE developers
_must_ throw an exception.
"Returns S_OK if successful, or an error value otherwise"
That's meaningless in this context. Show me where in the IE
documentation it says that the method will _throw_ that exception to
the calling script (and under what circumstances). ;)
"When the content of an element changes and causes scroll bars to
display, the IHTMLElement2::doScroll method might not work correctly
immediately following the content update."
Does that translate to the IE developers throwing exceptions before
the DOM is safe to manipulate (and never throwing them after). Of
course not. :)
>
> Or this which suggest errors are thrown on properties/methods that
> require the document to be completely parsedhttp://msdn.microsoft.com/en-us/library/ms531426%28VS.85%29.aspx#ctl0...
And just where in that massive (and largely irrelevant) document does
it say that? How about a quote?
>
> Or this implementation which states it may return an errorhttp://msdn.microsoft.com/en-us/library/aa703983(VS.85).aspx
Again. A salient quote?
>
> Or that in reality it's been proven that it throws errors ?
>
> > } catch (e) {
> > setTimeout(arguments.callee, 50);
>
Proven to throw errors _when_ and who says IE9 will do the same
thing? All of you guys seem to have the same narrow mindset. How
many versions/configurations of IE have you tested this on? What does
"proof" mean to you? Nobody ever complained to you personally, so it
must work?
> > 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.
Doesn't really matter what it was intended for. As presented, it will
run in everything. And again, what versions of IE and how do you plan
to target them?
> Implementers mostly likely use browser sniffs,
In 2010? Those were bad enough in 2001.
http://www.jibbering.com/faq/faq_notes/not_browser_detect.html
> feature inference,
Object inferences are another form of browser sniffing. What objects
would indicate that doScroll does what you assert it to do? :)
> or
> feature detection
> to determine if the "doScroll" code should be executed.
Do tell. What feature would you detect?
>
> ...
>
> > 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.
Perhaps a millisecond. So what does that help?
> I believe it fires early on cached loads but I don't have the
> specifics at hand.
As if that matters. :)
>
> > 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.
Thanks for wasting my time. :(
> However there are workarounds for that.
Do tell. Workarounds for a workaround. Browser scripting doesn't
need this sort of shit. Thanks anyway.
jdalton
In the post I originally replied to
http://groups.google.com/group/comp.lang.javascript/msg/c8a115d7d7cf87b4?pli=1
You said there wasn't a "shred of documentation anywhere that
indicates
this method will throw an exception".
I believe I have shown at least a shred that implies erroring.
You can read through them on your own time.
As to your "C++ developers" comment:
I mentioned in my post that the link was for a different
implementation.
As to sniffs / object inference / feature detection:
I wasn't judging their usage rather stating how the code is used by
implementers.
As to the "onreadystate" comment.
You originally wrote "readyState indicates completion at the same time
the load event fires"
I was just letting you know it didn't always fire at the same time (in
fact is fires before).
As to your "As presented, it will run in everything" comment:
If you looked at Diego's code and usage examples you would see that is
not the case.
You also wrote "Why not design with reality in mind?".
In reality this is a working solution for at least IE 6-8.
- JDD
David Mark
>
> You said there wasn't a "shred of documentation anywhere that
> indicates
> this method will throw an exception".
And, unsurprisingly, there isn't.
>
> I believe I have shown at least a shred that implies erroring.
> You can read through them on your own time.
Implies? For whom. What you cited was for C++ programmers (e.g. the
IE browser developers). They can do whatever they want with the
result (including nothing).
>
> As to your "C++ developers" comment:
> I mentioned in my post that the link was for a different
> implementation.
So you posted something irrelevant and mentioned that it was
irrelevant at the same time. Why?
>
> As to sniffs / object inference / feature detection:
> I wasn't judging their usage rather stating how the code is used by
> implementers.
And, doesn't it follow that if you can't implement it without browser
sniffing, it's a dead issue (and has been for ten years?) :)
>
> As to the "onreadystate" comment.
> You originally wrote "readyState indicates completion at the same time
> the load event fires"
That's true, except for nit-picking over a millisecond or two. You
(and everyone else I hope) know what the implications of that
statement are. This is how time gets wasted (going back and forth
over nonsense). Gee, if you count a millisecond then you might have a
technical point, but nobody is keeping score on that front (and you
are just confusing the central issue of DOM readiness).
> I was just letting you know it didn't always fire at the same time (in
> fact is fires before).
Thanks for that. :( Seems more like you want points for something.
>
> As to your "As presented, it will run in everything" comment:
> If you looked at Diego's code and usage examples you would see that is
> not the case.
That's not true. I posted the code I reviewed in its _entirety_.
The IEContentLoaded source code
/*
*
* IEContentLoaded.js
*
* Author: Diego Perini (diego.perini at gmail.com) NWBOX S.r.l.
* Summary: DOMContentLoaded emulation for IE browsers
* Updated: 05/10/2007
* License: GPL/CC
* Version: TBD
*
*/
// @w window reference
// @fn function reference
function IEContentLoaded (w, fn) {
var d = w.document, done = false,
// only fire once
init = function () {
if (!done) {
done = true;
fn();
}
};
// polling for no errors
(function () {
try {
// throws errors until after ondocumentready
d.documentElement.doScroll('left');
} catch (e) {
setTimeout(arguments.callee, 50);
return;
}
// no errors, fire
init();
})();
// trying to always fire before onload
d.onreadystatechange = function() {
if (d.readyState == 'complete') {
d.onreadystatechange = null;
init();
}
};
}
Nope. Nothing there at all. Hitting View Source (!) reveals a (very)
ugly object inference:-
// only start this for Internet Explorer
if (typeof document.fileSize != 'undefined') {
Is that the "example" you mean? In the source?
>
> You also wrote "Why not design with reality in mind?".
Just quote and cite. Thanks.
> In reality this is a working solution for at least IE 6-8.
Even if that were the case (it's certainly not proven), the reality is
that you can't implement it without sniffing and have no way to know
what it will break in the future. A script that seems to work today
per observation only is hardly guaranteed to work tomorrow. You have
to have some shred of a (real) hypothesis or documentation as to why
it should work and why it should continue to work in the future. Your
observations of it working in _your_ IE desktop browsers are worthless
(think how many different configurations each of them has).
And how do you define "working" as well? The same way you define
"proof?" This industry does not need more mindless blithering. Is
this your idea of job security (i.e. doing stupid things for no real
reason to ensure a call back?) Why not investigate the myriad other
options that _are_ grounded in reality?
I've got two words for all of the seemingly endless stream of cocksure
neophytes that want to "argue" endlessly about nothing. Why bother?
Scott Sauyet
> On Jan 1, 8:39 am, Scott Sauyet <scott.sau...@gmail.com> wrote:
>
>> On Dec 31 2009, 6:09 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
>>> On Dec 31, 10:35 am, ScottSauyet<scott.sau...@gmail.com> wrote:
>>> "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?
>
> You didn't understand that?
I understand that you somehow think for jQuery, the number of posts is
O(n^2) in respect to the number of active posters. I have no idea how
you got that idea, but I rather doubt it and would love to see your
evidence.
What doesn't make sense is your taking Matt Kruse to task for being
inconsistent on whether the number of posts says anything positive
about jQuery while your yourself are being inconsistent about the very
same thing. You earlier said that the large number of posts
demonstrated problems with jQuery. Why are you now not willing to say
that falling numbers demonstrate increasing competence?
There is a real question of what the number of posts mean. It's clear
that a little-used technology will not likely generate large numbers
of posts, so large numbers do say something about how widespread the
interest in the technology is. But on the other hand, a well-
documented technology with few bugs will generate fewer posts than one
that is buggy or poorly understood, so large numbers also say
something about the lack of quality of a technology. How these two
factors balance against each other, though, that's anyone's guess.
-- Scott
Diego Perini
You are just refuting any evidence that has been showed and you still
do not give any failing test case nor a better solution:
* Summary: DOMContentLoaded emulation for IE browsers
Does it mean something to you ? If not read or re-read the complete
accompanying page, I wrote it clearly in the first sentence:
[QUOTE]
This is an Internet Explorer only method. It does not produce the
expected results on other browsers.
It is meant to be used as an IE alternative in other fine scripts
trying to fix the window onload problem.
It is based on a hack (no doubt about that), but I hope it is an
improvement over previous IE hacks.
[/QUOTE]
http://javascript.nwbox.com/IEContentLoaded/
if you were searching for my old cross-browser solution (knowing you,
I fear in showing so much sniffing, but anyway just to clear up the
confusion I may have created in you and your expectations):
http://javascript.nwbox.com/ContentLoaded/
but if you like to do free reviews and help a bit you should really
look at the implementation I moved to latest NWEvents where I finally
removed all that unwanted browser sniffing of UA:
http://github.com/dperini/nwevents/
the additions/commits of my DOMContentLoaded/IEContentLoaded solution
to nwevents-1.2.3.js were included just a few days ago (on users
request) !
This is the Microsoft citation again, I mean the one the pushed me to
test things instead of just assuming:
http://msdn.microsoft.com/en-us/library/ms531426(VS.85).aspx
[QUOTE]
A few methods, such as doScroll, require the primary document to be
completely loaded. If these methods are part of an initialization
function, they should be handled when the ondocumentready event fires.
[/QUOTE]
And yes I (and others) have tested the that method throws errors up
until the page source is completely loaded, even if trickled by server
code, I mean inserting delays in server-side output both through
server scripting flushes and using proxy software like Charles for
analyzing the process.
Then it was tried comparing Microsoft original/suggested HTC solution
and it was found to give the same results/timings.
It is still an "hack" as I wrote in the docs. Have no ways to disagree
on that.
David Mark
> On Jan 1, 3:31 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Jan 1, 8:39 am, Scott Sauyet <scott.sau...@gmail.com> wrote:
>
> >> On Dec 31 2009, 6:09 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> >>> On Dec 31, 10:35 am, ScottSauyet<scott.sau...@gmail.com> wrote:
> >>> "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?
>
> > You didn't understand that?
>
> I understand that you somehow think for jQuery, the number of posts is
> O(n^2) in respect to the number of active posters.
Dear God. That's what you took from that? It was an _example_.
Threads are trees and trees grow exponentially. As I said: "call it n
squared" (for the sake of argument).
> I have no idea how
> you got that idea, but I rather doubt it and would love to see your
> evidence.
No, you just want to blather about nothing (or there is some sort of
language barrier in play).
>
> What doesn't make sense is your taking Matt Kruse to task for being
> inconsistent on whether the number of posts says anything positive
> about jQuery while your yourself are being inconsistent about the very
> same thing.
I certainly am not.
> You earlier said that the large number of posts
> demonstrated problems with jQuery.
No, I didn't (and I thought I explained that well enough, even for a
child to understand). The "large number of posts" quote from a year
ago was in response to Matt's assertion that they got more posts than
CLJ because their group was more active. Get it?
> Why are you now not willing to say
> that falling numbers demonstrate increasing competence?
You've got two different trains of thought crossed up in your brain.
They still get more posts _per active user_ because they can never
seem to answer anything with finality (it's all guesswork). It
doesn't matter if there is one or a million users.
>
> There is a real question of what the number of posts mean.
Obviously.
> It's clear
> that a little-used technology will not likely generate large numbers
> of posts, so large numbers do say something about how widespread the
> interest in the technology is.
Yes, somewhat.
> But on the other hand, a well-
> documented technology with few bugs will generate fewer posts than one
> that is buggy or poorly understood, so large numbers also say
> something about the lack of quality of a technology.
Bingo! There is clearly nothing well-documented about jQuery and no
real progress on bugs in the last few years (certainly can't
characterize their infestation as a "few bugs"), so I think the cause
of the decline is clear (it has nothing to do with quality).
> How these two
> factors balance against each other, though, that's anyone's guess.
If you rule out your "quality" argument, what's left?
Dr J R Stockton
1g2000yqz.googlegroups.com>, Thu, 31 Dec 2009 18:21:13, David Mark
<dmark....@gmail.com> posted:
>
>I have Thunderbird. My stupid provider canceled NNTP years ago
>(idiots). Duh, they can you just use Google Groups. :)
Then use one or more of the inexpensive non-American NNTP providers.
Or even of the free ones.
--
(c) John Stockton, nr London UK. replyYYWW merlyn demon co uk Turnpike 6.05.
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes precede replies. Snip well. Write clearly. Mail no News.
David Mark
wrote:
> In comp.lang.javascript message <4602e3a1-b2dc-41d1-a32f-d77941291e5d@z4
> 1g2000yqz.googlegroups.com>, Thu, 31 Dec 2009 18:21:13, David Mark
>
>
>
> >I have Thunderbird. My stupid provider canceled NNTP years ago
> >(idiots). Duh, they can you just use Google Groups. :)
>
> Then use one or more of the inexpensive non-American NNTP providers.
>
> Or even of the free ones.
>
I have signed up for eternal-september.org. Will configure TB when I
have a chance. Will be great to get away from this abominable
interface. Whatever could Google be thinking presenting news articles
like this? It's so completely beyond awful that you have to wonder if
anybody there has even tried it. If they did, why in God's name did
they sign-off on it?
Same goes for Adsense. After I complained repeatedly about the "auto-
sign-in" breaking the back button, they tried to fix it. Of course,
now it never signs in, landing inevitably on the sign-in form, with
this blurb above it in yellow:-
"Already signed in? Take me to my account."
...why are they _asking_ me?! Don't they know?
And there is also this link, captioned "What's this?":-
https://www.google.com/adsense/static/en_US/AutoSignIn.html
I knew exactly what it was before I clicked it. They are so utterly
predictable.
Oh well, glad I could help. :)
Garrett Smith
> In comp.lang.javascript message <4602e3a1-b2dc-41d1-a32f-d77941291e5d@z4
> 1g2000yqz.googlegroups.com>, Thu, 31 Dec 2009 18:21:13, David Mark
> <dmark....@gmail.com> posted:
>> I have Thunderbird. My stupid provider canceled NNTP years ago
>> (idiots). Duh, they can you just use Google Groups. :)
>
> Then use one or more of the inexpensive non-American NNTP providers.
>
> Or even of the free ones.
>
Hans-Georg Michna
>I have comcast for ISP
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.
I get the creeps when I hear "Comcast". (:-)
Hans-Georg
Hans-Georg Michna
>I wouldn't ape their API. It's a waste of time.
I see your point, but the fact remains that jQuery is incredibly
popular, rightfully or not. "Aping" their API is the only chance
to let users easily and directly compare and find what works.
While I assume you are right about all the technical basics, you
may still be overlooking how attractive the jQuery API is for
beginners, probably also for intermediate programmers, and those
are the ones that matter a lot for the market situation.
Forget about the inefficiency. For most typical jQuery
applications it just does not matter, and for the fewer web
sites where jQuery's inefficiency does matter, one can still
offer alternatives.
Yet another reason is the huge amount of existing jQuery code.
Only a compatible API can lever that.
By the way, I would redefine jQuery's .attr(…) method to work
only with properties. For the most part they have done that
themselves already, so the misnomer will have to stay.
Hans-Georg
David Mark
georgNoEmailPle...@michna.com> wrote:
> On Fri, 1 Jan 2010 14:52:36 -0800 (PST), David Mark wrote:
> >I wouldn't ape their API. It's a waste of time.
>
> I see your point, but the fact remains that jQuery is incredibly
> popular, rightfully or not.
So was Disco. ;) Trust me when I tell you that it is on its way
(rightfully) down the toilet. Have I been wrong yet?
> "Aping" their API is the only chance
> to let users easily and directly compare and find what works.
Not really. TaskSpeed is a good example. Of course, when jQuery came
in dead last (by fifty lengths at least) and the rest of the pack
finished a mile behind the "pure" baseline, I heard ugly "Real World"
murmurs creeping in (e.g. the "pure" solutions were somehow
cheating). Some people will see what they want to see, regardless of
reality (see Matt Kruse) :)
>
> While I assume you are right about all the technical basics, you
> may still be overlooking how attractive the jQuery API is for
> beginners, probably also for intermediate programmers, and those
> are the ones that matter a lot for the market situation.
There's exactly two attractions for the dull and duller set:-
1. Querying by CSS selector
2. "Chaining"
#1 is arguably not a good interface for DOM scripting, but that's as
maybe. Virtually every browser that jQuery "supports" has it built-in
now (QSA, and it simply isn't compatible with jQuery).
http://www.cinsoft.net/queries.html
#2 was always built into the language. Put this at the end of your
method calls:-
return this;
So, it's pretty much over for them for all but the hopelessly deluded
who will eventually self-destruct (like all die-hard cult members).
The same goes for any "cross-browser" script or framework stupid
enough to "support" one wave of browsers at a time (e.g. the latest
major desktop browsers). They are now hopelessly swamped,
particularly those still stuck in the decade before last (sniffing the
UA string).
>
> Forget about the inefficiency. For most typical jQuery
> applications it just does not matter, and for the fewer web
> sites where jQuery's inefficiency does matter, one can still
> offer alternatives.
You are completely wrong. jQuery can be hundreds and even thousands
of times slower than a competently written, context-specific script.
It's outrageous what these "code monkified" sites do to my PC's. And
for what? Most of them don't do anything special at all.
And when responding to user input, scripts need to be as fast as
possible. This is particularly true on mobile devices (which jQuery-
fied sites needn't worry about as they will typically just blow up at
the outset).
>
> Yet another reason is the huge amount of existing jQuery code.
It's all shit. By definition, it would have to be. Don't listen to
idiots who use those "nothing is perfect" or "just being pragmatic"
argument to try to explain away core issues. When the foundation
(reading element attributes and dimensions, viewport measurement,
input monitoring, etc.) shifts _constantly_ (usually because of
incompetence on the part of the authors), it topples the efforts of
the neophytes building on top of it. Then what do _they_ do? See the
various support forums to find out. The end result is typically to
try to replace it with a newer (or older) version, which is a non-
trivial proposition, even for experienced developers with support from
solid QA testers (hardly the norm). Phew! And what if it still
doesn't "work?" Do you see how you could never rely on plug-ins or
anything else written by a third-party jQuery "programmer?" And
there's no system to keep track of compatibility for any of it.
Software just doesn't work like that, even on the desktop where it is
a _far_ easier proposition to wing it. ;)
> Only a compatible API can lever that.
You need a shovel for that pile, not a lever.
>
> By the way, I would redefine jQuery's .attr(…) method to work
> only with properties.
Yes, explaining that (or anything for that matter) to the deluded
authors (again, see Matt Kruse).
http://groups.google.com/group/jquery-dev/browse_thread/thread/baef5e91bd714033#
It's a cargo cult. Resig's idea of "test-driven development" is to
use tests not to confirm his designs are implemented correctly, but to
shape his designs. It's mixed up and nobody can seem to convince him
otherwise (after three years). He's just a rotten programmer with
abysmal problem-solving skills (and virtually no real experience with
cross-browser scripting) who (unfortunately) stumbled upon success and
adulation from people who don't know any better (e.g. Web
developers). It's retarded whatever development he might have been
capable of. Bit of a loud-mouth too. As for his die-hard followers,
some of them seem genuinely retarded to me. :) Wouldn't you have to
be at this point, at least mildly?
> For the most part they have done that
> themselves already, so the misnomer will have to stay.
Um, it's still a bizarre hybrid last I checked. It throws exceptions
for some attributes, reads attributes for others, steps on still
others and reads straight properties for the majority. It varies from
one version of jQuery to the next and the behavior changes _radically_
in IE8 on clicking the compatibility mode button (which sort of
simulates IE7), which is a large button right next to Refresh. Do you
see the problem with this?
jdalton
Here are links with quotes this time :D
http://msdn.microsoft.com/en-us/library/ms531426%28VS.85%29.aspx#Component_Initialization
[quote]
A few methods, such as <a>doScroll</a>, require the primary document
to be completely loaded.
If these methods are part of an initialization function, they should
be handled when the ondocumentready event fires.
[/quote]
My earlier comment about doScroll() failing to behave properly on
secondary documents, because it's based on the primary, reinforces the
documentation above.
http://msdn.microsoft.com/en-us/library/ms531426%28VS.85%29.aspx#ctl00_MTCS_main_ctl53
(suggest errors are thrown on things that require the document to be
completely parsed)
[quote]
The innerHTML property of the custom element is available once the
oncontentready event has fired.
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.
[/quote]
> So you posted something irrelevant and mentioned that it was
> irrelevant at the same time. Why?
The C++ link was to show possible intent carried over from the related
API.
> And, doesn't it follow that if you can't implement it without browser
> sniffing, it's a dead issue (and has been for ten years?) :)
I wasn't suggesting/endorsing that implementers use browser sniffing.
I was merely stating that it is one of the techniques used to
determine if they should call their IEContentLoaded() equivalent.
None of the implementers should call the function without attempting
to ensure IE-only use first.
About the "onreadystate" comment:
The "onreadystatechange" is intended as a fallback (worse case).
It will at least be executed before the onload event observers.
About the code usage:
At the top of the page it states "This is an Internet Explorer only
method".
The source code includes nothing to make it self-executing so it's up
to the implementer to determine when the function should be called.
> Nope. Nothing there at all. Hitting View Source (!) reveals a (very)
> ugly object inference:-
>
> if (typeof document.fileSize != 'undefined') {
>
> Is that the "example" you mean? In the source?
Yes that's one way.
About the technique working:
> > In reality this is a working solution for at least IE 6-8.
>
> Even if that were the case (it's certainly not proven),
It has been proven.
http://dl.dropbox.com/u/513327/doscroll.png
Just fire up your VM and try the demos or
http://dl.dropbox.com/u/513327/doscroll.html
> A script that seems to work today
> per observation only is hardly guaranteed to work tomorrow.
It’s worked for 11 years now.
With Microsoft investing in JavaScript frameworks and nearly all of
them using this technique I think it’s pretty likely to stick around
for another 11 or more.
> You have
> to have some shred of a (real) hypothesis or documentation as to why
> it should work and why it should continue to work in the future.
See above.
> I've got two words for all of the seemingly endless stream of cocksure
> neophytes that want to "argue" endlessly about nothing. Why bother?
I really dig informed and constructive reviews.
Seeing as you missed docs, notes, and usage context from the post I
don’t think your review would qualify as informed or constructive.
-JDD
David Mark
> David,
>
> Here are links with quotes this time :D
>
>
> [quote]
> A few methods, such as <a>doScroll</a>, require the primary document
> to be completely loaded.
> If these methods are part of an initialization function, they should
> be handled when the ondocumentready event fires.
> [/quote]
I've seen that one. IIRC, it is quoted on one of the pages espousing
your advocated strategy. As I said, it does not say that the browser
will throw exceptions before the DOM is ready.
>
> My earlier comment about doScroll() failing to behave properly on
> secondary documents, because it's based on the primary, reinforces the
> documentation above.
I recognize those words, but...
>
> http://msdn.microsoft.com/en-us/library/ms531426%28VS.85%29.aspx#ctl0...
> (suggest errors are thrown on things that require the document to be
> completely parsed)
>
> [quote]
> The innerHTML property of the custom element is available once the
> oncontentready event has fired.
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.
> [/quote]
Yep. Definitely the wrong docs. Literal Content component?!
>
> > So you posted something irrelevant and mentioned that it was
> > irrelevant at the same time. Why?
>
> The C++ link was to show possible intent carried over from the related
> API.
It's not entirely out of touch, but close doesn't count with this sort
of stuff. The reality is that (as we've seen) you can't predict what
MS will do in the next version of IE, even when they _do_ document
things (and you apparently don't have any way to target IE anyway).
Seeing as a failure here will be fatal, it is imprudent to bet the
farm on such conjecture.
>
> > And, doesn't it follow that if you can't implement it without browser
> > sniffing, it's a dead issue (and has been for ten years?) :)
>
> I wasn't suggesting/endorsing that implementers use browser sniffing.
I didn't say you were. But just what are you suggesting? The example
you cited used an object inference that was completely unrelated to
the doScroll method. It didn't even check if that method existed.
(!) This is the mindset that has resulted in a new jQuery version
every year and the severing of support for anything but the latest
versions of major browsers (in their default configurations). Stop
and think. It's like the last time around for these things, so why
not shock the world and come up with a competent solution? It's been
three years (and ten since IE6 came out) and you still can't even
_read_ documents straight. ;)
> I was merely stating that it is one of the techniques used to
> determine if they should call their IEContentLoaded() equivalent.
And what method would you recommend? My point has been that there is
no feature test that will indicate anything about this behavior, so
you might as well write it off and investigate the myriad other (sane)
possibilities.
> None of the implementers should call the function without attempting
> to ensure IE-only use first.
See above. You aren't really adding anything at this point.
>
> About the "onreadystate" comment:
> The "onreadystatechange" is intended as a fallback (worse case).
> It will at least be executed before the onload event observers.
And that stupid try-catch may still be going around in circles at 50ms
a revolution. ;)
>
> About the code usage:
> At the top of the page it states "This is an Internet Explorer only
> method".
That's meaningless and irrelevant. The fact is it is a doScroll-
exists-and-throws-exceptions-before-dom-ready method. I told you
there's no feature test for that. End of story, unless you are keen
on banging your head against a wall for no reason.
>
> The source code includes nothing to make it self-executing so it's up
> to the implementer to determine when the function should be called.
You are a broken record. Why are you wasting time like this?
>
> > Nope. Nothing there at all. Hitting View Source (!) reveals a (very)
> > ugly object inference:-
>
> > if (typeof document.fileSize != 'undefined') {
>
> > Is that the "example" you mean? In the source?
>
> Yes that's one way.
...to shoot yourself in the foot.
1. Other browsers have been known to copy IE
2. IE9 may drop that property
3. That property has nothing to do with the task at hand
4. Where is the detection of the doScroll method?
It's the same song and dance; the same miserable tune I've been
hearing from self-proclaimed browser scripting gurus for the last few
years. Look where it's got you. :(
>
> About the technique working:
>
> > > In reality this is a working solution for at least IE 6-8.
>
> > Even if that were the case (it's certainly not proven),
>
> It has been proven.http://dl.dropbox.com/u/513327/doscroll.png
That proves nothing. Where is the data that indicates the DOM was
ready when that thing snapped out of its exception cycle? Are you
aware that Operation Aborted (and related maladies) are notoriously
sporadic? I would think that would be obvious by now.
>
> Just fire up your VM and try the demos orhttp://dl.dropbox.com/u/513327/doscroll.html
Fire up my VM?! Do I take that to mean that you haven't even tested
this in Windows?
>
> > A script that seems to work today
> > per observation only is hardly guaranteed to work tomorrow.
>
> It’s worked for 11 years now.
It is the height of absurdity for you to cite the age of IE6 in
defense of such hacks. You realize that jQuery is nowhere near
compatible with that browser, right?
And what about year 12? ;)
> With Microsoft investing in JavaScript frameworks and nearly all of
> them using this technique I think it’s pretty likely to stick around
> for another 11 or more.
Microsoft investing in JavaScript (sic) frameworks? Do tell! You do
realize that IE8 broke the jQuery in so many ways that it is now
virtually unusable? They are really looking out for Resig's
interests, huh?
And for the umpteenth time, browser developers do not bend to the will
of code monkeys. We've seen it over and over. Why do you think they
have to keep rewriting large tracts of jQuery (and dismissing last
year's browsers?).
>
> > You have
> > to have some shred of a (real) hypothesis or documentation as to why
> > it should work and why it should continue to work in the future.
>
> See above.
See above. :)
>
> > I've got two words for all of the seemingly endless stream of cocksure
> > neophytes that want to "argue" endlessly about nothing. Why bother?
>
> I really dig informed and constructive reviews.
You really dig? Are you saying you haven't been informed by my
various reviews? I suggest you read them again. And if you find them
destructive, that's your problem (in every conceivable sense). ;)
> Seeing as you missed docs, notes, and usage context from the post I
> don’t think your review would qualify as informed or constructive.
>
I missed nothing.
jdalton
> 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.
> > [/quote]
>
> Yep. Definitely the wrong docs. Literal Content component?!
The documentation is targeted toward behaviors/htc files but reference
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.
> And what method would you recommend? My point has been that there is
> no feature test that will indicate anything about this behavior, so
> you might as well write it off and investigate the myriad other (sane)
> possibilities.
I disagree. A specific object inference on the method should be
enough.
You have similar in your own code.
About the "onreadystate" comment:
> And that stupid try-catch may still be going around in circles at 50ms
> a revolution. ;)
The dropbox example I posted is a basic example designed to provide
confirmation that technique works.
A more robust solution could stop repeated calls to the function in an
onload event handler (worse case).
> > About the code usage:
> > At the top of the page it states "This is an Internet Explorer only
> > method".
>
> That's meaningless and irrelevant. The fact is it is a doScroll-
> exists-and-throws-exceptions-before-dom-ready method. I told you
> there's no feature test for that. End of story, unless you are keen
> on banging your head against a wall for no reason.
It shows your initial lack of context as you failed to properly read
the post and jumped to unrealistic conclusions.
Again object inference with the "shreds" of documentation and tests
are enough here.
> Fire up my VM?! Do I take that to mean that you haven't even tested
> this in Windows?
No I did.
I was stating you can fire up a virtual machine/pc and test it on an
image if you had one handy.
> > > A script that seems to work today
> > > per observation only is hardly guaranteed to work tomorrow.
>
> > It’s worked for 11 years now.
>
> It is the height of absurdity for you to cite the age of IE6 in
> defense of such hacks. You realize that jQuery is nowhere near
> compatible with that browser, right?
>
It was the age of IE 5.0.
The code reviewed was not jQuery code.
> And for the umpteenth time, browser developers do not bend to the will
> of code monkeys. We've seen it over and over. Why do you think they
> have to keep rewriting large tracts of jQuery (and dismissing last
> year's browsers?).
I am not defending jQuery's coding practices.
Developers influence browser development all the time.
The popularity of selecting elements by css selectors helped pave the
way for querySelectorAll().
Some browsers even allow per site compatibility patching.
http://blogs.msdn.com/ie/archive/2008/12/03/compatibility-view-improvements-to-come-in-ie8.aspx
> > I really dig informed and constructive reviews.
>
> You really dig? Are you saying you haven't been informed by my
> various reviews? I suggest you read them again. And if you find them
> destructive, that's your problem (in every conceivable sense). ;)
I am referring to your review over IEContentLoaded not the various
others.
http://groups.google.com/group/comp.lang.javascript/msg/c8a115d7d7cf87b4
> I missed nothing.
Look again :D
-JDD
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.
> > > [/quote]
>
> > Yep. Definitely the wrong docs. Literal Content component?!
>
> The documentation is targeted toward behaviors/htc files but reference
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. ;)
>
> > And what method would you recommend? My point has been that there is
> > no feature test that will indicate anything about this behavior, so
> > you might as well write it off and investigate the myriad other (sane)
> > possibilities.
>
> 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. :)
>
> > And that stupid try-catch may still be going around in circles at 50ms
> > a revolution. ;)
>
> 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. ;)
>
> > > About the code usage:
> > > At the top of the page it states "This is an Internet Explorer only
> > > method".
>
> > That's meaningless and irrelevant. The fact is it is a doScroll-
> > exists-and-throws-exceptions-before-dom-ready method. I told you
> > there's no feature test for that. End of story, unless you are keen
> > on banging your head against a wall for no reason.
>
> 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. :(
>
> > Fire up my VM?! Do I take that to mean that you haven't even tested
> > this in Windows?
>
> 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.
>
> > > > A script that seems to work today
> > > > per observation only is hardly guaranteed to work tomorrow.
>
> > > It’s worked for 11 years now.
>
> > It is the height of absurdity for you to cite the age of IE6 in
> > defense of such hacks. You realize that jQuery is nowhere near
> > compatible with that browser, right?
>
> 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.
>
> > And for the umpteenth time, browser developers do not bend to the will
> > of code monkeys. We've seen it over and over. Why do you think they
> > have to keep rewriting large tracts of jQuery (and dismissing last
> > year's browsers?).
>
> 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 really dig informed and constructive reviews.
>
> > You really dig? Are you saying you haven't been informed by my
> > various reviews? I suggest you read them again. And if you find them
> > destructive, that's your problem (in every conceivable sense). ;)
>
> 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.
:\
jdalton
> > The documentation is targeted toward behaviors/htc files but reference
> >
> > 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.
Does to :D
> 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.
> > 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. :(
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
> 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
Hans-Georg Michna
give somebody a choice between a perfect solution on a silver
tablet and a heap of garbage, people go straight for the
garbage. Humans are like rats.
This, however, may mean, assuming you are right about jQuery,
its continuing success. (:-)
I've done an interesting personal test recently, essentially
triggered by you. I've tried to wean myself off jQuery. My first
finding is that it was surprisingly easy.
However, there are a few places where I need some helpful,
well-working, ready-made code, to shield myself from browser
dependencies and to do some special work like Ajax. Will look at
your library again when I need that.
Have you ever thought about doing an updated version that sheds
support for very old browsers like IE before 6? Perhaps that
could make the code a lot smaller, as the newer browsers have
moved closer to the standard.
Hans-Georg
Garrett Smith
> On Sat, 02 Jan 2010 22:51:09 -0800, Garrett Smith wrote:
>
>> I have comcast for ISP
>
> 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.
>
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,
>
> > > The documentation is targeted toward behaviors/htc files but reference
>
> > > 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.
>
> Does to :D
*PLONK*
Garrett Smith
> On Jan 1, 1:05 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> David Mark wrote:
>>> On Dec 29, 7:52 pm, Garrett Smith <dhtmlkitc...@gmail.com> 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.
Diego Perini
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).