Prev: Error getElementbyClassName
Next: string with apostrophes
From: David Mark on 13 Jan 2010 00:08
On Jan 11, 3:43 pm, Lasse Reichstein Nielsen <lrn.unr...(a)gmail.com>
wrote:
> Luuk <l...(a)invalid.lan> writes:
> > 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.
> > Here is is (between start and end):
> > <start of list>
> > </end of list>
>
> 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.
From: David Mark on 13 Jan 2010 00:14
On Jan 12, 10:41 pm, kangax <kan...(a)gmail.com> wrote:
> On 1/11/10 3:47 PM, slebetman wrote:
>
>
>
> > On Jan 12, 3:51 am, nameless<xsatelli...(a)gmail.com> wrote:
> >> 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.
>
> 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.
From: kangax on 13 Jan 2010 00:23
On 1/13/10 12:14 AM, David Mark wrote:
> On Jan 12, 10:41 pm, kangax<kan...(a)gmail.com> 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 ;)

[...]

--
kangax
From: David Mark on 13 Jan 2010 01:10
On Jan 13, 12:23 am, kangax <kan...(a)gmail.com> wrote:
> On 1/13/10 12:14 AM, David Mark wrote:
>
> > On Jan 12, 10:41 pm, kangax<kan...(a)gmail.com> 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;

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). ;)
From: Garrett Smith on 13 Jan 2010 02:02
David Mark wrote:
> On Jan 11, 8:00 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote:
>> On Jan 11, 1:51 pm, nameless <xsatelli...(a)gmail.com> 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.

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.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Error getElementbyClassName
Next: string with apostrophes