From: David Mark on
Garrett Smith wrote:
> David Mark wrote:
>> On Jan 11, 8:00 pm, Matt Kruse <m...(a)> wrote:
>>> On Jan 11, 1:51 pm, nameless <xsatelli...(a)> wrote:
>>>> What browser doesn't support ajax ?
>>> IE6 with ActiveX disabled. That's probably the most common case you'll
>>> come across, of browsers that won't do ajax.
>> And another common case you will come across is lousy libraries (e.g.
>> jQuery) that failed to account for it.
> That got fixed a few days ago.

I know. Exactly one day after I mentioned it (for the hundredth time at
least). But how does that help the thousands of sites that were foolish
enough to buy into jQuery as a "cross-browser" crutch? It's just
another example of how foolish it is to invest time and money into
endless open source Beta tests. Think of how many additional
complexities have been added since I first reported the problem. How
can anyone even consider "upgrading" when the whole thing has been
turned inside out in the last year or so (e.g. the move from browser
sniffing to object inferences). And look how many other (unrelated but
interdependent) features they've twiddled with since then. Considering
it is only about 60K of script, it is obvious that companies should have
just written what they needed in the first place, rather than relying on
John Resig and co. to rewrite it every year, invalidating last years
browsers and scripts in the process.


Yea! The system "works". That's a git hub alright. Every time I go
there it brings FF to its knees. Sometimes it bogs down XP as well.
I'll bet it uses jQuery. ;)

> I still find the case for supporting "file:" protocol to be odd and
> commented on that in Github. XHR WD explicitly states that http and
> https are supported and that other implementations may support other
> protocols but doing so is "not covered by this specification". Expecting
> behavior that XHR WD defineS as nonstandard is risky.

Yes, XHR with file: is fairly useless, unless you are unlucky enough to
use a framework that loads all of its code via XHR. Then you need it,
but of course, the one I'm thinking of doesn't have it. It's like they
won't let anyone with a brain or the slightest understanding of the
issues near these efforts. They are all sure they've created something
great because they seem to work in "all (recent) browsers". Of course,
anything more than superficial testing exposes those misunderstandings.
Most of these stupid things don't even handle IE8 well. IE8 can work
like IE7, but still there are endless "debates" about when to end
"support" (that they don't have) for IE7 and under. A two-year-old
could see the fallacy in that, yet I've seen ostensibly grown men going
on about it for _months_ (while their stuff turns to dust due to the
pervasive browser sniffing and other blunders). :)

You notice how you never see _any_ of these guys in here? That can't be
a coincidence. I read one buffoon reminiscing about his "days hanging
out in CLJ", which I'm sure is either dreaming or posing. Do these
fools really think they have pat hands? Near as I can tell, most are
still resisting the "new" idea of abandoning browser sniffing. I
replaced Dojo's UA sniffing flags with object inference flags and that's
what they all focused on. None of them noticed that the new code didn't
use those flags at all. :) When I pointed that out, the question was
"what did you use then?" I told them to see for themselves, but
invariably they muttered something about not having enough time (but
they've got time to blither about not supporting browsers they never
figured out in the first place). These are not programmers at all.
Software designed and written by time-challenged non-programmers (with a
shaky grasp of the language to boot) is doomed.
From: Sherm Pendley on
nameless <xsatellitex(a)> writes:

> What browser doesn't support ajax ?


Arguably one of the most important "browsers" you'll never see.

From: David Mark on
Sherm Pendley wrote:
> nameless <xsatellitex(a)> writes:
>> What browser doesn't support ajax ?
> Googlebot.
> Arguably one of the most important "browsers" you'll never see.

Yes, that's an outstanding point. Ajax in the wrong hands can be a
disaster not just for usability, but for finding the document in the
first place. ;)
From: David Mark on
David Mark wrote:
> On Jan 13, 12:23 am, kangax <kan...(a)> wrote:
>> On 1/13/10 12:14 AM, David Mark wrote:
>>> On Jan 12, 10:41 pm, kangax<kan...(a)> wrote:
>> [...]
>>>> And of course there are browsers that _do support_ Javascript (and
>>>> possibly have it enabled) but are behind (corporate) firewalls/proxies
>>>> which strip SCRIPT elements.
>>> Yes, that's why you have to test everything. If your app has an entry
>>> point (in an external script) called myAppStartup, needs Ajax and uses
>>> My Library, the gateway would look like this:-
>>> if (API&& API.Requester&& typeof myAppStartup == 'function') {
>>> myAppStartup();
>>> }
>> Not `typeof API != 'undefined'`? We don't want ReferenceError's if
>> something failed loading ;)
> I was assuming there would be a declaration of API above. I've gotten
> into the habit of making each script block stand on its own (e.g. no
> implied globals of any kind).
> <script type="text/javascript">
> var API;

var API, myAppStartup;

Sorry for any confusion. Test is simplified to:-

if (API && API.Requester && myAppStartup) {