Legacy code/browser compatibility

[David Golightly]

This is just a quick poll for all you web devs out there: What
browsers do you test on/are concerned about compatibility with?
Obviously, you're going to test on current-generation browsers such as
IE6, IE7, Firefox 1.5/2, Opera 8/9, Safari 2, etc.

How old must a browser be before you stop worrying about it? Anybody
here still test on IE4?

Thanks,

David

[Randy Webb]

David Golightly said the following on 11/10/2006 2:50 PM:

This is just a quick poll for all you web devs out there: What
browsers do you test on/are concerned about compatibility with?
Obviously, you're going to test on current-generation browsers such as
IE6, IE7, Firefox 1.5/2, Opera 8/9, Safari 2, etc.

How old must a browser be before you stop worrying about it? Anybody
here still test on IE4?

John Stockton didn't "test", he *used* IE4, until about a month or so ago.

As for age of the browser? Who cares. That is what feature detection is for.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[VK]

David Golightly wrote:

This is just a quick poll for all you web devs out there: What
browsers do you test on/are concerned about compatibility with?
Obviously, you're going to test on current-generation browsers such as
IE6, IE7, Firefox 1.5/2, Opera 8/9, Safari 2, etc.

How old must a browser be before you stop worrying about it? Anybody
here still test on IE4?

<IMHO>
IE4 died years ago.
IE 5.x < IE 5.5 implemented the future ways in too coorved ways so died
too.
</IMHO>

<FACTS>
<!-- Strictly by the *current* usage priority -->
IE6.0
Firefox 1.5
IE7.0
Camino
Safari
Others
</FACTS>

[Richard Cornford]

David Golightly wrote:

This is just a quick poll for all you web devs out there:
What browsers do you test on/are concerned about
compatibility with? Obviously, you're going to test on
current-generation browsers such as IE6, IE7, Firefox 1.5/2,
Opera 8/9, Safari 2, etc.

That is really the wrong question. A sensible design process starts with
an appreciation of what the outcome is intended to achieve. So, for
example, the purpose of a general public access e-commerce (retailing)
web site is to maximise profits, while a specialist web application
(possibly running on an Intranet) achieves its purpose when the people
who are intended to use it can use it effectively.

In the first case needlessly excluding potential customers at the design
stage is not that good an idea, so it is advisable to design to
accommodate the largest possible customer base (baring in mind that a
combination of server-side scripting and HTML can accommodate *every*
browser that can display HTML and submit forms). Remember; it is not the
user's fault if you are unwilling to take their money off them, and
someone else will be willing to so it is not the user's problem either.

In the latter case it is possible to dictate that people who are going to
be using the web application must run, say, IE 6+ or a Mozilla/Gecko
browser, with javascript enabled, (as those are hardly arduous
restrictions and accommodate Windows, Mac and Unix/Linux OSs). The users
(or, more likely, their employers) will want to use the web application
and will be willing to use the browsers dictated in the configurations
required.

The question is not one of what is the minimum standard required for web
development but rather what is needed of any particular project and what
is required to achieve it. To make those design decisions in an informed
way it is necessary to know hat can be achieved.

An author conversant in the creation of genuinely cross-browser designs
is in a position to accurately estimate the effort (and associated costs)
of achieving the goals of the project they are working on. They may
decide that context only calls for support for some arbitrary set of
browsers/versions, but knowing what can be achieved means that not
achieving it is a decision rather than the consequences of their never
learning to do any better.

How old must a browser be before you stop worrying
about it? Anybody here still test on IE4?

As an importune part of cross-browser script design is clean degradation,
for such code I would always test on a number of browsers that I knew
could not actively support the script code, else I would not be sure that
the design degraded acceptably. Once code is designed to degrade
acceptably then the outcome on the most ancient browsers will be as
acceptable as it will be on the most modern browser with javascript
disabled.

Richard.

[David Golightly]

Richard Cornford wrote:

David Golightly wrote:

This is just a quick poll for all you web devs out there:
What browsers do you test on/are concerned about
compatibility with? Obviously, you're going to test on
current-generation browsers such as IE6, IE7, Firefox 1.5/2,
Opera 8/9, Safari 2, etc.

That is really the wrong question. A sensible design process starts with
an appreciation of what the outcome is intended to achieve. So, for
example, the purpose of a general public access e-commerce (retailing)
web site is to maximise profits, while a specialist web application
(possibly running on an Intranet) achieves its purpose when the people
who are intended to use it can use it effectively.

In the first case needlessly excluding potential customers at the design
stage is not that good an idea, so it is advisable to design to
accommodate the largest possible customer base (baring in mind that a
combination of server-side scripting and HTML can accommodate *every*
browser that can display HTML and submit forms). Remember; it is not the
user's fault if you are unwilling to take their money off them, and
someone else will be willing to so it is not the user's problem either.

In the latter case it is possible to dictate that people who are going to
be using the web application must run, say, IE 6+ or a Mozilla/Gecko
browser, with javascript enabled, (as those are hardly arduous
restrictions and accommodate Windows, Mac and Unix/Linux OSs). The users
(or, more likely, their employers) will want to use the web application
and will be willing to use the browsers dictated in the configurations
required.

The question is not one of what is the minimum standard required for web
development but rather what is needed of any particular project and what
is required to achieve it. To make those design decisions in an informed
way it is necessary to know hat can be achieved.

An author conversant in the creation of genuinely cross-browser designs
is in a position to accurately estimate the effort (and associated costs)
of achieving the goals of the project they are working on. They may
decide that context only calls for support for some arbitrary set of
browsers/versions, but knowing what can be achieved means that not
achieving it is a decision rather than the consequences of their never
learning to do any better.

