Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > My Library TaskSpeed tests updated

Reply
Thread Tools

My Library TaskSpeed tests updated

 
 
Scott Sauyet
Guest
Posts: n/a
 
      02-18-2010
David Mark wrote:

> I wonder if you ran the thing while I had a bad build up there. *That
> has happened a couple of times in the last week.


That's always possible. I don't know if you can tell by looking at a
minified version, but it's here:

http://scott.sauyet.com/Javascript/T...s/mylib-min.js

Obviously that's from the version I ran at

http://scott.sauyet.com/Javascript/T...d/2010-02-15a/

This one has in addition to the real libraries tested, one I described
with the changes to the loop initialization for My Library (slows down
by 15%) and one with a number of the cheats I complained about added
to the JQuery tests (huge speed-ups.)

I tested again today in IE6, which is painfully slow, and I get the
same errors. Maybe it was just a bad build.

-- Scott
 
Reply With Quote
 
 
 
 
David Mark
Guest
Posts: n/a
 
      02-18-2010
Scott Sauyet wrote:
> David Mark wrote:
>> Scott Sauyet wrote:

>
>>> I actually am a fan of test-driven design, but I don't do it with
>>> performance tests; that scares me.

>> I am sure you are _not_ talking about what I am talking about. At least
>> I hope not. And what makes you think that these performance tests had
>> anything to do with the changes. FYI, they didn't.

>
> Well, this is how your post that started this thread began:
>
> | I've updated the TaskSpeed test functions to improve performance.
> This
> | necessitated some minor additions (and one change) to the OO
> interface
> | as well.
>
>
>


I know. I just wrote that. I fail to see how it implies that the speed
test results had _anything_ to do with adding a loadClone method to the
OO interface. JFTR, it didn't.
 
Reply With Quote
 
 
 
 
David Mark
Guest
Posts: n/a
 
      02-18-2010
Scott Sauyet wrote:
> David Mark wrote:
>
>> I wonder if you ran the thing while I had a bad build up there. That
>> has happened a couple of times in the last week.

>
> That's always possible. I don't know if you can tell by looking at a
> minified version, but it's here:
>
> http://scott.sauyet.com/Javascript/T...s/mylib-min.js


Yes and no. I can re-test with my IETester in IE6 mode anyway. That
may or may not mean anything. Are you using a true blue IE6 or a
simulation of some sort?

>
> Obviously that's from the version I ran at
>
> http://scott.sauyet.com/Javascript/T...d/2010-02-15a/


Okay. I'll just hit that in my IETester IE6 and see what happens. Thanks!

>
> This one has in addition to the real libraries tested, one I described
> with the changes to the loop initialization for My Library (slows down
> by 15%) and one with a number of the cheats I complained about added
> to the JQuery tests (huge speed-ups.)


But jQuery is still bringing up the rear I assume.

>
> I tested again today in IE6, which is painfully slow, and I get the
> same errors. Maybe it was just a bad build.


What errors? I mean that literally. What is the error message you see?

Thanks!
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      02-18-2010
Scott Sauyet wrote:
> David Mark wrote:
>
>> I wonder if you ran the thing while I had a bad build up there. That
>> has happened a couple of times in the last week.

>
> That's always possible. I don't know if you can tell by looking at a
> minified version, but it's here:
>
> http://scott.sauyet.com/Javascript/T...s/mylib-min.js
>
> Obviously that's from the version I ran at
>
> http://scott.sauyet.com/Javascript/T...d/2010-02-15a/


I just ran it in (IETester) IE6. The only error I see is at the end
(dojo is undefined). LOL.

Of course, IETester is just some black box that could be doing anything
behind the scenes. I normally test with a real IE6 installation. Just
so happens that that is not convenient for me at the moment and I want
to get to the bottom of this. So, what errors are you seeing?

