Preloading images?

[Fabian]

var preload1 = new Image(); preload1.src = "/pic/yay.gif";
var preload2 = new Image(); preload2.src = "/pic/nay.gif";

The above is meant to preload image files, yes? Problem is, it doesnt
seem to be doing so in practice. Any idea where Im going wrong? Could it
be that things work differnetly when in an attached .js file?
--
--
Fabian
Visit my website often and for long periods!
http://www.lajzar.co.uk

[Thomas 'PointedEars' Lahn]

Fabian wrote:

var preload1 = new Image(); preload1.src = "/pic/yay.gif";
var preload2 = new Image(); preload2.src = "/pic/nay.gif";

The above is meant to preload image files, yes?
Yes, and depending on the (file) size of the image,
it is a Bad Thing as explained a few days ago.
Problem is, it doesnt seem to be doing so in practice.
How do you get that idea? Do you get any script errors?
Any idea where Im going wrong?
It is simply that at least on the Internet you cannot modify the user's
cache settings and what you observe here is possibly what happens if they
do not match what you assume.
Could it be that things work differnetly when in an attached .js file?

Depends on what you mean by `attached'.
PointedEars

[Fabian]

"Thomas 'PointedEars' Lahn" <Po*********@web.de> wrote in message
news:3F**************@PointedEars.de...

Fabian wrote:

var preload1 = new Image(); preload1.src = "/pic/yay.gif";
var preload2 = new Image(); preload2.src = "/pic/nay.gif";

The above is meant to preload image files, yes?
Yes, and depending on the (file) size of the image,
it is a Bad Thing as explained a few days ago.

The images in question at < 3kb each, and the page wont make sense if
they dont get displayed.

Problem is, it doesnt seem to be doing so in practice.

How do you get that idea? Do you get any script errors?

No errors I can tell anyway. Its at
www.lajzar.co.uk/en/index.html/animals.html (amongst others) if you want
to look. Since I have no idea where in the code a bug of this kind might
reside, it seems pointless posting any in the group at this stage. The
prime suspect was apparently the wrong one.
It is simply that at least on the Internet you cannot modify the user's cache settings and what you observe here is possibly what happens if they do not match what you assume.
Id have hoped I would at least be able to modify this particular user's
cache settings to enable preloading.

Could it be that things work differnetly when in an attached .js

file?
Depends on what you mean by `attached'.

<script src="blah.js" language="GuavaJuice">
</script>

That kind of attached. There is another way?
--
--
Fabian
Visit my website often and for long periods!
http://www.lajzar.co.uk

[Stephen]

Hi there, and apologies if this is a rather long-winded answer...
Fabian wrote:

"Thomas 'PointedEars' Lahn" <Po*********@web.de> wrote in message
news:3F**************@PointedEars.de...

Fabian wrote:

var preload1 = new Image(); preload1.src = "/pic/yay.gif";
var preload2 = new Image(); preload2.src = "/pic/nay.gif";

The above is meant to preload image files, yes?
Yes, [...SNIP...]

The images in question at < 3kb each, and the page wont make sense if
they dont get displayed.

Problem is, it doesnt seem to be doing so in practice.

How do you get that idea? [...SNIP...]

No errors I can tell anyway.

Because there's no code there to detect the error that's happening ...

Its at www.lajzar.co.uk/en/index.html/animals.html
Actually I found at
www.lajzar.co.uk/en/animals.html

(amongst others) if you want to look. Since I have no idea where in the code a bug of this kind might
reside, it seems pointless posting any in the group at this stage. The
prime suspect was apparently the wrong one.

It's not a javascript problem...

It is simply that at least on the Internet you cannot modify the user's
cache settings and what you observe here is possibly what happens if they
do not match what you assume.

Id have hoped I would at least be able to modify this particular user's
cache settings to enable preloading.

I do not believe the user's browser cache settings have anything to do
with whether the images "preload"

Could it be that things work differnetly when in an attached .js file?

No. Don't believe so ...

But here's what happened when I tried loading the "animals.html" page:

