browser support for v0.2
Peter Michaux
Fork libraries use feature detection but some idea of which browsers
have which levels of support is still necessary.
-----------
These are fully supported browsers. That is the feature tests must
pass and there must be no syntax or runtime errors.
IE6+, FF2+, O9.5+, S3+
These browsers may or may not support certain Fork libraries. That is,
the feature tests may fail in these browsers and leave parts of Fork
undefined. These browsers will have no syntax errors. These browsers
will have no runtime errors.
IE5.0+, FF1+, NN6+, O8+, S1+
These browsers may report syntax errors leaving the library undefined.
If the feature tests do pass for a particular library, then the
library will have no runtime errors.
IE4+, NN4+
These browsers may report syntax errors leaving the library undefined.
If the feature tests happen to pass for a library then the library may
report runtime errors. These browsers just don't matter at all.
IE3-, NN3-
-----------
The only areas where I am unsure is in the fully supported list.
---
I don't want to include the 2.0.3- event workaround for preventDefault
that is in Fork v0.1 because it is bulky and 2.0.4 was release a long
time ago (January, 13 2006). Safari 2.0.4 was the last release of the
2.x series and superseded by 3.0.4 on October 26, 2007 available on
both OS X 10.4 and 10.5. Unfortunately discriminating between 2.0.3
and 2.0.4 is quite hard. There is no direct feature test for the
particular bug of interest. I've been searching for a couple days and
have only found a couple very unfortunate feature tests which could be
used to infer which of these browsers. They work but they require the
document body to be available and so cannot be done when the scripts
are loaded in the document head. I haven't been able to find a new
feature, or css property, etc that appeared for the first time in
2.0.4. How bad would it be to put the entire 2.x series down the
graceful degradation path?
Looking at some browser statistics (which are possibly very inaccurate)
http://marketshare.hitslink.com/report.aspx?qprid=2
Safari has a total market share of only 6.31%. Safari 2.x (a.k.a
Safari 41 on the list) has only 0.35% share of which some are probably
pre 2.0.4. So finding a successful inference technique for 2.0.4 may
only be enabling something like 0.25% of the market compared with
putting all 2.x users down the degradation path. That is only 2 or 3
users per 1000 users.
The w3schools stats
http://w3schools.com/browsers/browsers_stats.asp
show Safari having a total of only 2.6% which would put all Safari 2.x
users at extremely low amounts.
---
Opera 9.5 is the newest version of Opera. I can imagine fully
supporting Opera 9.0 as well. Unfortunately Opera 9.0 doesn't seem to
queue multiple XMLHttpRequests. It seems to just drop extras beyond
two simultaneous requests.
-----------
Any thoughts?
Peter
Peter Michaux
MobileMe.
http://www.infoq.com/news/2008/07/ie6_on_its_way_out
Peter
RobG
On Jul 26, 9:22 am, Peter Michaux <petermich...@gmail.com> wrote:
[...]
> It looks like Apple is not even supporting Safari 2.x for its
> MobileMe.
>
> http://www.infoq.com/news/2008/07/ie6_on_its_way_out
pretty disappointed in Apple's effort. The number of complaints about
the site indicates there are some serious flaws, e.g. the login page
incudes:
var destination_page = (browsertype.MobileSafari) ?
'iphone_welcome' : 'unsupported_browser';
//destination_page = (browsertype.IE && 7 == version) ?
'browser_coming_soon' : destination_page;
if (browsertype.IE && 7 == version && readCookie('ie7') !=
null) return;
if ((browsertype.IE && 7 != version) || (browsertype.Safari
&& version < 500 ) || (browsertype.Firefox && version < 2 ) ||
(browsertype.Firefox && version >= 2 && (isOldWin || isLinux) ) ||
(browsertype.Opera) || (browsertype.WebKit && !browsertype.Safari) ||
(browsertype.MobileSafari))
{
switch(language.substring(0, 2))
{
case 'en':window.location.href = "http://
www.me.com/"+destination_page+"/en/";
break;
case 'ja':window.location.href = "http://
www.me.com/"+destination_page+"/ja/";
break;
case 'fr':window.location.href = "http://
www.me.com/"+destination_page+"/fr/";
break;
case 'de':window.location.href = "http://
www.me.com/"+destination_page+"/de/";
break;
default:window.location.href = "http://
www.me.com/"+destination_page+"/";
break;
}
--
Rob
Peter Michaux
> On Jul 26, 9:22 am, Peter Michaux <petermich...@gmail.com> wrote:
> [...]
>
> > It looks like Apple is not even supporting Safari 2.x for its
> > MobileMe.
>
> >http://www.infoq.com/news/2008/07/ie6_on_its_way_out
>
> The MobileMe site does extensive browser and platform sniffing, I'm
> pretty disappointed in Apple's effort. The number of complaints about
> the site indicates there are some serious flaws, e.g. the login page
> incudes:
>
> var destination_page = (browsertype.MobileSafari) ?
> 'iphone_welcome' : 'unsupported_browser';
>
> //destination_page = (browsertype.IE && 7 == version) ?
> 'browser_coming_soon' : destination_page;
>
> if (browsertype.IE && 7 == version && readCookie('ie7') !=
> null) return;
>
> if ((browsertype.IE && 7 != version) || (browsertype.Safari
> && version < 500 ) || (browsertype.Firefox && version < 2 ) ||
> (browsertype.Firefox && version >= 2 && (isOldWin || isLinux) ) ||
> (browsertype.Opera) || (browsertype.WebKit && !browsertype.Safari) ||
> (browsertype.MobileSafari))
> {
> switch(language.substring(0, 2))
> {
> break;
> case 'ja':window.location.href = "http://www.me.com/"+destination_page+"/ja/";
> break;
> case 'fr':window.location.href = "http://www.me.com/"+destination_page+"/fr/";
> break;
> case 'de':window.location.href = "http://www.me.com/"+destination_page+"/de/";
That certainly does look pretty bad.
I do understand and like the general idea of a gateway script after a
login page to test necessary features are present in the browser. Then
subsequent pages inside the login area do not need to test features
which relieves quite a burden on the application programmer.
Are you also making an implicit comment about Safari 2.x support?
Peter
Declan
year, so there isn't really much point in worrying about it (except to
see whether or not it fails).
IE 5+ is probably more important as some companies still haven't
upgraded for fear of breaking internal intranets.
Also supporting Opera 9+ shouldn't be much different from supporting
9.5+, so should that be considered?
Peter Michaux
>
> Hasn't support for any version of Netscape been dropped by AOL this
> year, so there isn't really much point in worrying about it (except to
> see whether or not it fails).
Perhaps "support" is a used a bit differently with Fork than it is
with other browser scripting libraries.
With Fork, a _fully_ supported browser, is one that will pass all
feature tests and for which all features will work.
A browser like NN6 is not fully supported. It is supported in the
sense that it will never throw an error. Not a syntax error, or
runtime error. That is, it will degrade gracefully. The features of
Fork that will not work with NN6 will not be defined in NN6. Only the
features that will work in that browser will be defined in that
browser. Because of this (good) behavior, there is some sense of
support for NN6 as an application developer can build gracefully
degrading pages in NN6. No other library has anything related to this
type of behavior. So with regard to NN6, it isn't that it is fully
supported. It is supported just enough to enable graceful degradation.
A browser that will syntax error on a page is a slightly unsupported
browser. If the browser doesn't syntax error on the page then it
should behave like NN6 described above. This is only acceptable for
old browsers.
A completely unsupported browser is one in which features of Fork
would be defined but they would throw runtime errors. This is only
acceptable for very old browsers like NN3 or IE3. These browsers would
likely syntax error on just about every file in Fork so it wouldn't
really be a concern anyway.
> IE 5+ is probably more important as some companies still haven't
> upgraded for fear of breaking internal intranets.
True. In fact, I think there is something like support contracts for
Windows ME until 2010 and that OS shipped with IE5. (I can't remember
the exact details but it is in the comp.lang.javascript archives
somewhere.)
> Also supporting Opera 9+ shouldn't be much different from supporting
> 9.5+, so should that be considered?
The one issue I know of with Opera 9 before 9.5 is the queuing of
multiple XHR requests. It seems to dump any requests in excess of 2
(perhaps a configurable number.) I haven't looked into this yet. Help
with this research would be greatly appreciated :-)
Peter