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 25 Feb 2010 21:58 toby.oconnell(a)gmail.com wrote: > 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. Right. Typically you need to know which functions will work long before you actually call them. > > 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. > } > } Yes, I prefer one-off's, but that's the basic idea. Who needs extraneous flags, which may get out of sync without constant vigilance by the developers (something jQuery is not noted for). > > (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.) Yes, I didn't quite follow the "do nothing" bit. I prefer not to create such false fronts as they fool the calling app into thinking there is something usable there (of course, depending on context, that may not matter). > > 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. Yes, you would have no way to know whether it is a win, lose or draw until it is too late. > > 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. The separate mechanism would get out of sync in short order. Why use two variables where one will do? And I don't know that it will allow for more terse code either. One way or the other, apps have to do some detection up front (which precludes dummy functions that obscure the needed details) and checking flags or the methods themselves seems to require the same amount of verbosity. Of course, most developers just assume everything works and in the three browsers/configurations they test, it appears to be a good assumption, so why bother with all of this "complicated" detection? They may not know programming, but they know what they like! ;)
From: Peter Michaux on 26 Feb 2010 00:26 On Feb 23, 2:38 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote: > On Feb 23, 2:32 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > > > That's crazy. Virtually everyone carries a mobile browser these days > > Where is your evidence? I would guess that the number of people who > access the web via mobile device is in the single-digit percentages. I don't think that "virtually everyone carries a mobile browser these days." I don't think that is even close to true. That said, if mobile devices are a single-digit percentage then that group can't be thrown out as unworthy. There are quite a few browser niches that are single-digit percentages and if you add them up and throw them out you are throwing out a significant percentage. > > Mobile browsers are important right now (and have been for years). > > They are somewhat important, to some people. Certainly not a priority > for most. Yet. I agree that mobile may not be essential for everyone yet but now that I have a cell phone it sure is nice when sites do work. Peter
From: David Mark on 26 Feb 2010 00:31 Peter Michaux wrote: > On Feb 23, 2:38 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote: >> On Feb 23, 2:32 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> >>> That's crazy. Virtually everyone carries a mobile browser these days >> Where is your evidence? I would guess that the number of people who >> access the web via mobile device is in the single-digit percentages. > > I don't think that "virtually everyone carries a mobile browser these > days." I don't think that is even close to true. Even the poorest of the poor have phones. Even the lamest phones have browsers, therefore... > > That said, if mobile devices are a single-digit percentage then that > group can't be thrown out as unworthy. There are quite a few browser > niches that are single-digit percentages and if you add them up and > throw them out you are throwing out a significant percentage. Right. > > >>> Mobile browsers are important right now (and have been for years). >> They are somewhat important, to some people. Certainly not a priority >> for most. Yet. > > I agree that mobile may not be essential for everyone yet but now that > I have a cell phone it sure is nice when sites do work. > Yes, and aggravating when they don't and you can see that it was strictly due to The Crazies and their arbitrary "decision" making process.
From: Peter Michaux on 26 Feb 2010 01:28 On Feb 25, 9:31 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > Peter Michaux wrote: > > I agree that mobile may not be essential for everyone yet but now that > > I have a cell phone it sure is nice when sites do work. > > Yes, and aggravating when they don't and you can see that it was > strictly due to The Crazies and their arbitrary "decision" making process.. Some web applications benefit greatly from drag-and-drop functionality. They benefit so greatly and the non-drag-and-drop version is so bad that the non-drag-and-drop version is never built. There are some some web applications that you could say *require* drag-and-drop: games, drawing programs. There is no financial incentive to building the non-drag-and-drop version. Drag-and-drop in a web page doesn't seem to work on my iPhone. So it isn't that the decision makers of the web page were "The Crazies". It is actually the phone and/or the phone's browser that is not up to the task. Peter
From: David Mark on 26 Feb 2010 01:58
Peter Michaux wrote: > On Feb 25, 9:31 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> Peter Michaux wrote: > >>> I agree that mobile may not be essential for everyone yet but now that >>> I have a cell phone it sure is nice when sites do work. >> Yes, and aggravating when they don't and you can see that it was >> strictly due to The Crazies and their arbitrary "decision" making process. > > Some web applications benefit greatly from drag-and-drop > functionality. I suppose. But it is rare that DnD would be anything more than a novelty enhancement for a Website. > They benefit so greatly and the non-drag-and-drop > version is so bad that the non-drag-and-drop version is never built. Okay. That's not a Website then. So the Website that links to it should use a script-generated link, perhaps even detecting certain features as well. Problem solved. :) |