My Library _passes_ TaskSpeed in IE < 7

R

RobG

Tested IE5.5 and IE6 using that IETester thing as my other multi-IE box
crashed a week ago.  Perfect (as expected).  Can anyone else see a
problem in IE < 7?

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

For a bit of fun I tried Safari 1.0.3 (Mac OS 10.2.8). It wouldn't run
any of the tests at all. For the slickspeed tests, the only libraries
that completed any were jQuery 1.2 and YUI 2.7, which managed to
complete most of them. None of the others could complete any test, all
ending with 'error returned'.

The taskspeed tests at dojotookit.org would not run at all.

For the dojo slickpeed tests, jQuery 1.2.6, YUI 2.5.2 and Dojo 1.1.1
did reasonably well.

I won't be keeping this browser around for long, about to upgrade it
to Mac OS 10.4. I tried IE 5.2 but as expected, nothing ran at all.
 
D

David Mark

RobG said:
For a bit of fun I tried Safari 1.0.3 (Mac OS 10.2.8). It wouldn't run
any of the tests at all.

Yes, same for IE < 6. The testing framework itself isn't up to the
task. :(
For the slickspeed tests, the only libraries
that completed any were jQuery 1.2 and YUI 2.7, which managed to
complete most of them. None of the others could complete any test, all
ending with 'error returned'.

The query features are almost certainly pruned in that browser and
obviously the SlickSpeed framework doesn't perform any feature detection
on the API (e.g. checking to see if the $ function is available). I'd
be curious to know if $ (or API.getEBCS) is actually present in that
browser (in which case there is an undiscovered hole in the internal
feature detection).
The taskspeed tests at dojotookit.org would not run at all.

For the dojo slickpeed tests, jQuery 1.2.6, YUI 2.5.2 and Dojo 1.1.1
did reasonably well.

If they didn't pass (or fail in my case) _all_ of them then they didn't
do their jobs, allowing the calling app to get inconsistent results.
I won't be keeping this browser around for long, about to upgrade it
to Mac OS 10.4. I tried IE 5.2 but as expected, nothing ran at all.

The testing framework itself bombs on that browser. I was able to run
it in IE5.5 though (and virtually all of the squares were blacked out
but the last two columns, which were perfect). :)
 
S

Scott Sauyet

David said:
Scott said:
I'm not feeling very well and don't have the energy to respond to this
whole interesting post, but I do want to follow up on this point.
I'm not sure how you combine your gateways.  If you have multiple
features being used for one block of code, it's of course
straightforward to do this:
But to my eyes there's something wrong with this code.  I really want
to run everything else even if rounded corners are not supported.
That's just a nice tweak.  Of course it's easy enough to remove the
initial API.roundCorners check and add it around the one line where
it's needed, but you seem to be saying that these should all go at a
very high level.  What am I missing?

Join the club on not feeling well.  Briefly, you aren't missing
anything.  There are exceptions to every rule.

Hope you're feeling better today.

Okay, I think that clears up my confusion. I'm mixed about the
dynamic API; I can certainly see some benefits, but I'm not sold on
the additional complexities. I'm going to have to think about this
some more.

-- Scott
 
I

Ivan S

Well, I suppose one could call "API.roundCorners" function (and do
feature test) at the time of creating element (var myElt = /* ... */
<- here, I suppose), so that "API.cloneElement" would return element
that already has rounded element (or not, if feature is not
available).

This approach seems better to me, since there is separation of concern
(Ajax - styling).

Any thoughts about this? :)

Now I see I've made a mistake (and was unclear about what I was
thinking). It's not "has rounded element" but "has rounded corners".
Sorry about that, I haven't drank my first coffee at the time I was
writing post, so my brain wasn't functional. :)


If this:

"Of course it's easy enough to remove the
initial API.roundCorners check and add it around the one line where
it's needed"

does mean adding test like this (as I understood):

var myForm = /* ... */,
myElt = /* ... */,
myContainer = /* ... */;