How old must a browser be before you stop worrying
about it? Anybody here still test on IE4?

As an importune part of cross-browser script design is clean degradation,
for such code I would always test on a number of browsers that I knew
could not actively support the script code, else I would not be sure that
the design degraded acceptably. Once code is designed to degrade
acceptably then the outcome on the most ancient browsers will be as
acceptable as it will be on the most modern browser with javascript
disabled.

Richard.

So all that taken into consideration, there is inevitably a tradeoff
between shutting out potential customers using ancient browsers and the
development time needed to ensure that your features work on them.

Granted that JavaScript code is a spice added to a well-designed
website and that core functionality needs to be provided with core web
technologies such as you listed above (basic HTML and form submission),
even many older browsers are capable of rudimentary javascript
enhancements.

Can I take your reply as affirmation that you indeed test your CSS on
IE4, ensuring that the appearance is acceptable? How much time are you
willing to invest to ensure legacy browser compatibility on your
average general-purpose, broad-market e-commerce app, for instance?

[Richard Cornford]

David Golightly wrote:

Richard Cornford wrote:

<snip>

>An author conversant in the creation of genuinely
cross-browser designs is in a position to accurately
estimate the effort (and associated costs) of achieving
the goals of the project they are working on. They may
decide that context only calls for support for some
arbitrary set of browsers/versions, but knowing what
can be achieved means that not achieving it is a
decision rather than the consequences of their never
learning to do any better.

>>How old must a browser be before you stop worrying
about it? Anybody here still test on IE4?

As an importune part of cross-browser script design is
clean degradation, for such code I would always test
on a number of browsers that I knew could not actively
support the script code, else I would not be sure that
the design degraded acceptably. Once code is designed
to degrade acceptably then the outcome on the most
ancient browsers will be as acceptable as it will be
on the most modern browser with javascript disabled.

<snip>

So all that taken into consideration, there is inevitably
a tradeoff between shutting out potential customers using
ancient browsers and the development time needed to ensure
that your features work on them.

There is only a trade off in accommodating ancient browsers if it is
necessary to write code to actively accommodate them. If a system is
being designed to facilitate clean degradation then the work needed to
accommodate the most modern browsers with javascript disabled has
effectively accommodated those ancient browsers in some sense. If, for
example, your script is using DOM manipulation then the effort to provide
similar functionality on, say, Netscape 4, is considerable and the
results are still unlikely to be satisfactory, but not attempting to
actively execute script and instead falling-back to whatever represents
the designed clean degradation can satisfy the Netscape 4 user at zero ad
ditional effort. Zero effort in exchange for even fractional increased
turnover is a good trade off.

Granted that JavaScript code is a spice added to a
well-designed website and that core functionality
needs to be provided with core web technologies such
as you listed above (basic HTML and form submission),
even many older browsers are capable of rudimentary
javascript enhancements.

A case in point. Every scriptable browser that has ever understood what a
form element is has facilitated client-side form validation. There are
people who would suggest using methods like - getElementById - to access
form controls (often out of some sort of misguided sense of 'modernness'
or misinformed preference for the W3C DOM Core over an appreciation of
the whole of the W3C DOM and its possible facilities), and so the
creating of code that cannot work with IE 4, Netscape 4 and many other
browsers with similarly designed object models. From that starting
position providing form validation for the older scriptable browsers
pretty much requires an entire additional layer in the architecture, or
an entire alternative validation path.

From that position the trade off doesn't look very good. However, there
is a single pattern of form accessors use and submission control that was
introduced in the earliest browsers and has now been formalised in the
W3C HTML DOM. Authoring form validation to that one pattern gives you (or
can give you, so long as you don't get involved with the less
well/commonly implemented regular expression extensions) a one code fits
all script that will work on every browser from the most ancient still in
use to the most modern (and with W3C DOM formalisation can be expected to
work on all future HTML browsers as well). And the code written is
certainly no more complex that any alternative that attempted to use -
getElementById - exclusively, and cost much back compatibility in the
process. So here too the right design decisions up front can accommodate
those ancient browsers as well as the most modern for precisely zero
additional effort.

Can I take your reply as affirmation that you indeed test
your CSS on IE4, ensuring that the appearance is acceptable?

CSS? This is a javascript newsgroup, and your original question appeared
to about scripting.

How much time are you willing to invest to ensure legacy
browser compatibility on your average general-purpose,
broad-market e-commerce app, for instance?

That is a 'how long is a piece of string' question. If the expected
outcome on an ancient browser is the use of the clean degradation path
then there is not active client-side code to test. All that is necessary
then is to load the page(s) and verify that the degradation path is
properly taken. The work of seconds, literally.

Richard.

[Peter Michaux]

Richard Cornford wrote:

Can I take your reply as affirmation that you indeed test
your CSS on IE4, ensuring that the appearance is acceptable?

CSS? This is a javascript newsgroup, and your original question appeared
to about scripting.

CSS support is a big part of DHTML so I can see the relavance of the
question.

How much time are you willing to invest to ensure legacy
browser compatibility on your average general-purpose,
broad-market e-commerce app, for instance?

That is a 'how long is a piece of string' question. If the expected
outcome on an ancient browser is the use of the clean degradation path
then there is not active client-side code to test. All that is necessary
then is to load the page(s) and verify that the degradation path is
properly taken. The work of seconds, literally.