You mentioned three tests and all have had changes in the last little
while. As empirical evidence is inconclusive, we should turn to the
code at this point anyway. You mentioned sethtml, insertBefore and
insertAfter as having some unspecified errors. Typically, I copy and
paste the test functions into a blank page so that I can debug the
errors. As I can't do that at the moment, I can only go by the code
used in each of these test functions:-


"sethtml" : function() {
var myEl = E().loadNew('p').setText('New Content');

The E constructor is used in almost all of the tests, so we can throw
that out as a suspect. Same for its loadNew method. In contrast, the
setText method is only used by these three tests, so is a good (if
unlikely suspect). So let's round that one up:-

ePrototype.setText = function(text) {
setElementText(this.element(), text);
return this;
};

....which leads to setElementText, which I know works in IE6 and hasn't
changed in ages. So I think I can safely rule out the setText method.

Back to the test sethtml function:-

return Q('div').empty().forEach(function(el) {

The - empty - method is used by the finale test as well, but let's look
at it too:-

ePrototype.empty = function() {
emptyNode(this.element());
return this;
};

....which leads to emptyNode:-

API.emptyNode = emptyNode = function(node) {
while (node.firstChild) {
node.removeChild(node.firstChild);
}
};

....which is not going to have issues.

myEl.loadClone().appendTo(el);

Here is the code behind that chain:-

if (isHostMethod(html, 'cloneNode')) {
ePrototype.clone = function(bChildren) {
return this.element().cloneNode(bChildren);
};
ePrototype.loadClone = function(bChildren) {
return this.load(this.clone(bChildren));
};
}

But note the feature detection and realize that TaskSpeed does not do
any feature detection of the API as it is one of those
run-straight-into-a-wall type of applications. It is likely the authors
never heard of detecting _API_ methods, which is admittedly a newly
introduced concept (well, over two-years-old at this point). I point
this out as these test functions should not even be created if the
required features are absent. But then TaskSpeed would have to detect
whether the functions were created and that is beyond its current scope.
So don't expect TaskSpeed to degrade gracefully like the My Library
test page demonstrates. It will definitely crash and burn for all in
extremely outdated browsers (which does not describe IE6, of course).

ePrototype.appendTo = function(el) {
el.appendChild(this.element());
return this;
};

Nothing suspicious there.

}).load('div').length();

This just re-loads the query. It's not a new feature and I am sure all
of this has been previously tested in IE6.

},

"insertbefore" : function() {
var myEl = E().loadNew('p').setText('A Link');
return Q('.fromcode a').forEach(function(a) {
myEl.loadClone().insertBefore(a);
}).length();
},

"insertafter" : function() {
var myEl = E().loadNew('p').setText('A Link');
return Q('.fromcode a').forEach(function(a) {
myEl.loadClone().insertAfter(a);
}).length();
},

I don't see anything suspicious there either. For completeness, here
are the insertBefore and insertAfter methods:-

ePrototype.insertBefore = function(el) {
var parent = el.parentNode;

if (parent) {
parent.insertBefore(this.element(), el);
}
return this;
};

ePrototype.insertAfter = function(el) {
var next = el.nextSibling;
var parent = el.parentNode;

if (parent) {
if (next) {
parent.insertBefore(this.element(), next);
} else {
parent.appendChild(this.element());
}
}
return this;
};

This is from the latest code, but not much of that stuff has changed of
late. I don't see anything there that would cause issues in IE6 and my
testing (with my page, as well as the one you reported as problematic)
with the (possibly bogus) IETester bears that out. I even tested IE5.5
(or some approximation of it). The 5.5 results were wonderfully
affirming (virtually all blacked out except the last two columns).

So, can anyone see a problem in a real IE6 installation? I don't have
access to one right at the moment and it irritates me to think I could
have missed something. I'll be the first to admit if I did something
stupid. But I really don't think that is the case at this point (though
was wondering there for a bit).
 
Reply With Quote
 
Scott Sauyet
Guest
Posts: n/a
 
      02-19-2010