1. Browser requests animals.html
2. Server says 200 ok, here it is
3. Browser sees it needs css.css & requests it
4. Server says 200 ok, here it is
5. Browser requests "favicon.ico"
6. Server says 200 ok, here it is
[ don't get bored yet ...]
7. Browser sees it needs "game1.js" and requests it.
8. Server says 200 ok, here it is:
Note, your Apache server serves this as application/x-javascript.
This is probably as ok as anything, but it may be more usual to serve it
as text/javascript. Though this has nothing to do with the problem.

[This is the interesting part:]
9. Browser sees it needs yay.gif and requests it
10. Server says 404, can't find it (!!)
11. Browser sees it needs nay.gif and requests it
12. Server says 404, can't find it (!!)

Has nothing to do with cache; has to do with the server can't find the
images to serve. They are being requested as /pic/yay.gif (or
/pic/nay.gif) from www.lajzar.co.uk

When you call the checkAnswers() function, you construct the yay/nay
image sources as

"pic/yay.gif"
"pic/nay.gif"

That is, without the starting "/". In this case the images show. So the
answer is that in your preload code you're trying to fetch the images
from the wrong place.

I think you can put an onerror event handler on the image preloads to
detect the error:

preload1 = new Image();
preload1.onerror=function(){alert("No Preload-yay");};
preload1.src = "/pic/yay.gif";

ALthough that's not very pretty. And as you've coded the checkAnswers()
function (with the correct image location) the problem fixes itself
(even if image showing might not be as fast as you'd like).

HTH,
Stephen

[Fabian]

"Stephen" <ss*****@austin.rr.com> wrote in message news:W0omb.13978$%

Problem is, it doesnt seem to be doing so in practice.

How do you get that idea? [...SNIP...]

No errors I can tell anyway.

Because there's no code there to detect the error that's happening ...

I do my error checking mostly with the Mk I eyeball debugging system.
For added error checking potential, I have two running at the same time.
It is primitive, but it mostly works.
Its at

www.lajzar.co.uk/en/index.html/animals.html
Actually I found at
www.lajzar.co.uk/en/animals.html

As I said, it only *mostly* works :)
But here's what happened when I tried loading the "animals.html" page:
....
[This is the interesting part:]
9. Browser sees it needs yay.gif and requests it
10. Server says 404, can't find it (!!)
11. Browser sees it needs nay.gif and requests it
12. Server says 404, can't find it (!!)

Has nothing to do with cache; has to do with the server can't find the
images to serve. They are being requested as /pic/yay.gif (or
/pic/nay.gif) from www.lajzar.co.uk

When you call the checkAnswers() function, you construct the yay/nay
image sources as

"pic/yay.gif"
"pic/nay.gif"

ok, I am stupid. Thanks for finding the problem. A virtual rate of beer
is on its way to you now ;)
--
--
Fabian
Visit my website often and for long periods!
http://www.lajzar.co.uk

[Jim Ley]

On Sat, 25 Oct 2003 03:08:39 +0200, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote:

Fabian wrote:

var preload1 = new Image(); preload1.src = "/pic/yay.gif";
var preload2 = new Image(); preload2.src = "/pic/nay.gif";

The above is meant to preload image files, yes?
Yes,

No, it will depend on the HTTP headers sent with those gifs and user
settings.
and depending on the (file) size of the image,
it is a Bad Thing as explained a few days ago.

I think you should inform both the various W3 working groups who ares
putting the behaviour into the actual mark-up languages, they seem
happy that it is a good idea.

Jim.

--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Stephen]

Fabian wrote:

"Stephen" <ss*****@austin.rr.com> wrote in message news:W0omb.13978$%

>Problem is, it doesnt seem to be doing so in practice.

How do you get that idea? [...SNIP...]
No errors I can tell anyway.

Because there's no code there to detect the error that's happening ...

I do my error checking mostly with the Mk I eyeball debugging system.
For added error checking potential, I have two running at the same time.
It is primitive, but it mostly works.

Its at

www.lajzar.co.uk/en/index.html/animals.html

Actually I found at
www.lajzar.co.uk/en/animals.html

As I said, it only *mostly* works :)

But here's what happened when I tried loading the "animals.html" page:

...

[This is the interesting part:]
9. Browser sees it needs yay.gif and requests it
10. Server says 404, can't find it (!!)
11. Browser sees it needs nay.gif and requests it
12. Server says 404, can't find it (!!)

Has nothing to do with cache; has to do with the server can't find the
images to serve. They are being requested as /pic/yay.gif (or
/pic/nay.gif) from www.lajzar.co.uk

When you call the checkAnswers() function, you construct the yay/nay
image sources as

"pic/yay.gif"
"pic/nay.gif"

ok, I am stupid. Thanks for finding the problem. A virtual rate of beer
is on its way to you now ;)