if (API.attachEvent && API.validateForm && API.xhr &&
API.cloneElt && API.appendElt) {
API.attachEvent(myForm, "submit", function(evt) {
if (API.validateForm(myForm) {
API.xhr({
method: "POST",
url: myForm.action,
success: function(data) {
var newElt = API.cloneElement(myElt);
// update newElt using data;
API.appendElt(myContainer, newElt);

if (API.roundCorners) API.roundCorders(newElt);

},
error: function(msg) {/* ... */}
})
}
});
}


Maybe, something like this would be little better:


var myForm = /* ... */,

myContainer = /* ... */;

var myElt = /*...*/;

if (API.roundCorners) {
API.roundCorners(myElt);
}

if (API.attachEvent &&API.validateForm && API.xhr &&
API.cloneElt && API.appendElt) {
API.attachEvent(myForm, "submit", function(evt) {
if (API.validateForm(myForm) {
API.xhr({
method: "POST",
url: myForm.action,
success: function(data) {
var newElt = API.cloneElement(myElt);
// update newElt using data;
API.appendElt(myContainer, newElt);
},
error: function(msg) {/* ... */}
})
}
});
}

This way Ajax functionality isn't "polluted" with styling
functionality.

***

This isn't so much important, but me personally would make some kind
of separation between "this" and "that" functionality.



I'm no JS expert, so I don't know is this good approach (in some other
languages it is). Any thoughts, this time? :)
 
S

Scott Sauyet

Ivan said:
Ivan said:
Well, I suppose one could call "API.roundCorners" function (and do
feature test) at the time of creating element (var myElt = /* ... */
<- here, I suppose), so that "API.cloneElement" would return element
that already has rounded element (or not, if feature is not
available).
This approach seems better to me, since there is separation of concern
(Ajax - styling).
Any thoughts about this? :)

Now I see I've made a mistake (and was unclear about what I was
thinking). It's not "has rounded element" but "has rounded corners".
Sorry about that, I haven't drank my first coffee at the time I was
writing post, so my brain wasn't functional. :)

If this:

"Of course it's easy enough to remove the
initial API.roundCorners check and add it around the one line where
it's needed"

does mean adding test like this (as I understood):
[ ... ]
    if (API.attachEvent && API.validateForm && API.xhr &&
            API.cloneElt && API.appendElt) {
[ ... ]
var newElt = API.cloneElement(myElt);
             if (API.roundCorners) API.roundCorders(newElt);
    }

Maybe, something like this would be little better:

[ ... ]
   if (API.roundCorners) {
         API.roundCorners(myElt);
    }

    if (API.attachEvent &&API.validateForm && API.xhr &&
            API.cloneElt && API.appendElt) {
[ ... ]
              var newElt = API.cloneElement(myElt);
    }

This way Ajax functionality isn't "polluted" with styling
functionality.

Yes, if the rounded corners implementation is such that cloning the
relevant element copies along with it any scaffolding used for the
rounding, this would work. There are probably implementations which
wrap the target element in additional styled DIVs, and such
implementation wouldn't allow this technique.

But remember that this was just an example. David is suggesting that
a few high-level gatekeeper tests can be done on dynamic library
methods and then all code guarded by those gatekeepers could be
expected to function properly. While that works, the lack of
granularity bothers me, and I was trying to show a straightforward
example of where that would fall down. Rounded corners is one of my
favorite examples of this sort of thing. It's nice to have; designers
love it. But I refuse to add the necessary scaffolding to page
markup. I will do it in JS, but if it's not supported, they have to
live with square boxes! Entangling this nice-to-have feature with
more important ones, especially to turn them all off as a group, is
unacceptable.

David's response is fine: Sometimes you need more than just the high-
level gatekeepers.

I'd love to see largish examples of code written with this dynamic API/
gatekeeper method. It's simple enough for small things, but it's not
at all clear to me how it would scale.

-- Scott
 
I

Ivan S