Deciding which browsers are to be considered ancient is a grey area.
Some statisitics may help with that decision perhaps even regardless of
reliability problems of those statistics.

http://www.w3schools.com/browsers/browsers_stats.asp

Today I was hoping to be able to push IE 5.5 down the degradation path
but if those usage numbers mean something then that stage doesn't seem
to have been reached yet.

Peter

[Richard Cornford]

Peter Michaux wrote:

Richard Cornford wrote:

<snip>

>>How much time are you willing to invest to ensure legacy
browser compatibility on your average general-purpose,
broad-market e-commerce app, for instance?

That is a 'how long is a piece of string' question. If the
expected outcome on an ancient browser is the use of the
clean degradation path then there is not active client-side
code to test. All that is necessary then is to load the
page(s) and verify that the degradation path is properly
taken. The work of seconds, literally.

Deciding which browsers are to be considered ancient is a
grey area. Some statisitics may help with that decision

"Some statistics"? If you want a statistic how about 42? Does that help,
or is there more to statistics than just numbers?

perhaps even regardless
of reliability problems of those statistics.

http://www.w3schools.com/browsers/browsers_stats.asp

That is just a page full of numbers. They don't become statistics until
they say what is being measured, how it is being measured, where it is
being measured and how the results are being interpreted. None of that
information is provided, and it never is when people quote statistics.

Today I was hoping to be able to push IE 5.5 down the
degradation path but if those usage numbers mean something
then that stage doesn't seem to have been reached yet.

You may conclude that, though that page does not contain any numbers
relating to IE 5.5, only IE 5. And even then how do you know that all
hits attributed to IE 5 do not originate with embedded IceBrowser 5 (or
any other browser that spoofs IE 5 in its default UA header)? Without
knowing what the numbers actually represent how can any valid conclusion
be drawn form them?

You risk looking at the numbers and just using them to reinforce/justify
your own prejudices. If you are going to make design decisions based
upon personal prejudices the least you should do is be honest about
doing so and not hide behind a list of meaningless numbers.

Richard.

[Peter Michaux]

Richard Cornford wrote:

>
You risk looking at the numbers and just using them to reinforce/justify
your own prejudices. If you are going to make design decisions based
upon personal prejudices the least you should do is be honest about
doing so and not hide behind a list of meaningless numbers.

Which prejudices do I have? When was I dishonest? I don't remember
doing any hiding.

Peter

[David Golightly]

Some statisitics may help with that decision perhaps even regardless of

reliability problems of those statistics.

http://www.w3schools.com/browsers/browsers_stats.asp