Didn't by any means intend to imply you're stupid... I make that same
mistake far more than I'll admit in public :-). You know, at least, that
your initial observation was exactly right: the preload *wasn't* taking
place ... And thanks for the beer!

S.

[Thomas 'PointedEars' Lahn]

Stephen wrote:

It's not a javascript problem...

That's definitely true.

It is simply that at least on the Internet you cannot modify the user's
cache settings and what you observe here is possibly what happens if they
do not match what you assume.

Id have hoped I would at least be able to modify this particular user's
cache settings to enable preloading.

I do not believe the user's browser cache settings have anything to do
with whether the images "preload"

But they actually have. What achieved by preloading is only that there is an
Image object created and a resource is accessed by a HTTP request (if not on
the local file system.) That resource is saved in the cache and therefore
need not to be downloaded a second time if, and only if, it is then still in
the cache, which speeds up the display. Although JavaScript is a common way
to do this, you could also do the "preloading" by putting the image on a
previous page and, if supported, even by prefetching the resource with HTML
(`link' element) or CSS (`background-image' property).
PointedEars

[Thomas 'PointedEars' Lahn]

Jim Ley wrote:

[...] Thomas 'PointedEars' Lahn [...] wrote:

Fabian wrote:

var preload1 = new Image(); preload1.src = "/pic/yay.gif";
var preload2 = new Image(); preload2.src = "/pic/nay.gif";

The above is meant to preload image files, yes?

Yes,

No, it will depend on the HTTP headers sent with those gifs and user
settings.

I also wrote that implicitely. The above is in fact *meant*
to preload images. The result does not negate the intent.

and depending on the (file) size of the image,
it is a Bad Thing as explained a few days ago.

I think you should inform both the various W3 working groups who ares
putting the behaviour into the actual mark-up languages, they seem
happy that it is a good idea.

By putting the functionality into recommendations, it is by no means said
that you should use that feature when not appropriate. It merely provides
the possibility to use the feature. Unless there are no more analog modems,
it seems at least questionable to use that particular feature on the Web,
especially when done without regard to the amount of data to be transmitted.
PointedEars, connected by a 56k modem

[Thomas 'PointedEars' Lahn]

Fabian wrote:

"Thomas 'PointedEars' Lahn" [...] wrote [...]

Fabian wrote:

> var preload1 = new Image(); preload1.src = "/pic/yay.gif";
> var preload2 = new Image(); preload2.src = "/pic/nay.gif";
>
> The above is meant to preload image files, yes?
Yes, and depending on the (file) size of the image,
it is a Bad Thing as explained a few days ago.

The images in question at < 3kb each,

That is acceptable to me as user of a 56k analog modem.
and the page wont make sense if they dont get displayed.

See the problem? What if the user has disabled images? What if they use a
user agent that cannot display images, let's say a text browser or a Braille
line? The `alt' attribute is your friend. If that does not suffice, you have
greater problems with your concept than that your images do not preload.

It is simply that at least on the Internet you cannot modify the
user's cache settings and what you observe here is possibly what
happens if they do not match what you assume.

Id have hoped I would at least be able to modify this particular user's
cache settings to enable preloading.

No, forget about it. My cache is *my* cache.
How dare you change what I find appropriate?

> Could it be that things work differnetly when in an attached .js
> file?

Depends on what you mean by `attached'.

<script src="blah.js" language="GuavaJuice">
</script>

That kind of attached. There is another way?

`Attached' could have meant that the .js file is an attachment of an
evil[tm] HTML e-mail and other causes of the problem would have had
to be considered.
PointedEars

[Jim Ley]

On Sat, 25 Oct 2003 15:41:46 +0200, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote:

I also wrote that implicitely. The above is in fact *meant*
to preload images. The result does not negate the intent.
No, it's a side effect really....
By putting the functionality into recommendations, it is by no means said
that you should use that feature when not appropriate. It merely provides
the possibility to use the feature. Unless there are no more analog modems,
it seems at least questionable to use that particular feature on the Web,
especially when done without regard to the amount of data to be transmitted.

How strange, because of certain pecularities in your environment you
choose to impose a behaviour on everyone - it would be trivial of you
to block the preloading, and that would make much more sense all
around.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Fabian]

"Thomas 'PointedEars' Lahn" <Po*********@web.de> wrote in message

and the page wont make sense if they dont get displayed.
See the problem? What if the user has disabled images? What if they

use a user agent that cannot display images, let's say a text browser or a Braille line? The `alt' attribute is your friend. If that does not suffice, you have greater problems with your concept than that your images do not

preload.

Trust me, this is a complete and utter non-issue. This section is being
written with Japanse schoolchildren in mind, particularly the school
computer networks. The school computers in every school I have visited
use Explorer 6 with all normal display options on. As for their home
computers, lets just say that Japanese kids arent noted for thinking
creatively. I can be fairly certain what their home set up is because it
simply wouldnt occur to them that they can change the settings without
permission from tech support. That goes double for their parents.

If they are using a text browser with braille support, learning English
would be the least of their problems for this hypothetical Japanese kid.

If anything, the main useability problem is too much text and not enough
pictures.

Id have hoped I would at least be able to modify this particular user's cache settings to enable preloading.

No, forget about it. My cache is *my* cache.
How dare you change what I find appropriate?

Perhaps I was writing too subtlely. "This particular user" is a subtle
way of referring to myself.
--
--
Fabian
Visit my website often and for long periods!
http://www.lajzar.co.uk

[Thomas 'PointedEars' Lahn]

Jim Ley wrote:

[...] Thomas 'PointedEars' Lahn [...] wrote:

By putting the functionality into recommendations, it is by no means said
that you should use that feature when not appropriate. It merely provides
the possibility to use the feature. Unless there are no more analog modems,
it seems at least questionable to use that particular feature on the Web,
especially when done without regard to the amount of data to be transmitted.

How strange, because of certain pecularities in your environment you
choose to impose a behaviour on everyone - it would be trivial of you
to block the preloading, and that would make much more sense all
around.

Your sarcasm aside, I do not impose behaviours on everyone because of my
needs. That I am currently using an analog modem (I had the opportunity to
connect via a 10 MBit LAN until a month ago) emphasizes only that I do know
of what I am writing about when asking to reconsider to use certain
features. There are of course more than one user with an analog modem. What
a Web author wants are visitors. Thus it is not wise to disregard the needs
of *any* visitor if this can be prevented. If you read standards and (W3C)
recommendations thourough, you find this attitude expressed in the features
they describe.
PointedEars

[Jim Ley]

On Sat, 25 Oct 2003 16:52:31 +0200, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote:

Your sarcasm aside, I do not impose behaviours on everyone because of my
needs.
So why suggest that other people stop using preloading, an important
usability aid for a great number of people, because you're blessed
with 28K or so connection I've often used 9.6K and shared 28k
connection between 10 people or more. I just modified by
browser/behaviour so as it didn't harm me, you're free to do the same.
What
a Web author wants are visitors. Thus it is not wise to disregard the needs

Preloading is a lot more relevant to low bandwidth users, as it
ensures that the usability increase still works, by ensuring the
materials are available. In high bandwidth situations, it's hardly
relevant as the content comes down, but as I say - it's easy enough to
disable.

Yes authors want visitors, and yes their site needs to be usable -
preloading can provide that - obviously forcing large images etc. down
peoples throats is bad, but that is wholly irrelevant to preloading.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Thomas 'PointedEars' Lahn]

