My Library _passes_ TaskSpeed in IE < 7
in [JavaScript]
|
Prev: A good opportunity to investment
Next: FAQ Topic - Why does framename.print() not print the correct frame in IE? (2010-02-19)
From: David Mark on 28 Feb 2010 18:25 David Mark wrote: [...] > Note that this is a generic example. It is not specific (but is > similar) to My Library, which actually does something like this > internally. As a matter of fact, as it sits, My Library's show/hide > functionality is less than ideal as it actually does ignore effects > options on hide/show when effects are impossible. But when only > _specific_ effects are unavailable (e.g. fade), it is up to the > applications to avoid passing those effects functions in the options. > That's something I need to rearrange down the road. For now the > incongruity is simply documented. There actually is a flag on the > affected methods indicating whether the hide/show operation will be > immediate or progressive (the latter indicating that a callback can be > used). Affected methods include setElementHtml, changeImage, as well as > showElement and a few others that can optionally use effects and/or a > callback. > Actually, checking my documentation, I made that sound more complicated than it is, at least for showElement. Unless you consider environments that are lacking setInterval, the ability to do progressive hide/show is known at _build_ time (as it should be) as the showElement method itself would be pruned in environments lacking CSS support. As noted in the docs, this is not the case for setElementHtml and a few others, which is something I do need to address. You should be able to determine the capabilities of these methods at build time (at least as far as the callback goes) and not have to check the (async) flag property at call time.
From: Scott Sauyet on 1 Mar 2010 09:04 On Feb 28, 6:12 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > Scott Sauyet wrote: >> David Mark wrote: >>> Scott Sauyet wrote: >>>> For instance, this is certainly fine for me: >>>> >>>> API.roundCorners(myDiv); > >>>> And this is overkill: > >>>> if (API.roundCorners) { >>>> API.roundCorners(myDiv); >>>> } >>> No, you do _not_ do it that way. You do a one-time check at the start >>> for required methods. > >> Do you centralize all code that might need rounded corners, then? > > I don't think this is a good example feature as it is hard to imagine > code that hinges on rounded-corners. But yes, depending on the > complexity of the applications, you may need to break it up into > sections and use a different gateway for each section. 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: var myForm = /* ... */, myElt = /* ... */, myContainer = /* ... */; if (API.attachEvent &&API.validateForm && API.xhr && API.cloneElt && API.appendElt && API.roundCorners) { 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); API.roundCorders(newElt); }, error: function(msg) {/* ... */} }) } }); } 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? -- Scott
From: David Mark on 1 Mar 2010 18:38 Scott Sauyet wrote: > On Feb 28, 6:12 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> Scott Sauyet wrote: >>> David Mark wrote: >>>> Scott Sauyet wrote: >>>>> For instance, this is certainly fine for me: >>>>> >>>>> API.roundCorners(myDiv); >>>>> And this is overkill: >>>>> if (API.roundCorners) { >>>>> API.roundCorners(myDiv); >>>>> } >>>> No, you do _not_ do it that way. You do a one-time check at the start >>>> for required methods. >>> Do you centralize all code that might need rounded corners, then? >> I don't think this is a good example feature as it is hard to imagine >> code that hinges on rounded-corners. But yes, depending on the >> complexity of the applications, you may need to break it up into >> sections and use a different gateway for each section. > > 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: > > var myForm = /* ... */, > myElt = /* ... */, > myContainer = /* ... */; > > if (API.attachEvent &&API.validateForm && API.xhr && > API.cloneElt && API.appendElt && API.roundCorners) { > 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); > API.roundCorders(newElt); > }, > error: function(msg) {/* ... */} > }) > } > }); > } > > 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.
From: Ivan S on 2 Mar 2010 04:02 On Mar 2, 12:38 am, David Mark <dmark.cins...(a)gmail.com> wrote: > Scott Sauyet wrote: > > On Feb 28, 6:12 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > >> Scott Sauyet wrote: > >>> David Mark wrote: > >>>> Scott Sauyet wrote: > >>>>> For instance, this is certainly fine for me: > > >>>>> API.roundCorners(myDiv); > >>>>> And this is overkill: > >>>>> if (API.roundCorners) { > >>>>> API.roundCorners(myDiv); > >>>>> } > >>>> No, you do _not_ do it that way. You do a one-time check at the start > >>>> for required methods. > >>> Do you centralize all code that might need rounded corners, then? > >> I don't think this is a good example feature as it is hard to imagine > >> code that hinges on rounded-corners. But yes, depending on the > >> complexity of the applications, you may need to break it up into > >> sections and use a different gateway for each section. > > > 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: > > > var myForm = /* ... */, > > myElt = /* ... */, > > myContainer = /* ... */; > > > if (API.attachEvent &&API.validateForm && API.xhr && > > API.cloneElt && API.appendElt && API.roundCorners) { > > 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); > > API.roundCorders(newElt); > > }, > > error: function(msg) {/* ... */} > > }) > > } > > }); > > } > > > 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. 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? :)
From: RobG on 2 Mar 2010 07:14
On Feb 19, 6:43 am, David Mark <dmark.cins...(a)gmail.com> wrote: > 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. -- Rob |