Their numbers are useful, but seem kind of suspect - I highly doubt
that Firefox has a nearly 30% market share! - but very telling are
their numbers for how many users have JavaScript turned off altogether.
If the wider audience of people who might arrive at your page via
Google is anywhere close to 10%, that speaks volumes for having
reliable non-javascript fallback code in place, and that JavaScript
isn't in a position to replace solid backend code, no matter how flashy
certain Ajax tricks may be (and I'm going to use them anyways).

Obviously, the best answer is "it depends on your particular audience",
as someone mentioned above. However, unless you're building a
specialized piece of software for a closed set of people, it's
difficult to know. I like to pay attention to my server logs to know
what people are using, but when you're just launching a new site, you
often don't have that advantage.

>
Today I was hoping to be able to push IE 5.5 down the degradation path
but if those usage numbers mean something then that stage doesn't seem
to have been reached yet.

This is tough, given that even Microsoft has ended support for IE 5.5:
http://support.microsoft.com/gp/lifean20

They would've ended support for 5.01 long ago as well; unfortunately,
as the default browser for Windows 2000, they've got government
contracts that ensure support for that dinosaur through 2010.

But IE 5 support isn't a big deal if you use a library that implements
JavaScript 1.5 functionality: Function.apply, Array.push, Array.pop,
these sorts of things (see
http://msdn.microsoft.com/library/de...nformation.asp)
Prototype provides this (though I don't personally use Prototype, for
other reasons), but there are also implementations of these functions
floating out there on the Internets that provide this and bring older
versions of JavaScript up to speed. (I have some on hand if anyone's
curious.) With these in place, you don't need to fret nearly as much
over feature support. The rest of your feature testing, such as the
Event model, you can wrap in helper objects. And I don't really bother
with writing code for DOM Level 0 support (pre-IE5), because I don't
see that the user base is there for it (see also Peter Paul Koch:
http://www.quirksmode.org/js/dom0.html). But that's just the way I do
things.

-David

[Richard Cornford]

Peter Michaux wrote:

Richard Cornford wrote:

>>
You risk looking at the numbers and just using them to
reinforce/justify your own prejudices. If you are going
to make design decisions based upon personal prejudices
the least you should do is be honest about doing so and
not hide behind a list of meaningless numbers.

Which prejudices do I have? When was I dishonest? I don't
remember doing any hiding.

I said you risked it, not that you had done so. However, as you
presented a page of 'browser usage statistics' as a seemingly serious
reference you do risk deluding yourself.

Richard.

[Matt Kruse]

Richard Cornford wrote:

Once code is
designed to degrade acceptably then the outcome on the most ancient
browsers will be as acceptable as it will be on the most modern
browser with javascript disabled.

The "most ancient" of browsers didn't even support object literals. Do you
avoid using them just in case someone is using Netscape 2?

There does need to be a reasonable cutoff at some point, where the language
implementation must support a certain set of features. DOM support is
another matter. Whether to use object literals, regular expressions, or
try/catch requires a decision be made to not support older browsers, because
you can't feature-detect for things like whether object literals are
supported. You'll get compilation errors if you use the featuers at all.

So, I don't think that the idea of supporting even "the most ancient
browsers" is even worth considering. If a browser has javascript enabled, it
should support object literals, regular expressions, function expressions,
and probably even try/catch. If not, then a developer can reasonably expect
the user to upgrade. IMO.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Richard Cornford]

Matt Kruse wrote:

Richard Cornford wrote:

Once code is
designed to degrade acceptably then the outcome on the most ancient
browsers will be as acceptable as it will be on the most modern
browser with javascript disabled.

The "most ancient" of browsers didn't even support object literals. Do you
avoid using them just in case someone is using Netscape 2?

With a system capable of clean degradation when scripting is
unavailable, script not executing because of a syntax error only
differs in its acceptability in that alternative a user of such an
ancient browsers may see a syntax error reported.

There does need to be a reasonable cutoff at some point, where
the language implementation must support a certain set of features.

There are certainly browsers that are far too old to even be
considered/tested. Netscapes <= 3 certainly come into that category.
But there is a huge difference between only supporting a fixed and
limited set of current browsers in particular configurations and
accepting that there will eventually come a time when all browsers stop
being used by anyone.

Richard.

[Matt Kruse]

Richard Cornford wrote:

With a system capable of clean degradation when scripting is
unavailable, script not executing because of a syntax error only
differs in its acceptability in that alternative a user of such an
ancient browsers may see a syntax error reported.

Not necessarily. The problem is that the inital branch is either script
supported or not. In the case of ancient browsers, script will be supported.
But once you enter into the 'script' branch and expect your code to execute
successfully (even if feature tests result in reverting back to non-script
mode), if it breaks you are out of luck.

Your statement implies that any syntax error introduced into working js code
will simply result in the page being useable in its non-script form, but
that's not true.

What about:
<form onsubmit="return [true,false][0]">

This is a dumb example, but makes the point - in a browser that doesn't
support object literals, a syntax error would result and the page would
neither be useable in the non-script form nor the script form. And yet you
can't do feature tests to find out if object literals are supported!

There are certainly browsers that are far too old to even be
considered/tested. Netscapes <= 3 certainly come into that category.

I agree, but others may draw the line in a different place than you, which
was the point of the original question.
You can surely script to support browsers older than NN3, but doing so would
require more effort than is practical, and the benefits would probably be
zero.

But there is a huge difference between only supporting a fixed and
limited set of current browsers in particular configurations and
accepting that there will eventually come a time when all browsers
stop being used by anyone.

The line is arbitrary. If there is a chance that 1 in 10,000 visitors to
your commerce site will be using NN3, would you choose to still support it,
and dumb down your code so no syntax errors would result? Or would it not be
worth it?

So if another person sees that IE5.5 visitors to their site are less than
..1%, and they want to use features that would cause syntax errors in that
browser, is it any more wrong for them to decide not to support it? If they
want to use /regex/ syntax in their code which will result in syntax errors
for old browsers, is that necessarily a bad decision?

Surely it's easier to provide backwards compatability for IE5.5 than for
NN3, but if neither gives any practical benefit, then why make any effort to
support either one? If this:
try{alert(['x'][0].match(/x/));}catch(e){}
causes a syntax error in a user's browser, then that user needs to upgrade!
:)

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Richard Cornford]

Matt Kruse wrote:

Richard Cornford wrote:

>With a system capable of clean degradation when scripting
is unavailable, script not executing because of a syntax
error only differs in its acceptability in that alternative
a user of such an ancient browsers may see a syntax error
reported.

Not necessarily. The problem is that the inital branch is
either script supported or not. In the case of ancient
browsers, script will be supported. But once you enter into
the 'script' branch and expect your code to execute
successfully (even if feature tests result in reverting
back to non-script mode), if it breaks you are out of luck.

Code that contains syntax errors is never executed.

Your statement implies that any syntax error introduced
into working js code will simply result in the page being
useable in its non-script form, but that's not true.

Yes it is.

What about:
<form onsubmit="return [true,false][0]">

This is a dumb example, but makes the point - in a browser
that doesn't support object literals

Array literals.

>, a syntax error would result

So the browser cannot create an onsubmit function, so it does not.

and the page would neither be useable in the non-script
form nor the script form.

If the page is useable on browsers that have scripting disabled it must
be possible to submit the form with a submit button of some sort, and as
the syntax error mans that no onsubmit handler exists the use of those
buttons will submit the form. In what sense is that "unusable"?

And yet you can't do feature tests to find out if
object literals are supported!

But don't need to so long as I use them liberally, as the resulting
syntax errors will grantee that any script element containing them will
not result in executable script.

>There are certainly browsers that are far too old to even be
considered/tested. Netscapes <= 3 certainly come into that
category.

I agree, but others may draw the line in a different place
than you,

I don't draw the line at all. The first question is what the project is
intended to achieve. The appropriateness of browser support/testing
decisions comes some way after determining that.

which was the point of the original question.

I don't think it was. It sounded like someone looking for an excuse for
never learning what could be achieved by hiding behind some notion of a
generally accepted (and not particularly rigorous) standard. That is an
attitude that results in clients being deprived of the true potential of
their web projects by developers who excuse not being able to do any
better by pointing to people who would do worse.

You can surely script to support browsers older than NN3,
but doing so would require more effort than is practical,
and the benefits would probably be zero.