On Feb 18, 5:09*pm, David Mark <(E-Mail Removed)> wrote:
> Scott Sauyet wrote:
>> * *http://scott.sauyet.com/Javascript/T...d/2010-02-15a/

>
> I just ran it in (IETester) IE6. *The only error I see is at the end
> (dojo is undefined). *LOL.
>
> Of course, IETester is just some black box that could be doing anything
> behind the scenes. *I normally test with a real IE6 installation. *Just
> so happens that that is not convenient for me at the moment and I want
> to get to the bottom of this. *So, what errors are you seeing?


Unfortunately, all that shows up in the title of the cell is:

[object Error]

which is not at all useful.

I made a simpler version just testing My Library in order to try to
run this down. It's at

http://scott.sauyet.com/Javascript/T...d/2010-02-17a/

It's happening for me on my home machine as well as my work one. I'm
using Multiple IEs [1], which installs multiple versions of IE on a
Windows machine. I've never run into any issues beyond the many
versions occasionally sharing some settings, but it could be a problem
with this version.

-- Scott
____________________
[1] http://tredosoft.com/Multiple_IE
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      02-19-2010
Scott Sauyet wrote:
> On Feb 18, 5:09 pm, David Mark <(E-Mail Removed)> wrote:
>> Scott Sauyet wrote:
>>> http://scott.sauyet.com/Javascript/T...d/2010-02-15a/

>> I just ran it in (IETester) IE6. The only error I see is at the end
>> (dojo is undefined). LOL.
>>
>> Of course, IETester is just some black box that could be doing anything
>> behind the scenes. I normally test with a real IE6 installation. Just
>> so happens that that is not convenient for me at the moment and I want
>> to get to the bottom of this. So, what errors are you seeing?

>
> Unfortunately, all that shows up in the title of the cell is:
>
> [object Error]
>
> which is not at all useful.


Right. Something screwy is going on there as I've had several reports
of success. But all it takes is one failure to spoil the bunch.
>
> I made a simpler version just testing My Library in order to try to
> run this down. It's at
>
> http://scott.sauyet.com/Javascript/T...d/2010-02-17a/


I'll try it out, but I expect it will "pass" here again.

>
> It's happening for me on my home machine as well as my work one. I'm
> using Multiple IEs [1], which installs multiple versions of IE on a
> Windows machine. I've never run into any issues beyond the many
> versions occasionally sharing some settings, but it could be a problem
> with this version.


Multiple IE versions can lead to screwy problems, but it galls me that
my library is somehow tripping over this (and the others aren't). If
you would, I would appreciate it if you would make a simpler test case.
It will likely be a good learning exercise in any event (you've
stumbled over something that is throwing me and I thought I'd seen it
all in IE, multi or not).

Paste the test function(s) into a page without the try-catch and see
what it throws up. If you can tell me the error message and line, I'm
sure I can figure it out and fix it without duplicating the issue here.
I'm _very_ curious as to what the problem could be. Also, did you try IE7?

I reviewed the related code and nothing jumped out at me, so I'm in the
dark at this point. That's not somewhere I'm used to being when it
comes to IE. It's particularly irritating as I had multi-IE (or
something similar) on the test machine that went down recently. I
wonder if the problem would have shown up on that one.

Thanks again for your help Scott. Your efforts are _much_ appreciated!
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      02-19-2010
Scott Sauyet wrote:
> On Feb 18, 5:09 pm, David Mark <(E-Mail Removed)> wrote:
>> Scott Sauyet wrote:
>>> http://scott.sauyet.com/Javascript/T...d/2010-02-15a/

>> I just ran it in (IETester) IE6. The only error I see is at the end
>> (dojo is undefined). LOL.
>>
>> Of course, IETester is just some black box that could be doing anything
>> behind the scenes. I normally test with a real IE6 installation. Just
>> so happens that that is not convenient for me at the moment and I want
>> to get to the bottom of this. So, what errors are you seeing?