Jim Ley wrote:

[...] Thomas 'PointedEars' Lahn [...] wrote:

Your sarcasm aside, I do not impose behaviours on everyone because of my
needs.
So why suggest that other people stop using preloading,

I have only suggested that they think about it before using it.
I just modified by browser/behaviour so as it didn't harm me, you're free
to do the same.

That may be OK to you, but who of us is now imposing behaviors on others
here when you write that it is therefore also OK to others? Do you really
think that someone except of you will *ever* adjust their settings to fit
for only *one* particular website? There are plenty of other websites out
there! Besides, sometimes it is only possible for the administrator to
change such settings, have you considered that?

What a Web author wants are visitors. Thus it is not wise to disregard
the needs

Preloading is a lot more relevant to low bandwidth users, as it
ensures that the usability increase still works, by ensuring the
materials are available.

Since users pay for downloaded data as well as connection time I doubt
they would appreciate it if their download or connection time quota is
spoiled by downloading (a bunch of navigational) images they do not want
because they do not need them (and vice-versa.) Multimedia experience is
not everything, sometimes you are just looking for useful information.
PointedEars

[Jim Ley]

On Sat, 25 Oct 2003 19:49:36 +0200, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote:

Jim Ley wrote:

So why suggest that other people stop using preloading,
I have only suggested that they think about it before using it.