But you can also write, for example, form validation that will work on
all browsers that know what a form is and allow it to be scripted, as no
more effort than it would take to write a script that only worked on IE
6+ and Firefox. There is no point gauging the trade-offs until you know
what is being traded off. Deciding up-front that no project could afford
to work with any but the latest browsers ensures that none of your
projects ever will, but not that they shouldn't have.

A few months ago we were presented with a reference to a page by a web
developer who had implemented an e-commerce site using AJAX and ruby on
rails and was sufficiently proud of the result to be boasting about it.
Yet when I visited the site in question with IE 6 the shopping cart did
not work, pretty much killing off its potential as an e-commerce site. I
doubt very much that hat developer had told his clients that there
potential to do business was one user configuration setting away from
being unusable on the most common browser in use, or that a little
server-side fall-back would keep the money coming in regardless.

And this example also said a great deal about the bogus notion of
"target audiences" and their relationship with browser use, as the site
was retailing web icons and so the "target audience" was web developers.
Web developers being probably the single group most likely to be using a
web browser through choice rather than by default (so often more unusual
browsers) and at the same time most likely to have exercised their
ability to configure their browsers (and so be using non-default
configurations).

>But there is a huge difference between only supporting a
fixed and limited set of current browsers in particular
configurations and accepting that there will eventually
come a time when all browsers stop being used by anyone.

The line is arbitrary. If there is a chance that 1 in 10,000
visitors to your commerce site will be using NN3, would you
choose to still support it,

I have never supported Netscape 3 (it pre-dates my involvement in web
development), but the clean degradation that I have designed into
scripts, in part to accommodate the 10-20% of users of the most modern
browsers who do not have javascript enabled/available) has accommodated
Netscape 3 with no extra effort on my part.

and dumb down your code so no syntax errors would result?

In browsers that ancient syntax errors do not represent any real issue.

Or would it not be worth it?

Any return form zero effort is worth it.

So if another person sees that IE5.5 visitors to their site
are less than .1%,

Is this a cross-browser site that would work fine with IE 5, or a site
that is already browser/versions dependent and producing 'chicken and
egg' statistics?

and they want to use features that would cause syntax
errors in that browser, is it any more wrong for them
to decide not to support it? If they want to use /regex/
syntax in their code which will result in syntax errors
for old browsers, is that necessarily a bad decision?

What is the site for? What is the context? What are the alternatives

Surely it's easier to provide backwards compatability for
IE5.5 than for NN3, but if neither gives any practical benefit,
then why make any effort to support either one?

"If" and "effort" can be determined in context, but not usefully
generalised.

If this:
try{alert(['x'][0].match(/x/));}catch(e){}
causes a syntax error in a user's browser, then that user
needs to upgrade! :)

But do you refuse to take someone's money off them because you cannot
show them a javascript alert message? Who exactly does that hurt?

Richard.

[Matt Kruse]

Richard Cornford wrote:

Code that contains syntax errors is never executed.

Sure it is:

function foo() {
alert('foo');
junk;
}
foo();

The actual command that is a syntax error is, of course, not executed.

Now imagine that foo() has been called from within your page, so you have
obviously determined that javascript is enabled. In your attempt to begin
feature testing, you use an object literal or regular expression that causes
the browser to die with a syntax error. You're now stuck. You're in the
javascript branch, so you assume your code will run as expected without
resorting back to plain old html behavior. But instead you get a syntax
error and code execution stops. You are left in an unknown state.

If the page is useable on browsers that have scripting disabled it
must be possible to submit the form with a submit button of some
sort, and as the syntax error mans that no onsubmit handler exists
the use of those buttons will submit the form. In what sense is that
"unusable"?

But if the handler function exists, and starts executing, then breaks, then
what?

But don't need to so long as I use them liberally, as the resulting
syntax errors will grantee that any script element containing them
will not result in executable script.

<a href=http://cnn.com onclick="return foo()">CNN</a>

In this case, foo() does get executed, even though it has a syntax error.
Here it happens to continue navigating because an error behaves the same as
returning false. But in other cases, it's not that simple.

I have never supported Netscape 3 (it pre-dates my involvement in web
development)

Really? I'd assumed you have been around for a while longer! I'm an
old-timer, then - I remember when NCSA Mosaic was released ;)

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[David Golightly]

which was the point of the original question.

I don't think it was. It sounded like someone looking for an excuse for
never learning what could be achieved by hiding behind some notion of a
generally accepted (and not particularly rigorous) standard. That is an
attitude that results in clients being deprived of the true potential of
their web projects by developers who excuse not being able to do any
better by pointing to people who would do worse.

The original question:

"How old must a browser be before you stop worrying about it? Anybody
here still test on IE4?"

Let me clarify. This is specifically in reference to JavaScript code
(apropos this list); this discussion (such as it has been) has ventured
way off topic into fallback form/basic HTML support, which though
essential, does not entail active JavaScript support or testing. Any
remedial JavaScript code or testing requires an investment of time that
you have to balance against the size of your potential userbase for a
given browser.

Again: How much time do you spend actually testing your JavaScript on
IE4?

[Richard Cornford]

Matt Kruse wrote:

Richard Cornford wrote:

>Code that contains syntax errors is never executed.

Sure it is:

function foo() {
alert('foo');
junk;
}
foo();

The actual command that is a syntax error is, of course,
not executed.

There is no syntax error in that code. There will be a runtime error
when the undeclared Identifier is evaluated.

Now imagine that foo() ...

<snip>

Let's see a real syntax error and its influence on code execution before
wasting time on this subject.