>
> Unfortunately, all that shows up in the title of the cell is:
>
> [object Error]
>
> which is not at all useful.
>
> I made a simpler version just testing My Library in order to try to
> run this down. It's at
>
> http://scott.sauyet.com/Javascript/T...d/2010-02-17a/
>
> It's happening for me on my home machine as well as my work one. I'm
> using Multiple IEs [1], which installs multiple versions of IE on a
> Windows machine. I've never run into any issues beyond the many
> versions occasionally sharing some settings, but it could be a problem
> with this version.


I was actually thinking it was a problem with my build, but your
suggestion seems more likely at this point (a problem with the multi-IE6).

I created a simplified test page for you:-

http://www.cinsoft.net/scotttest.html

If it makes it all the way through, you will see a "good!" alert. There
is no try-catch, so any error will be reported. I assume it will be the
sethtml test as it is the first of the three that was reported as having
a problem in your setup(s).

Thanks again for your help! Will be very interesting to see what those
errors are about.
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      02-19-2010
Scott Sauyet wrote:

> [1] http://tredosoft.com/Multiple_IE


I was hesitant to dump more IE's on this box, but went ahead and did it.

I should have trusted my initial instincts. I had noted that the only
common denominator was the setText method and sure as hell that was the
one throwing the exception. It wasn't that method's fault though. It
simply exposed an issue with the MultipleIE product.

The line that threw the exception was setting the innerText property of
a newly created element. In the debugger I was able to read the
property ("") as expected, but not set it. That's no good.

So this one's not on me. I never really thought it was, but had to know
for sure.

You might want to report this to the MultipleIE people. Appears they
have issues with some of the versions (there are several others noted on
their Website).

Glad that one is off my plate.

Once again, thanks for the feedback! There are no bad bug reports.
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      02-22-2010
Richard Cornford wrote:

[...]

>
> I prefer to question these notions, and make two observations. The first
> being that when asked for the rational justification for general purpose
> javascript libraries the answers given tend towards the superficial and
> the unthinking. Mostly when I ask the question no attempt to answer is
> given at all. A few people bother to assert that the answer is "obvious"
> (dubious because when the reason for something really is obvious it is
> also trivial to state that reason; meaning the fact that it has not been
> stated when asked for implies that it is not "obvious"). Sometimes the
> next position is that having pre-existing general libraries are is good
> idea in other languages so they must be a good idea in javascript, which
> denies the context of application, as downloading/compiling the
> equivalent of Java's 16 megabytes of libraries every time you want view
> a web page clearly would not be a good idea.
>


In my experience, it is even worse. These library devotees truly
believe that using a GP library is forward-thinking, efficient and
virtually a requirement for anything more than a "hello world"
application; whereas, "old-school" JS is backwards time-wasting
bullshit. Of course, none of them has ever written a cross-browser
script (though they often think they have), so there is really no way
for them to make meaningful comparisons.

For example, about a year ago, I was charged with re-vamping a _very_
simple, but uber-critical, public form-based application. It's the kind
of thing I've done a million times: write the basic HTML and CSS, then
the back-end scripting and finally a dash of client-side script to give
it a little flavor. When I first looked at the original I was horrified
and informed management that we were definitely starting over. They
didn't have any problem with that as they brought me in for my expertise
and I spared them the details of why I was throwing out somebody's baby.