That is not what you said in this thread.
That may be OK to you, but who of us is now imposing behaviors on others
here when you write that it is therefore also OK to others?
Neither of us... All web authoring is suggesting, suggesting
something be preloaded can be important for usability, telling people
not to do is it is not helpful.
Since users pay for downloaded data as well as connection time I doubt
they would appreciate it if their download or connection time quota is
spoiled by downloading (a bunch of navigational) images they do not want
because they do not need them (and vice-versa.)

Where did I say anything about using images for navigation - that's
most certainly a really bad idea, and I can fully agree with you that
it is bad - but what's that got to do with preloading images, other
than the fact some people misuse it in that way?

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Stephen]

Thomas 'PointedEars' Lahn wrote:

Stephen wrote:

[...snip...]

I do not believe the user's browser cache settings have anything to do
with whether the images "preload"

But they actually have.

Actually, I stand by the statement I made, where "preload" is doing what
the OP originally wrote about:

var preload1 = new Image(); preload1.src = "/pic/yay.gif";
var preload2 = new Image(); preload2.src = "/pic/nay.gif";

This is based on my observations and is not simply an assertion.
What achieved by preloading is only that there is an
Image object created and a resource is accessed by a HTTP request (if not on
the local file system.)
Pretty much ok, but for that "file system" part. The term "cache" is
really a bit ambiguous: there is disk cache and memory cache. So the
browser uses memory for storing some of its "stuff" -- and it is into
memory that the "preloaded" images go; they may also get stored in disk
cache. Even if I turn off disk caching the memory part still works. By
my observation, this even works in Opera, where one can explicitly "turn
off" memory caching.
That resource is saved in the cache and therefore
need not to be downloaded a second time if, and only if, it is then still in
the cache, which speeds up the display.

It is being in memory that makes rollovers work really fast. Even
fetching a (disk)-cached copy could be too long. The point is to make
rollovers appear instantaneous.

Again, I do not believe there is any user browser cache setting that has
anything to do with whether the images "preload".

Of course, a clear, unambiguous example illustrating a user setting for
browser cache that causes "preloads" to fail could change my mind on the
matter.

Regards,
Stephen

[Fabian]

"Thomas 'PointedEars' Lahn" <Po*********@web.de> wrote in message

Since users pay for downloaded data as well as connection time I doubt
they would appreciate it if their download or connection time quota is
spoiled by downloading (a bunch of navigational) images they do not want because they do not need them (and vice-versa.) Multimedia experience is not everything, sometimes you are just looking for useful information.

For Japanese schholchildren, my target audience, multimedia is king. A
plain text site would have them fall asleep in seconds.
--
--
Fabian
Visit my website often and for long periods!
http://www.lajzar.co.uk

[Thomas 'PointedEars' Lahn]

Fabian wrote:

"Thomas 'PointedEars' Lahn" <Po*********@web.de> wrote in message

Since users pay for downloaded data as well as connection time I doubt
they would appreciate it if their download or connection time quota is
spoiled by downloading (a bunch of navigational) images they do not

want

because they do not need them (and vice-versa.) Multimedia experience

is

not everything, sometimes you are just looking for useful information.

For Japanese schholchildren, my target audience, multimedia is king. A
plain text site would have them fall asleep in seconds.

Read again. I did not write that you must discard images.
HTH

PointedEars

P.S.:
Your comb-like quoting (correct translation?) sucks. Alas I do not know
a non-German tutorial/FAQ for Outlook Express (Google should provide one)
but I suggest you use MorVer or OE-Tools to avoid that in the future as
many people have before.

[Fabian]

"Thomas 'PointedEars' Lahn" <Po*********@web.de> wrote in message

P.S.:
Your comb-like quoting (correct translation?) sucks. Alas I do not know a non-German tutorial/FAQ for Outlook Express (Google should provide one) but I suggest you use MorVer or OE-Tools to avoid that in the future as many people have before.

As I have no idea what comb-like quoting is, and as you are the first
person ever to comment unfavourably on my quoting style, I think I shall
pass on changing my modus operandi.
--
--
Fabian
Visit my website often and for long periods!
http://www.lajzar.co.uk

[Thomas 'PointedEars' Lahn]

Fabian wrote:

"Thomas 'PointedEars' Lahn" <Po*********@web.de> wrote in message

