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: Garrett Smith on 24 Feb 2010 17:43 Matt Kruse wrote: > On Feb 24, 4:08 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> In order to assess quality of solutions, real comparisons and >> cost-benefit analysis needs to be made. A real cost benefit analysis >> includes efficiency of outcome, flexibility of solution, long tern >> consequences. > [...] > > 3) A real analysis that considers all the factors and weighs them > appropriately is required to come to any meaningful conclusion. > > 4) Analogies suck. > Hey you started it with the generalization comparisons to buggy software that you use every day. So you want to get back on topic and discuss application problem solutions then? OK, I'm following. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 24 Feb 2010 18:53 Scott Sauyet wrote: > Matt Kruse wrote: >> 5) jQuery does not enable progressive enhancement, despite its claims > > In what way? The other arguments I recognize and give some credence > to, but I've never seen this one. > To abstract an unknown environment, you need a dynamic API. Think about it. How do you know if one of jQuery's wonder-methods will work, fail silently or blow up? The answer is that you don't until you try, which is too late. My Library takes care of all of the ugly DOM feature testing under the hood and exposes _only_ those methods that can work in the current environment. That way, all you have to do is use a simple gateway at the top of your application/enhancement. For example:- var API; if (API && API.setOpacity && API.attachMousewheelListener) { // Your fading, mousewheel-dependent app here } Now, what happens if you skip the gateway? For most features, in modern full-featured browsers, nothing at all (e.g. setOpacity is going to be there). But in lesser browsers, you may get an immediate exception, which is roughly what you can expect out of jQuery or the like in such environments. Of course, the others will be slightly worse as they may get further into your initialization before doing something ill-advised and may either fail silently or throw exceptions, depending on the methods' designs. It's a no-brainer, but it seems to be taking a while to catch on; over two years now and the other projects are still churning out static (and intellectually bankrupt) API's. You can't do that on the Web. ;)
From: Scott Sauyet on 25 Feb 2010 10:24 On Feb 24, 6:53 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > Scott Sauyet wrote: >> Matt Kruse wrote: >>> 5) jQuery does not enable progressive enhancement, despite its claims > >> In what way? The other arguments I recognize and give some credence >> to, but I've never seen this one. > > To abstract an unknown environment, you need a dynamic API. Think about > it. How do you know if one of jQuery's wonder-methods will work, fail > silently or blow up? The answer is that you don't until you try, which > is too late. [ ... [ But this is really just saying again that jQuery (and by extension, a number of the other popular libraries) has a perhaps myopic focus on a few versions of recent browsers. If you use it outside that narrow set, who know what havoc it will wreak? But within its "supported" browsers, is there any reason to say that it's not capable of progressive enhancement? I'm also curious about the dynamic API you present. Obviously that's one clear way to avoid failing calls to API methods. What are the advantages over the method that provides a static API that in the absence of browser support reverts to dummy code that does nothing, returns empty arrays or false results for any of its calls? -- Scott
From: David Mark on 25 Feb 2010 17:22 Scott Sauyet wrote: > On Feb 24, 6:53 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> Scott Sauyet wrote: >>> Matt Kruse wrote: >>>> 5) jQuery does not enable progressive enhancement, despite its claims >>> In what way? The other arguments I recognize and give some credence >>> to, but I've never seen this one. >> To abstract an unknown environment, you need a dynamic API. Think about >> it. How do you know if one of jQuery's wonder-methods will work, fail >> silently or blow up? The answer is that you don't until you try, which >> is too late. [ ... [ > > But this is really just saying again that jQuery (and by extension, a > number of the other popular libraries) has a perhaps myopic focus on a > few versions of recent browsers. Perhaps? That's all they can hope to handle and they more or less admit it. But that's nothing to shrug off. Just because some clueless library developers decide they "don't care" about browsers that came out last year (and this year's browsers will be dismissed next year, of course), because they really don't know what they are doing with cross-browser scripting, doesn't mean the public won't get pissed off when your site breaks in unexpected ways. By and large, they don't know John Resig and don't care what he thinks about their browsers. ;) > If you use it outside that narrow > set, who know what havoc it will wreak? Exactly. And it is a very _narrow_ set. They can't even handle IE8 in its default configuration (let alone compatibility mode). > But within its "supported" > browsers, is there any reason to say that it's not capable of > progressive enhancement? Yes, because they really don't know what they support. They only recently figured out they needed a try-catch around XHR creation. Previously it would blow up in certain IE configurations. So for years they were churning out versions that would fail in many corporate environments, but were blissfully unaware of the issue. There are plenty mode. Recently I pointed out that - removeAttr - when used to remove a COL/ROWSPAN attribute would blow up in _some_ of their "supported" browsers. Who knows if they tested in just a subset or they consider that to be an "edge attribute" Who knows? There's sure as hell nothing in the docs about it. :) And for years, they ignorantly claimed that their script would work with XHTML (it won't) and IE quirks mode (not a shot there either). And then there are queries on XML documents (e.g. XHR results). You guessed it. They made up stories out of thin air for years and then when it was pointed out that they were fairy tales, they "punted" (in their forum, not on the blog or in the docs). You can't trust them, period. > > I'm also curious about the dynamic API you present. Obviously that's > one clear way to avoid failing calls to API methods. What are the > advantages over the method that provides a static API that in the > absence of browser support reverts to dummy code that does nothing, > returns empty arrays or false results for any of its calls? > Think about it. How would that work at all? I suppose if it were a Hello World app... :) In other words, what would the user see? Some features fail silently, some blow up, some work, etc. That's no good. :(
From: toby.oconnell on 25 Feb 2010 21:40
On Feb 25, 7:24 am, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > On Feb 24, 6:53 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > > I'm also curious about the dynamic API you present. Obviously that's > one clear way to avoid failing calls to API methods. What are the > advantages over the method that provides a static API that in the > absence of browser support reverts to dummy code that does nothing, > returns empty arrays or false results for any of its calls? Usinging such a static API can keep code from blowing up but it can also obscure API misuse and cause other problems. IMO, The key feature of a dynamic API is fine-grained progressive enhancement, without a need to check the underlying feature support (e.g. jQuery.support.opacity) required by the API calls used. For example: function showEffect(el) { if (API.effectOne && API.effectTwo && API.effectThree) { // Super cool effect, supported by few browsers. } else if (API.effectOne && API.effectFour) { // Not as cool effect, supported by other browsers. } else if (API.showEl){ // Barebones effect. } else { // Do nothing. } } (Depending on the context in which this function is called, one might remove the 'else' condition and dynamically add this function itself by wrapping it in an appropriate if statement.) With a typical static API, it would be difficult or impossible to use fine-grained progressive enhancement because the first condition in the function above would execute with varying results. A library could provide a static API and provide a separate mechanism for determining browser support of each function, but I don't know that that would be advantageous in any way aside from allowing lazily- written, terser code. |