>If the page is useable on browsers that have scripting
disabled it must be possible to submit the form with a
submit button of some sort, and as the syntax error
mans that no onsubmit handler exists the use of those
buttons will submit the form. In what sense is that
"unusable"?

But if the handler function exists, and starts executing,
then breaks, then what?

Your handler example contained a potential syntax error, so no function
object could be generated from the code.

>But don't need to so long as I use them liberally, as
the resulting syntax errors will grantee that any script
element containing them will not result in executable script.

<a href=http://cnn.com onclick="return foo()">CNN</a>

In this case, foo() does get executed, even though it has a syntax
error.

Runtime error. So - foo - errors out, the onclick handier never returns
and the navigation is followed; fall-back.

Here it happens to continue navigating because an error
behaves the same as returning false. But in other cases,
it's not that simple.

But realistically most of the code is in external files and they are
never converted to executable code because the very old browsers
perceive syntax errors in the code, so the whole thing never gets past
the initialisation calls, if it gets that far (which it would not with
most of my code as those older browsers regard function expressions as
syntax errors as well and I tend to use function expressions for
initialisation). So the effect is largely indistinguishable from the
same script encountering a browser without script support.

>I have never supported Netscape 3 (it pre-dates my
involvement in web development)

Really? I'd assumed you have been around for a while
longer! I'm an old-timer, then - I remember when NCSA
Mosaic was released ;)

I had done no web development at all before late 2000. There was even a
time when I was impressed by your scripts, now long gone ;)

Richard.

[Richard Cornford]

David Golightly wrote:

which was the point of the original question.

I don't think it was. It sounded like someone looking for an
excuse for never learning what could be achieved by hiding
behind some notion of a generally accepted (and not
particularly rigorous) standard. That is an attitude that
results in clients being deprived of the true potential of
their web projects by developers who excuse not being able
to do any better by pointing to people who would do worse.

The original question:

"How old must a browser be before you stop worrying about it?

And it is still not a question that even needs to be asked until the
context in which you will be worrying about things has been established.

Anybody here still test on IE4?"

"Still" implies some absolute end to the idea of testing with any
particular browsers. While reality may have people not considering
testing with IE 4 for many years, and then seeing a reason for setting
one up to test for some specific context (indeed this group is one place
where that is very likely to happen as someone may start disputing the
behaviour of IE 4 in a couple of years and testing to see what it
actually did do may be seen as the best way of resolving such a
dispute).

Let me clarify. This is specifically in reference to JavaScript
code (apropos this list); this discussion (such as it has been)
has ventured way off topic into fallback form/basic HTML support,
which though essential, does not entail active JavaScript support
or testing.

Yes it does. Fall back may be for when javascript is unavailable but on
older browsers it is often necessary to determine that the necessary
features are not available on the client and actively choose to follow
the degradation path. And verifying that that happens properly is
necessary, if not time consuming.

Any remedial JavaScript code or testing requires an
investment of time that you have to balance against the
size of your potential userbase for a given browser.

That is largely a matter of opinion. As I have said, there are patterns
that, if employed, will tend to maximise active script support. The
difference between following them or not may be a considerable
difference in active browser support, but following them from the outset
does not require more work than not, and avoids any need for additional
effort to increase browser support.

Again: How much time do you spend actually testing your
JavaScript on IE4?

I have spent the last two years exclusively working on web applications
that have very specialist markets and user bases. None of those
applications are ever going to be exposed to IE 4 (or the public
Internet) so there is no point in my testing that code with IE 4. I
still have a partition on one of my computers that will boot to a
Windows version with IE 4 installed so I can test with it if, and when,
I see the need. Though I am so familiar with the IE 4 object model that
I know at the point of writing code how IE 4 would handle it so any
testing on IE 4 would never go beyond verifying that the expected
outcome was achieved, and that expected outcome would tend to be the use
of the fallback path as IE 4 is not capable of supporting any DOM
manipulation style scripting.

Richard.

[Peter Michaux]

David Golightly wrote:

>
Granted that JavaScript code is a spice added to a well-designed
website and that core functionality needs to be provided with core web
technologies such as you listed above (basic HTML and form submission),
even many older browsers are capable of rudimentary javascript
enhancements.

Not everyone thinks that JavaScript is just spice. 37signals is a now
famous and wealthy web development company. They use JavaScript as a
core functional part of the web page and don't worry about what will
happen when a user arrives without JavaScript or old JavaScript or
whatever not-up-to-date browser. Somewhere in the last few months DHH
(37signals founder and Rails author) said that (maybe directly in
response to a question of mine). 37signals is more interested in
skimming the cream off the web.

To view web pages there is a minimum requirement of having a computer
connected to the internet with a browser. Adding a modern browser with
JavaScript enabled to that list of requirements is not necessarily a
big additional requirement to add to the price of admission to a
website. For particular target groups of users it could mean that only
3% of users are shut out and even if the site is a ecommerece site that
might be a good trade off for reduction of development and testing
time.

I am interested in learning how to write truely cross-browser scripts
and am spending a lot of time thinking and experiementing with
techniques. That said, no one I have encountered that pays for web
development even cares about graceful degredation for old browsers.
They don't even want to pay for the time to test in those browsers. I
imagine as the organizations get more wealthy or prestegeous,like a
bank, or have money for pride, like Google might, it would make more
sense to achieve a higher degree of graceful degradation on a wider
range of browsers for more professional front.

Peter

[Peter Michaux]

David Golightly wrote:

Some statisitics may help with that decision perhaps even regardless of
reliability problems of those statistics.

http://www.w3schools.com/browsers/browsers_stats.asp