P.S.:
Your comb-like quoting (correct translation?) sucks. Alas I do not know

^^

a non-German tutorial/FAQ for Outlook Express (Google should provide

one)

^^

but I suggest you use MorVer or OE-Tools to avoid that in the future

as

^^

many people have before.

As I have no idea what comb-like quoting is,

I have marked it for you here.
and as you are the first person ever to comment unfavourably on my
quoting style,
There is a first time for everything. [psf 3.3]
I think I shall pass on changing my modus operandi.

I did what you should have done and used Google before posting:

http://flash.to/oe-quotefix/
HTH & F'up2 poster

PointedEars
--
How do I quote correctly in Usenet?
http://www.netmeister.org/news/learn2quote.html

[Fabian]

"Thomas 'PointedEars' Lahn" <Po*********@web.de> wrote in message

but I suggest you use MorVer or OE-Tools to avoid that in the

future

as ^^ many people have before.

As I have no idea what comb-like quoting is,

I have marked it for you here.

We call that broken quotes, or wrapped quotes. Take your pick.

I think I shall pass on changing my modus operandi.

I did what you should have done and used Google before posting:

Why do you say I should have done it? Why am I under some kind of
obligation? I am following teh standards by setting the line wrap length
at 72 characters. The question is, why aren't you, and presumably, that
program, following that standard?
http://flash.to/oe-quotefix/

Ah, I see what you're talking about now. I shan't be downloading that
program. You see, while it may well appear that I am using msoe, I am in
fact using a custom news reader that I wrote myself, which creates the
headers to mimic msoe as a stealth move. I would be surprised if this
program of yours is compatible.

Either that or:

I have no desire to install additional programs on my computer, no
matter how inobtrusive they may appear. It appears this program could
manipulate my text when I post some code for example, which would not be
what I want.

Either that or:

Every newsreader (since about 1973 or so anyway) has an option to set
the line length at which it automatically wraps text, and this accepts a
value of 80 or less (for backwards compatibility with text only
readers). Every group I have ever seen recomends setting this value to
72, which will allow 4 levels of quoting before any quoting gets broken.
This is in fact the default in msoe iirc. It is certainly the current
setting on my machine (just checked), and I dont recall ever changing
it. So if my quoting gets broken after a single level of quotes, the
fault lies with the previous poster for not following the standard, not
with me.

Take your pick.

[posted, not emailed, to save bandwidth. You do read the group, dont
you? No need to set headers to force an email reply too.]

--
--
Fabian
Visit my website often and for long periods!
http://www.lajzar.co.uk

[Lasse Reichstein Nielsen]

"Fabian" <la****@hotmail.com> writes:

We call that broken quotes, or wrapped quotes. Take your pick.
I'd say "broken".
Every newsreader (since about 1973 or so anyway) has an option to set
the line length at which it automatically wraps text, and this accepts a
value of 80 or less (for backwards compatibility with text only
readers).
There is definitly disagreement there. I recommend *never* to wrap
automatically. Especially in programming groups, braking lines
automatically is downright dangerous.

If you do break lines, either reflow the paragraph or retain the
quoting level on all of the broken lines. Broken quotes are just that:
broken. They incorrectly attribute every other line to the wrong
author.
Every group I have ever seen recomends setting this value to
72,
The recommendation is to not write lines longer than 72 characters,
not to break other people's lines where they are not meant to be
broken.
which will allow 4 levels of quoting before any quoting gets broken.
Not breaking lines will not break any quotes. It will give excessively
long lines, but some times that is necessary. Alternatively, you can
reflow the paragraph.
This is in fact the default in msoe iirc.
Probably. Having a widely used program have such bad defaults is still
bad.
It is certainly the current setting on my machine (just checked),
and I dont recall ever changing it. So if my quoting gets broken
after a single level of quotes, the fault lies with the previous
poster for not following the standard, not with me.
No. The recommendation of 72 character lines is there to minimize the
number of wrapped lines and the damage done by broken programs. The
fault for breaking lines incorrectly is still with your program (not
with you, unless you desire that behavior).
Take your pick.

You program creates broken quotes. Conclusion: Your program is broken.
You can't blame anybody but the program for its actions.

Broken quotes is one of the worse bugs to have, since it attributes text
to the wrong author. I accept that your program is broken and you can't
help it, but don't think for a second that it is correct or desireable
behavior. And if you can fix it, please do.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'