It was the usual nonsense. Horribly invalid and heavy XHTML as HTML,
tables-in-tables-in-more-tables, no navigation, all in one page,
ridiculous CSS, didn't work without scripting (showed a loading
animation forever), inaccessible form control widgets, downloaded half a
MB of scripts to do basic form validation, _literally_ fell apart in
lower resolutions and older browsers, etc., etc. I'm sure it isn't
difficult to picture as the Web is full of such ill-advised "modern"
monstrosities. But, for each of them there is some beetle-browed
twit-and-a-half that thinks they created a masterpiece (and usually an
equally clueless manager that lauded them as a genius for "just getting
things done" and "saving time and money"). That's where they get the
egos. And, of course, the catalyst for these "positive" results was
library xyz. So I knew I'd have to do a literally perfect job as the
slightest misstep at any point in the development would give them
ammunition to say "aw, you shoulda just used a library" and "why are you
wasting time?" Needless to say, I was confident that I could withstand
the scrutiny of "forward-thinking" know-nothings as they don't tend to
test things very thoroughly anyway.

So, I put together one of the leanest, most semantic little masterpieces
I've ever done. As I would find out, the first cut wasn't 100% perfect,
but it was _damned close_. The weight of the thing was cut by over 90%
(no exaggeration), it was valid, strict HTML, did not require scripting,
ran on (almost) everything, including older phones, text browsers,
screen readers, etc. And, to assuage the "old-school" challenges that I
knew would be forthcoming from the peanut gallery, I added "cool"
animations that even leveraged the (then) new Webkit transitions so as
to work swimmingly in iPhones/iPods, etc. It was ****ing _beautiful_.
I showed it to management before I moved on to carving it up into
templates for integration with the server side scripts, which were
already in place. They marveled at how _fast_ it was and left it at
that. So far so good.

Now, enter beetle-browed nitwit #1. The first thing they wanted to know
was why didn't I use library xyz. The idea that it was a good idea not
to use the piece of **** was just beyond their comprehension. I could
hear the skepticism in their voice (it was a remote job, so I couldn't
see them grimacing) as they questioned me about "reinventing the wheel"
and whether or not this "alien" POJS creation would really work in "all
browsers". Since I had already shown it to the people who mattered, I
didn't bother arguing with them. For all I knew, they wrote the
original and I didn't feel like wasting time explaining why the original
was a complete and utter disgrace.

Then, when I was about done with everything, testing the new forms (yes,
plural as I actually used more than one document), enter beetle-browed
nitwit #2, who announced that he wanted to start "designing" the forms.
It was a real spit-take moment. _Designing_ the forms?! The ****ing
thing was in the bag. What could he possibly have meant by that? Well,
I did have some idea and it turned out to be spot on. I mentioned to
him that if he was going to use PNG's to avoid translucent pixels if at
all possible. He seemed puzzled by that comment and asked why. I told
him they would look terrible in IE6 without ugly workarounds. Ah, no
problem, he said, they don't "support" IE6. And yes, corporate users
were the target market. (!) Take it several shambling, bumbling steps
further as I was told not to "waste time" testing in anything less than
IE8 and to forget about "broken" browsers like Opera too. OMFG. I
didn't know where to begin to explain the world to this guy, so I didn't
bother. I knew I sure as hell wasn't signing off on anything that
wasn't tested in IE6 (for a start).

Next thing I know, there are some bogus "XHTML" documents and equally
ludicrous CSS "designs" in my inbox. But I had an out (or so I
thought). I changed the look of mine to (roughly) match his (without
breaking in lower resolutions for one difference) and informed him that
I wouldn't be using his "fine work" as the originals had already been
put into templates for the server and the deadline was less than a
****ing week away. I figured nobody in their right mind(s) would argue
with that. I wasn't wrong about that, but these people were not in
their right minds. Be fair, these people were completely crackers (to
put it mildly).

Next thing I know (and I wonder what prompted it), I had an angry
manager asking me why I hadn't used this guy's "design". I was "wasting
time", they wanted to "just get it done", etc., etc. **** me running.
The little bastard was stirring up **** behind-the-scenes because he was
sure that his way was "right" and mine was "wrong". Simple as that.

So, I tried my best to explain (with visual aids) that junior's "design"
completely fell apart on my PC (and I mean fell apart as in unusable,
even unreadable). They had a pow-wow and came back quizzing me about
the size of my monitor. I told them it was ****ing huge (it's a 60"
television for Christ's sake). They had another huddle and came back to
ask what they really wanted to know, which was what _resolution_ was I
running. I told them, in all honesty, that it was 800x600 and oh did
they freak out (knew they would).

I demonstrated to them it didn't do much (if any) better at 1024x768 and
explained that users can't be required to use maximized browsers with no
extra toolbars, OS font settings that exactly match their developers,
etc., etc. There was a delay as I assume they tossed this "new"
information around with said nitwit and the final resolution was that I
was using an incorrect setup and must change my display settings to 1280
by whatever immediately so that no more time would be wasted. OMFG
again. I tried to explain that they had no idea what any resolution
would look like on my end as I use large font mode, but they just didn't
want to hear any more about it. I could sense they were getting _very_
angry (at me!)

Then enter nitwit #3 (this shop had them in abundance), who informed me
that they had noticed a client-side issue in Chromium. I said fine. It
should take all of two minutes to diagnose and fix as I know how to
debug a ****ing Web application (especially one that is just a trivial
set of forms). They said don't bother as it was just Chromium.
Whatever. I didn't have Chromium and AFAIK you have to build it, so I
put it on my list to check out before the release.

Next thing I know, I'm put on something else and there is this
trying-to-be-ironic post in one of the company forums that referred to
what I had done as old-fashioned, over-complicated, etc. They actually
had the gall to refer to the 100 or so lines of "plain-old" JS as
something that "just works" (with the ironic quotes if you can believe
that) and that they had taken the liberty of dropping in library xyz so
that it could be brought into the "modern" age, using (you guessed it)
****ing queries in lieu of referencing form controls through the forms'
- elements - collections. One of their "justifications" for this was
that there was "some problem" in one of the tested browsers (the
unexplained and never-investigated Chromium issue, of course) and that
clearly if I had used magic library xyz, they'd all have been
celebrating a successful launch by now. Then they systematically carved
away everything good about it, adding XHTML-style markup, lots of
idiotic CSS hacks, Flash, tons more bogus scripting (all powered by
browser sniffing, of course). But that wasn't enough destruction, so
they threw out the server side templates and went with a more "modern"
(and inherently inaccessible) Ajax approach. Basically, it ended up
back where it started. And who was the villain in all of this? You
guessed it.

I warned them that they were courting disaster with all of that bullshit
and they thoughtfully told me they would change it if there were any
problems. I asked them how the hell they would know if there were
problems and predictably they had no real answer (and I could sense they
were miffed by that line of questioning). And I thought all technical
people were supposed to be able to grasp basic logic. Stupid me.

The epilogue was that when they finally released the (now) piece of
****, announcing it to the entire world, I tried it out in IE8
compatibility mode and it dutifully threw an exception and died. Why?
And this is the capper. Without even consulting me (the resident
browser scripting expert), they had changed a line of mine to use
hasAttribute where I had originally checked a DOM property. I guess
they thought that attribute methods were more "standard" or something.
Mother-****ing incompetent idiots. As you might imagine, above all
else, _that_ bit infuriated me the most. I did report the problem to
management and (weeks later) it got spackled over. But who knows how
many sales to IE users were lost in the interim? And I wonder how long
it would have sat like that if I hadn't said something. Stupid them.

And, of course, it no longer did anything useful in _any_ browser
without scripting. Though it was no longer an endless loading
animation, perhaps the new one was worse as it allowed the user to fill
out the whole form before they realized they were screwed (submitting
just put them back on an unpopulated form). And, of course, the layout
fell apart in anything less than 1280 by whatever. I don't think I've
ever used that resolution, so I can't say if it actually worked at that
either. It's the same old story. The developers think that all of the
end-users have (or _should_ have) the same exact setup as they do (and
if they don't, **** 'em).

So yeah, communicating with typical "modern" library-happy dip-****
developers is difficult. They just don't get it (and likely never
will). It's so "obvious" to them that libraries are the way to "just
get things done". Anyone who says otherwise is living in the past,
"programming assembler", "wasting time", etc. Furthermore, end-users
are expected to eventually "catch up" to their "advanced" designs, so
why worry about the odd stragglers? Sites like Ajaxian and
StackOverflow are full of these train wrecks, bantering about how
library abc changed their lives and how they'd never "go back" to
fighting with Javascript (of course not, they got knocked out in the
first round).

I suspect that most of them just don't know anything about software (let
alone cross-browser scripting) and can't be bothered to learn as it
would get in the way of taking money off gullible clients.
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      02-22-2010
Richard Cornford wrote:
> Scott Sauyet wrote:
>> On Feb 17, 11:04 am, Richard Cornford wrote:
>>> On Feb 16, 8:57 pm, Scott Sauyet wrote:

>>
>>>> I think that testing the selector engine is part of testing
>>>> the library.
>>>
>>> Obviously it is, if the 'library' has a selector engine, but that
>>> is a separate activity from testing the library's ability to
>>> carry out tasks as real world tasks don't necessitate any
>>> selector engine.

>>


Couldn't agree more with that.

A hand rolled QuerySelector is too much work. It is just not worth it.

IE botches attributes so badly that trying to get the workarounds
correct would end up contradicting a good number of libraries out there.

Many developers don't know the difference between attributes and
properties. Many of the libraries, not just jq, have attribute selectors
that behave *incorrectly* (checked, selected, etc).

For an example of that, just try a page with an input. jQuery.com
homepage will do fine:
http://docs.jquery.com/Main_Page

(function(){
var inp jQuery('input[value]')[1];
inp.removeAttribute("value");
// The same input should not be matched at this point,
// Because its value attribute was removed.
alert(jQuery('input[value]')[1] == inp);
})();

Results:
IE: "true"
FF: "false"

As a bookmarklet:
javascriptfunction(){var inp =
jQuery('input[value]')[1];inp.removeAttribute("value");alert(jQuery('input[value]')[1]
== inp);})();

By failing to make corrections for IE's attribute bugs, the query
selector fails with wrong results in IE.

