What browser doesn't support ajax ?

[nameless]

What browser doesn't support ajax ?

I need a list of browser that doesn't support ajax.



Thanks ^_^

 

[Luuk]

Op 11-1-2010 20:51, nameless schreef:

What browser doesn't support ajax ?

I need a list of browser that doesn't support ajax.



Thanks ^_^

Here is is (between start and end):
<start of list>
</end of list>

 

[Lasse Reichstein Nielsen]

Op 11-1-2010 20:51, nameless schreef:

Here is is (between start and end):
<start of list>
</end of list>

What? No Netscape 1?
/L

 

[Lewis Perin]

What browser doesn't support ajax ?

I need a list of browser that doesn't support ajax.

Well, there's Lynx.

/Lew

 

[slebetman]

What browser doesn't support ajax ?

I need a list of browser that doesn't support ajax.

Thanks ^_^

1. Many very old browsers. Though most people can ignore this, you
sometimes need to deliver products to institutions/government
departments with old and outdated equipment with no budget to upgrade
but with enough budget to actually buy/use your product.

2. Ultra-lightweight modern browsers like Hv3: http://tkhtml.tcl.tk/hv3.html

3. Browsers with javascript turned off. Though this is getting rarer,
some programmers still do this. But this leads us to:

4. Firefox with NoScript installed and has a whitelist configured
which does not include your site. This is slightly more serious
because NoScript is one of the most popular Firefox extension. A lot
of people use it, not just developers.

5. Most text browsers like Lynx. Though people who prefer text
browsers really should be using Elinks compiled with Spidermonkey
which IIRC does support XMLHttpRequest.

As obvious from the above, these browsers are in the minority. But
except for number 1, the people using the browsers above are generally
very tech oriented people who tend to be a coveted demographics.

 

[Luuk]

Op 11-1-2010 21:43, Lewis Perin schreef:

Well, there's Lynx.

/Lew

The question was about "not supporting"

not about any text browser that are available....

 

[Matt Kruse]

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.

Matt Kruse

 

[slebetman]

Op 11-1-2010 21:43, Lewis Perin schreef:




The question was about "not supporting"

not about any text browser that are available....

Lynx is a browser that does not support Ajax thus directly answers the
question about "not supporting".

 

[David Mark]

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.

 

[David Mark]

What? No Netscape 1?
/L

Certainly not. I recently tried that browser with the test page for
My Library (which uses lots of Ajax) and it passed with flying
colors. They were nearly indistinguishable from later FF results.

 

[David Mark]

Don't forget about users with disabilities. As recent survey
demonstrates
(<http://webaim.org/projects/screenreadersurvey2/#javascript>), a
noticeable percentage of screen reader users browse with Javascript
disabled.

Which is only sane as screen readers and aural browsers are
notoriously bad with dynamic content (often unusable).

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();
}

No need to keep track of which browsers do what. Such lists are what
led to failures like Prototype, jQuery and YUI, which were baed on the
idea of keeping up with the lastest round of major desktop browsers.

 

[David Mark]

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;

if (API && API.Requester && typeof myAppStartup == 'function') {
myAppStartup();
}
</script>

In this case, the typeof test would work as well.

<script type="text/javascript">
if (typeof API == 'object' && API && API.Requester && typeof
myAppStartup == 'function') {
myAppStartup();
}
</script>

But outside of the global context, such a pattern can be poison. I
think it is easier to always declare variables. Some partial builds
of My Library will suppress variable declarations and use typeof tests
to compensate, which is something I mean to change soon, despite the
fact that it will lead to some extra dot operations (beats having
global properties impersonate missing locals).

 

[Garrett Smith]

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.

http://github.com/jquery/jquery/blob/23492fdf9fa6f2c3b8ee85d062fed74297f3c438/src/ajax.js#L181

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.

 

[David Mark]

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.

http://github.com/jquery/jquery/blob/23492fdf9fa6f2c3b8ee85d062fed74297f3c438/src/ajax.js#L181

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.

 

[David Mark]

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.

 

[David Mark]

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) {