Their numbers are useful, but seem kind of suspect - I highly doubt
that Firefox has a nearly 30% market share!

They do address this point just at the bottom of the stats.

"W3Schools is a website for people with an interest for web
technologies. These people are more interested in using alternative
browsers than the average user. The average user tends to use Internet
Explorer, since it comes preinstalled with Windows. Most do not seek
out other browsers.

"These facts indicate that the browser figures below are not 100%
realistic. Other web sites have statistics showing that Internet
Explorer is used by at least 80% of the users."

Peter

[Peter Michaux]

Richard Cornford wrote:

>

Any remedial JavaScript code or testing requires an
investment of time that you have to balance against the
size of your potential userbase for a given browser.

That is largely a matter of opinion. As I have said, there are patterns
that, if employed, will tend to maximise active script support. The
difference between following them or not may be a considerable
difference in active browser support, but following them from the outset
does not require more work than not, and avoids any need for additional
effort to increase browser support.

The additional effort is definitely there. I am experiencing it
constantly. It is not the effort in implementation that is the
difference because if you know the best path to take then obviously you
just code that way. If two paths are known and each 50 lines long then
they will take the same time. The additional effort comes in the
developer education. Good browser scripting resources are scattered and
good information is mixed with bad in many/most cases. Learning to
script so that a wide range of browsers function acceptably is a very
challenging task. It is one I am undertaking and I am accumulating hard
won nuggets of information. The bigger task is blending all the
information together for a particular page and it would be much easier
if I considered only a small set of browsers. Assembling strategies for
browser scripting is tough.

Peter

[Matt Kruse]

Richard Cornford wrote:

There is no syntax error in that code. There will be a runtime error
when the undeclared Identifier is evaluated.

You are correct, I was being too general in what I thought of as a 'syntax
error'.

But it can happen that a syntax error happens in an external file, while the
actual event handler is defined in the page and uses a function in the
external file. In this case, the external file will cause a syntax error and
the in-page function will run until it causes a runtime error from trying to
call a function that wasn't defined. So my example isn't perfect, but it
shows a realistic potential result of a syntax error - identifier resolution
failing at runtime.

I do realize after thinking about it, though, that in most cases of syntax
errors the browser will behave like one without scripting.

I had done no web development at all before late 2000. There was even
a time when I was impressed by your scripts, now long gone ;)

Ah, the "apprentice" surpassing the "master"? heh. I like js and I wish I
could have devoted more time to becoming an expert in it over the years. But
my career caused me to focus on other things, and after the wife and kids
and cats and dogs, all I have is minimal "free time" to polish off what I do
write and make it available to the world. :)

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Randy Webb]

Peter Michaux said the following on 11/14/2006 9:52 PM:

Richard Cornford wrote:

>>Any remedial JavaScript code or testing requires an
investment of time that you have to balance against the
size of your potential userbase for a given browser.

That is largely a matter of opinion. As I have said, there are patterns
that, if employed, will tend to maximise active script support. The
difference between following them or not may be a considerable
difference in active browser support, but following them from the outset
does not require more work than not, and avoids any need for additional
effort to increase browser support.

The additional effort is definitely there.

It is definitely there, but, some people just stay with the "Its no cost
at all argument". It isn't always a question of being able to make
something degrade gracefully, some things just can't be made to degrade
gracefully without a ton of work.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[VK]

Peter Michaux wrote:

Not everyone thinks that JavaScript is just spice.

Most of server-side solutionists do :-) They are still dreaming of ol'
good time with JavaScript used to place the focus in the first form
element at max... OK maybe few more form helpers here and there, but
nothing more.

Disabled JavaScript is not an option for a long time already. I mean it
is a technical option, but not a choice option. Anyone having the
opposite opinion is welcome to disable JavaScript, browse the Web and
count down days (I would say hours) before she spits on any imaginary
security considerations and will return to the normal browsing.

For the browser support range it is a bit of "chicken and egg"
question. If my browser (however ugly old it is) is carefully covered
on most sites I'm visiting: then what stymulus do I have to ever
upgrade it? Most of regular users are extremely "lazy in updates" and
they will not spend the required 10-15 min unitil someone says them
straight and brute "get your a** to this link and get your free update"
(OK - not so brute, nicer and softer of course :-)

And there is nothing criminal in that: it was done many times before.
Say Netscape 4 was abandonned because sites stopped to produce
alternative versions for it. Technically I can think of no of modern
technologies/layouts which couldn't be implemented for NN 4. Extremely
time and money consuming - that's for sure; but no technical walls. But
sorry, someone doesn't have time or desire to upgrade: someone doesn't
have money or desire to support ancient models. The second one always
wins.

With the "graceful degradation" there is a catch either because I
personally do not clearly understand what graceful degradation would be
for an ajaxoid driven database front-end. Like a full functional
equivalent of it implemented server-side? Then what the reason to do
anything client-side?
Or some "basic functionality" kept? And what that basic functionality
would mean in the spelled case?
I personally suggest to remember the saying "one cannot get all money
in the world". Same way "one cannot satisfy all web users". 95% are OK,
4.5% are not, 0.5% completely screwed, 1 user falled down from the
chair, broke the leg so couldn't keep navigating my site (statistically
possible). I'm fine with this math.

[David Golightly]

For anyone still paying attention to this thread, I just found this
document, which reflects Yahoo's method of establishing browser
support:

http://developer.yahoo.com/yui/artic...ser-chart.html

I think it's pretty fair and is about what I find myself gravitating
toward.

-David