Workarounds for IE are possible, but again, the amount of benefit from
being able to arbitrarily use `input[value]` and get a correct,
consistent, specified (by the Selectors API draft) result, is not worth
the effort in added code and complexity.

Instead, where needed, the program could use `input.value` or
`input.defaultValue` to read values and other DOM methods to find the
input, e.g. document.getElementById, document.getElementsByName, etc.

[...]

>>> Granted there are cases like the use of - addEventListener
>>> - where positive verification becomes a lot more difficult,
>>> but as it is the existing tests aren't actually verifying
>>> that listeners were added.

>>
>> Are there any good techniques you know of that would make it
>> straightforward to actually test this from within the
>> browser's script engine? It would be great to be able
>> to test this.

>


The only way of testing if an event will fire is to subscribe to it and
the fire the event.

Programmatically dispatching the event as a feature test is inherently
flawed because the important questions cannot be answered from the
outcome; e.g. will the div's onfocusin fire in when the input is focused?

> I don't know of anything simple. I think that the designers of -
> addEventListener - fell down badly here. It would have been so easy for
> that method to return a boolean; true for success; then if you attempted
> to add a non-supported listener it could return false from which you
> would know that your listener was going to be ineffective. Still, that
> is what happens when the people designing the specs have negligible
> practical experience in the field.
>


That design requires a definition for "non-supported listener."
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
My Library _passes_ TaskSpeed in IE < 7 David Mark Javascript 88 03-07-2010 01:18 AM
TaskSpeed results for My Library David Mark Javascript 90 02-11-2010 05:38 PM
Junit tests, setting up tests without having to create a billion methods xyzzy12@hotmail.com Java 8 02-28-2006 08:59 PM
Tests without study guides or practice tests? =?Utf-8?B?Q2hyaXNS?= Microsoft Certification 8 12-20-2005 04:59 AM
Constant.t fails 240 of 272 tests and recurs.t fails 1 of 25 tests on HPUX using perl 5.8.7 dayo Perl Misc 11 12-16-2005 09:09 PM



Advertisments