Thanks for your answer. :)
I'd love to see largish examples of code written with this dynamic API/
gatekeeper method.  It's simple enough for small things, but it's not
at all clear to me how it would scale.

I like David's idea to abstract several functionality, something like
this:

if (API.attachEvent && API.validateForm && API.xhr && API.cloneElt &&
API.appendElt) {
if (API.roundCorners) {
API.myAjax = function() {
// // Ajax functionality with "round corners"
}
}
else {
API.myAjax = function() {
// Ajax functionality without "round corners"
}
}
}


This way API.myAjax can be called without worrying about having "round
corners" functionality or not. It looks nice (at least to me), but one
thing bugs me. If I have "n" (n - natural number greater than one)
functions that I want to abstract, I would have to make every possible
combination from "n" of them. Right?
That can be quite a work if "n" is large number. Is there any better
approach (question is for everyone :) )? Maybe object-oriented
approach would be better in cases like this?
 
D

David Mark

RobG said:
For a bit of fun I tried Safari 1.0.3 (Mac OS 10.2.8).

Confirmed that Safari 1.2 is fine for My Library and the rest bombed on
at least one test (and you can't be a little bit pregnant). I didn't
see the results myself, but if history is any indicator, the "at least
one" report likely translates to "many".

Now that I notice you were talking of Safari 1.0.3 and not 1.2, I am
almost certain that the query features (among others) are pruned, so
SlickSpeed is just blundering by trying to call a $ function that isn't
there.

I suspect I will go ahead and fix up these frameworks now that I am
hosting them on my site. First thing I want is for TaskSpeed to run in
IE5.0 (it does actually work in 5.5, for mine only though) and make it
detect when the API features it needs are absent. Same for SlickSpeed
as one of the first lines in slickspeed.js throws an exception.

//base test functions

function forEach(iterable, fn, bind){
for (var i = 0, j = iterable.length; i < j; i++) fn.call(bind,
iterable, i, iterable);
};

Like they really needed to use call. :(

But I need to make it do some rudimentary feature detection and skip and
mark columns that have degraded gracefully (won't happen West of the
last two at the moment, but perhaps in the future). IIRC, queries
degrade at version 6 in Opera, version 4 in NN and either 5.0 or 4 in
IE. Probably Safari 1.1 or 1.0 is the end of the line for them as well.
I'll find out. For those who don't understand the point of all of
this, read up on it the test-related discussion in my forum. If, after
that, you still don't get why I test "ancient" browsers, you probably
never will. :)

The CSS for these things is a mess too (what a shock) and I have some
ideas for styling columns that have at least one failure, cells that
total those disallowed columns, etc. It really needs to have _expected_
results as well. It seems silly that the SlickSpeed test must rely on
disagreements to determine there is a counting problem (what if they are
all wrong?) Other than "*", which can be affected by DOM
implementations and a couple of the more esoteric and less than formally
specified (and/or non-standard) selectors, the answers are not really
open to interpretation. With expected results, it will be possible to
mark wrong answers, rather than obscuring the results for the whole row.
 
D

Dr J R Stockton

In comp.lang.javascript message
...
I
...

You write a lot about something called "My Library", a term for which
Google finds 19,600,000 results.

Would it not be helpful to put, say, <http://www.cinsoft.net/mylib.html>
in signatures to your articles?

That introductory page does not say what language the library is written
in.

The link on that page to this newsgroup points to Google. However, this
is a Usenet newsgroup, and it would be good to have a link to
<before the Google one. A Web browser
should call up the user's newsreader software, if any, from that link.

There appears to be only one instance of the word "date" in that domain,
and that is on a page seemingly intended for readers of Spanish :) .
 
J

Jorge

There appears to be only one instance of the word "date" in that domain,
and that is on a page seemingly intended for readers of Spanish :)

Y ja, y ja, y ja. Feestro, te bi a partí el diodenor por mochu elo :)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,764
Messages
2,569,567
Members
45,041
Latest member
RomeoFarnh

Latest Threads

Top