[Peter Michaux]

Hi David,

David Golightly wrote:

For anyone still paying attention to this thread, I just found this
document, which reflects Yahoo's method of establishing browser
support:

http://developer.yahoo.com/yui/artic...ser-chart.html

I keep an eye on this list but am surprised by some things.

Apple has passed Dell as the largest computer manufacturer (in USA?)
and many Apple users are still using OS X 10.3 which comes with Safari
1.3 and cannot use Safari 2.0. That means a lot of people are still
using Safari 1.3 but Yahoo! has decided not to give those users A-grade
support.

Someone wrote that Microsoft has government contracts until 2010 with
Windows 2000 which uses IE 5.5. I don't know how many users this
includes but IE 5.5 has been dropped from the YUI list.

Yahoo! has lots of dollars to spend on core technology like the Yahoo!
UI but they still settle for mediocre code in places.

The graded browser support idea is fine but I don't think that their
YUI implementation actually would give a C-grade browser an acceptable
degredation path.

For YUI, I think they would be better off listing for each library
which browsers are tested to work fine. For example, the Event library
(like you and I have been looking at in another thread) could be coded
to work with IE 4+ and Netscape 6+. I think that their implementation
will work with IE 5.5+ and Netscape 6+ but they won't even certify it
as working on Safari 1.3 or Firefox 1.0 which are relatively recent
browsers.

Also the YUI! functions will still define in browsers where the will
not function. For example, the YUI event library defines in IE 5 but
this browser doesn't have function.call() and will throw an error. I
like the idea of defining functions only in browsers where they will
work and it is what I'm trying to achieve with my event library and
others.

I think it's pretty fair and is about what I find myself gravitating toward.

It might be fair for the visitors using Yahoo! (which is probably a
good cross section of the web) but one site's users will not
necessarily indicate the browsers of another site's users.

I think that Yahoo! is too quick to drop certain browsers from the list
unnecessarily and this is probably motivated by lack of funding to the
YUI team. The team probably isn't given enough time to tinker and test.

Peter

[David Golightly]

Peter Michaux wrote:

Apple has passed Dell as the largest computer manufacturer (in USA?)
and many Apple users are still using OS X 10.3 which comes with Safari
1.3 and cannot use Safari 2.0. That means a lot of people are still
using Safari 1.3 but Yahoo! has decided not to give those users A-grade
support.

Yes, I actually know a poor soul who is still on Mac OS 9, where the
only browser is IE Mac 5.1. (Fortunately, she uses Hotmail, which also
hasn't changed since that browser was released back around 1999.) I've
got an older blueberry iBook running 10.3.9 so when I get the chance to
test on it (which is rare, since it has no wireless card and its
battery is dead), I also see only Safari 1.3, which has some pretty
nasty bugs in other regards. Safari's CSS support is nearly
unparalleled, but their JavaScript engine is crap, especially in 1.3.
Just an observation.

Someone wrote that Microsoft has government contracts until 2010 with
Windows 2000 which uses IE 5.5. I don't know how many users this
includes but IE 5.5 has been dropped from the YUI list.

That was me, and it was 5.01, not 5.5; I used to be a contractor with
MS testing IE and every bit of test code we wrote had to be supported
on Windows 2000/IE5.01, mostly for security fixes and the like. (5.5
for some reason has been dropped.) But any machine running Windows
2000 can install IE6 or Firefox, so I don't have a lot of sympathy for
end users who've decided to stick with IE 5. Even MS websites no
longer support IE5 as a front-line browser; msn.com looks like crap on
IE5. And even Google has a fallback to Mapquest-level non-Ajax
technology with IE5 on Google Maps and Gmail.

Yahoo! has lots of dollars to spend on core technology like the Yahoo!
UI but they still settle for mediocre code in places.

It's true, I'm not a personal fan of Yahoo, but they've acquired some
good sites recently like del.icio.us and flickr so at least they've got
a eye for where web technology is headed, which is more than you can
say for MS, which suffers from a chronic 1-year latency on web
technology and would rather not even bother with it; the web is
incompatible with their business model. But I digress.

Also the YUI! functions will still define in browsers where the will
not function. For example, the YUI event library defines in IE 5 but
this browser doesn't have function.call() and will throw an error. I
like the idea of defining functions only in browsers where they will
work and it is what I'm trying to achieve with my event library and
others.

I haven't looked at YUI too closely, but what we did at MS and what I
continue now as a web dev is implement missing methods for browser
support. I've posted elsewhere a definition of Function.apply and I
believe Function.call shouldn't be too much different in
implementation.

I think that Yahoo! is too quick to drop certain browsers from the list
unnecessarily and this is probably motivated by lack of funding to the
YUI team. The team probably isn't given enough time to tinker and test.

Neither am I :) When I'm on a budget, I need to have a specific list
of what target browsers I have time to test on and do bug fixes for.
Often a small client isn't going to pay for the 8-16 hours for testing
and bugfixes on a browser which serves only 2-3% of the market. Which
is why I first posed this question. Having a clear fallback - making
sure the site works first with no JavaScript - is fine for me. I don't
even have consistent access to IE5, much less earlier, and I don't feel
it's worth the trouble to get a copy of Win2K and dual-boot. There are
sites I write where JavaScript is just seasoning, and then there are
Ajax/DHTML sites that are really client-side apps and just won't work
at all with JavaScript off, so I don't bother (except to notify the
client to turn on JS). Having a solid client library goes a long way
to smoothing out the differences between modern browsers and assuring
some level of compatibility with older browsers.