FAQ Topic - How can I see in javascript if a web browser accepts cookies?

[FAQ server]

-----------------------------------------------------------------------
FAQ Topic - How can I see in javascript if a web browser accepts cookies?
-----------------------------------------------------------------------

Writing a cookie, reading it back and checking if it's the same.

http://www.w3schools.com/js/js_cookies.asp

Additional Notes:

http://www.jibbering.com/faq/faq_notes/cookies.html
===
Postings such as this are automatically sent once a day. Their
goal is to answer repeated questions, and to offer the content to
the community for continuous evaluation/improvement. The complete
comp.lang.javascript FAQ is at http://www.jibbering.com/faq/.
The FAQ workers are a group of volunteers.

[Andrew Poulos]

FAQ server wrote:

-----------------------------------------------------------------------
FAQ Topic - How can I see in javascript if a web browser accepts cookies?
-----------------------------------------------------------------------

Writing a cookie, reading it back and checking if it's the same.

Can't you just check window.navigator.cookieEnabled?

Andrew Poulos

[Evertjan.]

Andrew Poulos wrote on 11 dec 2006 in comp.lang.javascript:

FAQ server wrote:

>----------------------------------------------------------------------
- FAQ Topic - How can I see in javascript if a web browser accepts
cookies?
----------------------------------------------------------------------
-

Writing a cookie, reading it back and checking if it's the same.

Can't you just check window.navigator.cookieEnabled?

Are there any browsers not implementing this? [ie and ff seem ok]

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Richard Cornford]

Evertjan. wrote:

Andrew Poulos wrote on 11 dec 2006 in comp.lang.javascript:

>FAQ server wrote:

>>----------------------------------------------------------------------
- FAQ Topic - How can I see in javascript if a web browser accepts
cookies?
----------------------------------------------------------------------
-

Writing a cookie, reading it back and checking if it's the same.

Can't you just check window.navigator.cookieEnabled?

Are there any browsers not implementing this? [ie and ff seem ok]

It would not matter is there were not as that test doesn't take into
account the actions of content inserting/re-writing proxies which may
re-write the code that references cookies so that it does not (i.e.
change all occurrences of the character sequence 'cookie' into
something else).

Richard.

[Evertjan.]

Richard Cornford wrote on 11 dec 2006 in comp.lang.javascript:

Evertjan. wrote:

>Andrew Poulos wrote on 11 dec 2006 in comp.lang.javascript:

>>>Writing a cookie, reading it back and checking if it's the same.

Can't you just check window.navigator.cookieEnabled?

Are there any browsers not implementing this? [ie and ff seem ok]

It would not matter is there were not as that test doesn't take into
account the actions of content inserting/re-writing proxies which may
re-write the code that references cookies so that it does not (i.e.
change all occurrences of the character sequence 'cookie' into
something else).

eh?
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Richard Cornford]

Evertjan. wrote:

Richard Cornford wrote:

>Evertjan. wrote:

>>Andrew Poulos wrote:

<snip>

>>>Can't you just check window.navigator.cookieEnabled?

Are there any browsers not implementing this? [ie and ff seem ok]

It would not matter is there were not as that test doesn't take into

^^
Should be 'if'

>account the actions of content inserting/re-writing proxies which may
re-write the code that references cookies so that it does not (i.e.
change all occurrences of the character sequence 'cookie' into
something else).

eh?

See:-

<URL:
http://groups.google.com/group/comp....d1c4750161a84a

>

Richard.

[Evertjan.]

Richard Cornford wrote on 11 dec 2006 in comp.lang.javascript:

Evertjan. wrote:

>Richard Cornford wrote:

>>Evertjan. wrote:
Andrew Poulos wrote:

<snip>

>>>>Can't you just check window.navigator.cookieEnabled?

Are there any browsers not implementing this? [ie and ff seem ok]

It would not matter is there were not as that test doesn't take into

^^
Should be 'if'

>>account the actions of content inserting/re-writing proxies which
may re-write the code that references cookies so that it does not
(i.e. change all occurrences of the character sequence 'cookie' into
something else).

eh?

See:-

<URL:
http://groups.google.com/group/comp....e_frm/thread/e
128caf75d348100/0bd1c4750161a84a

>>

I read there:

ZoneAlarm is capable of inserting text into, and re-writing, incoming
HTML pages. It might be that it is preventing client side cookies by
re-writing any occurrences of the identifier 'cookie' that it find
within script sections or pages. That would leave server created HTTP
cookies unaffected (Ebay) and eliminate all client-side JavaScript
cookies.

Well yes, but that does not mean we should programme for any clientside
irregularity.

Cookie writing/reading sequence will not test for cookie cleaning after
browser shutdown, or show the memory-cookie-expire ability either.

====================

I propose window.navigator.cookieEnabled is worth of inserting in the
FAQ.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Michael Winter]

Evertjan. wrote:

I read there:

>ZoneAlarm is capable of inserting text into, and re-writing,
incoming HTML pages. It might be that it is preventing client side
cookies by re-writing any occurrences of the identifier 'cookie'
that it find within script sections or pages. That would leave
server created HTTP cookies unaffected (Ebay) and eliminate all
client-side JavaScript cookies.

Well yes, but that does not mean we should programme for any
clientside irregularity.

But surely one should make the effort for a known and not uncommon
possibility, especially when it takes little effort.

Cookie writing/reading sequence will not test for cookie cleaning
after browser shutdown, or show the memory-cookie-expire ability
either.

No method can prove the former - without server-side assistance and
expecting the user to close all browser instances. The latter can be
easily proved: create a cookie (session or future-dated, it doesn't
matter) then reassign that cookie with a date in the past. If the cookie
can be read after the first assignment but not after the second, then it
is reasonable to conclude that the user agent will not send expired
cookies. This approach is easily included while testing the property.

I propose window.navigator.cookieEnabled is worth of inserting in the
FAQ.

Opposed. It is no more reliable (and possibly less so).

Mike

[Evertjan.]

Michael Winter wrote on 11 dec 2006 in comp.lang.javascript:

Evertjan. wrote:

>I read there:

>>ZoneAlarm is capable of inserting text into, and re-writing,
incoming HTML pages. It might be that it is preventing client side
cookies by re-writing any occurrences of the identifier 'cookie'
that it find within script sections or pages. That would leave
server created HTTP cookies unaffected (Ebay) and eliminate all
client-side JavaScript cookies.

Well yes, but that does not mean we should programme for any
clientside irregularity.

But surely one should make the effort for a known and not uncommon
possibility, especially when it takes little effort.

>Cookie writing/reading sequence will not test for cookie cleaning
after browser shutdown, or show the memory-cookie-expire ability
either.

No method can prove the former - without server-side assistance and
expecting the user to close all browser instances. The latter can be
easily proved: create a cookie (session or future-dated, it doesn't
matter) then reassign that cookie with a date in the past. If the
cookie can be read after the first assignment but not after the
second, then it is reasonable to conclude that the user agent will not
send expired cookies. This approach is easily included while testing
the property.

We were not discussing what can be eaily done, but what to put in the
FAQ.

Do we put your solution in the FAQ, and then how?

>I propose window.navigator.cookieEnabled is worth of inserting in
the FAQ.

Opposed. It is no more reliable

That is no reason not to put it in the FAQ.

It is an easy solution, much shorter than a whole function:

if (window.navigator.cookieEnabled) {...}

(and possibly less so).

Could be, but if so, we should determine that first.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Michael Winter]

Evertjan. wrote:

Michael Winter wrote on 11 dec 2006 in comp.lang.javascript:

[snip]

>... create a cookie (session or future-dated, it doesn't matter)
then reassign that cookie with a date in the past. If the cookie
can be read after the first assignment but not after the second,
then it is reasonable to conclude that the user agent will not send
expired cookies. This approach is easily included while testing the
property.

[snip]

Do we put your solution in the FAQ, and then how?

I don't know. It looks a little messy as a single function, but can look
rather intimidating as a collection.

Below is collection of cookie-related methods that I wrote a while ago.
The makeAge method isn't used by the isSupported method.

var Session = function () {
var supported = false;

return {
get: function (name) {
var match = new RegExp('(^|;)\\s*' + name
+ '\\s*=\\s*([^\\s;]+)').exec(document.cookie);

return match ? match[2] : null;
},
set: function (name, value, maxAge, path, domain) {
var cookie = name + '=' + value;

if (maxAge !== 0) {
var expires = new Date();

expires.setUTCSeconds(maxAge
+ expires.getUTCSeconds());
cookie += ';expires=' + expires.toGMTString();
}
if (path) cookie += ';path=' + path;
if (domain) cookie += ';domain=' + domain;
document.cookie = cookie;
},
remove: function (name, path, domain) {
this.set(name, 'deleted', -1, path, domain);
},
isSupported: function () {
if (typeof document.cookie == 'string') {
var name = 'test',
value = 'foobar';

while (this.get(name) != null) name += '-' + name;
this.set(name, value, 30);
if ((this.get(name) == value)
&& (this.get('expires') == null)) {
this.remove(name);
supported = (this.get(name) == null);
}
}
this.isSupported = function () {return supported;};
return supported;
},
makeAge: function (days, hours, minutes, seconds) {
return ((days * 24 + (+hours || 0)) * 60
+ (+minutes || 0)) * 60 + (+seconds || 0);
}
};
}();

The age value in the test is arbitrary, really. A value of 2 should
suffice, but a larger number makes no difference. An indication of
success requires the data to be deleted, anyway.

>>I propose window.navigator.cookieEnabled is worth of inserting in
the FAQ.

Opposed. It is no more reliable

That is no reason not to put it in the FAQ.

It's certainly one reason.

It is an easy solution, much shorter than a whole function:

Is the property guaranteed? Does the property represent client-side
state management in general, or specifically that the document.cookie
property is usable? The former doesn't need to imply the latter; the
former is potentially useful information on its own. Given the nature of
the property, those are not easy questions to answer accurately.

[snip]

>(and possibly less so).

Could be, but if so, we should determine that first.

Richard already presented one reason why it definitely is, though I was
leaning more towards the existence of the property itself. Proving that
to any degree of certainty is impractical, as you should well know.

Mike

[Dr J R Stockton]

In comp.lang.javascript message
<PO*******************@text.news.blueyonder.co.uk> , Wed, 13 Dec 2006
02:45:03, Michael Winter <m.******@blueyonder.co.ukwrote:

expires.setUTCSeconds(maxAge
+ expires.getUTCSeconds());

Those Methods require mod-60 arithmetic; they don't *need* (but might
cause) Y-M-D handling.

But expires.setTime(maxAge*1000 + expires.getTime());
does not.

The improvement will be insignificant (the preceding New Date() will
tale longer!).

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6.
Web <URL:http://www.merlyn.demon.co.uk/- w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/- see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.

[Michael Winter]

Dr J R Stockton wrote:

[snip]

Those Methods [get/setUTCSeconds] require mod-60 arithmetic; they
don't *need* (but might cause) Y-M-D handling.

But expires.setTime(maxAge*1000 + expires.getTime()); does not.

True. Thanks.

[snip]
Different subject: Firefox 2.0 objects to the leading zero in "08" on
line 145 of <http://www.merlyn.demon.co.uk/js-date1.htm>. This is within
the TryToUTC function declaration. I think you have other occurrences of
leading zeros in numeric literals in other documents. An initial zero
must be followed by something other than a digit.

The table at the end of "Resolutions of new Date()"
<http://www.merlyn.demon.co.uk/js-dates.htm#Ressis positioned oddly to
the right causing a horizontal scrollbar. Again, in Firefox.

Mike

[Dr J R Stockton]

In comp.lang.javascript message
<q5*******************@text.news.blueyonder.co.uk> , Thu, 14 Dec 2006
01:50:14, Michael Winter <m.******@blueyonder.co.ukwrote:

>Different subject: Firefox 2.0 objects to the leading zero in "08" on
line 145 of <http://www.merlyn.demon.co.uk/js-date1.htm>. This is
within the TryToUTC function declaration. I think you have other
occurrences of leading zeros in numeric literals in other documents. An
initial zero must be followed by something other than a digit.

That's horrible; but it does seem to be in ECMA-262. Languages should
be written in Europe, where we have millennia of experience of the task.
It's not easy to locate all of those zeroes with available tools; but
I've found quite a few and fixed them. If you see any more ...

>The table at the end of "Resolutions of new Date()" <http://www.merlyn.
demon.co.uk/js-dates.htm#Ressis positioned oddly to the right causing
a horizontal scrollbar. Again, in Firefox.

I see no obvious reason. But if any FireFox expert can offer an
IE-compatible fix, I can install it. (The table should not in principle
be at the end of the section; it should be immediately after the code
box).

Thanks.

==

<URL:http://www.merlyn.demon.co.uk/js-misc1.htm#Cashhas, under "Ways
of Giving Change", a demonstration of cacheing in a recursive algorithm.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/- FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.

[Randy Webb]

Dr J R Stockton said the following on 12/14/2006 3:55 PM:

In comp.lang.javascript message
<q5*******************@text.news.blueyonder.co.uk> , Thu, 14 Dec 2006
01:50:14, Michael Winter <m.******@blueyonder.co.ukwrote:

>Different subject: Firefox 2.0 objects to the leading zero in "08" on
line 145 of <http://www.merlyn.demon.co.uk/js-date1.htm>. This is
within the TryToUTC function declaration. I think you have other
occurrences of leading zeros in numeric literals in other documents. An
initial zero must be followed by something other than a digit.

That's horrible; but it does seem to be in ECMA-262. Languages should
be written in Europe, where we have millennia of experience of the task.

Does your stupidity know *any* bounds at all?

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

[Evertjan.]

Randy Webb wrote on 15 dec 2006 in comp.lang.javascript:

>That's horrible; but it does seem to be in ECMA-262. Languages should
be written in Europe, where we have millennia of experience of the task.

Does your stupidity know *any* bounds at all?

No, Randy, our European endless stupidity is only surpassed by the American
counterpart.

Imagine the dullness of a world without stupidity. One would have to resort
to firearms to get rid of frustration.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Randy Webb]

Evertjan. said the following on 12/15/2006 3:56 AM:

Randy Webb wrote on 15 dec 2006 in comp.lang.javascript:

>>That's horrible; but it does seem to be in ECMA-262. Languages should
be written in Europe, where we have millennia of experience of the task.

Does your stupidity know *any* bounds at all?

No, Randy, our European endless stupidity is only surpassed by the American
counterpart.

Let's see here. Europe has had millennia of experience writing languages
yet there are how many different languages spoken in Europe? In endless
centuries they haven't come up with a single language yet Americans are
stupid yet they have one single language. How intuitive....

And no less, to say that the European Computer Manufacturers Association
language specification should be written in Europe is "intelligent"?

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

[Peter Michaux]

Andrew Poulos wrote:

FAQ server wrote:

-----------------------------------------------------------------------
FAQ Topic - How can I see in javascript if a web browser accepts cookies?
-----------------------------------------------------------------------

Writing a cookie, reading it back and checking if it's the same.

Can't you just check window.navigator.cookieEnabled?

Aren't the properties of the navigator object completely spoofable? And
aren't browser makers free to do what they want with and lie completely
with the navigator object (and i suppose all other objects)? Or is it
just the userAgent property that they lie with?

Peter

[Richard Cornford]

Peter Michaux wrote:

Andrew Poulos wrote:

<snip>

Can't you just check window.navigator.cookieEnabled?

Aren't the properties of the navigator object completely spoofable?

Yes, but it depends on what you mean by that.

And aren't browser makers free to do what they want with and lie
completely with the navigator object (and i suppose all other objects)?

Yes, but why should they? There would be little to be gained from
setting - cookieEnabled - to true when cookies were not enabled or to
false when they were. The issue with - cookieEnabled - is that the
browser itself is not the final arbiter of a script's ability to read
and write cookies, so what the browser thinks it can do is not
necessarily the same as what can be done.

Or is it
just the userAgent property that they lie with?

The browser identification and version properties may be spoofing other
browser for practical reasons. The - userAgent - property is intended
to reflect the HTTP user agent header value, and in all cases I am
aware of it does. However, the HTTP 1.1 user agent header is not
specified as being a source of information, so it should not be treated
as one, and an object property that reflects a header that is not
specified as a source of information should then also not be treated as
a source of information. There can be no lie where there is no
information.

Richard.

[VK]

Peter Michaux wrote:

Aren't the properties of the navigator object completely spoofable?

cookieEnabled is read-only property. Or you mean someone has disabled
cookies but hacked the engine to report cookieEnabled == true ? :-)
Also do not mix "feature detection" and "browser sniffing". The second
is spoofed over userAgent string left and right. My belowed case up to
date is of course Safari. (Some people do still believe that it is a
browser and not an Apple's practical joke - for them I'm reminding this
all times the best spoofing pearl: "...MSIE; Microsoft Internet
Explorer like Gecko".)

There are two very different types of cookies: 1) persistent cookies
and 2) session cookies.

Persistent cookies are the ones being stored client-side in
%system%Cookies folder (or equivalent). They remain - so can be read
back - until their expiration date or until manually removed.

Session cookies are not being stored in file: they exist only in the
computer memory and they disappear right after the current session:
thus after the last running instance of the browser is closed.

This way write/read back check can reliable tell only one thing: if
session cookies are enabled. This is true for 99% of cases so no big
use to check it really: but of course it doesn't make any harm.

At the same time persistent cookies can be very well disabled for given
domain depending on user preferences (block all cookies, block cookies
w/o P3P policies file etc.)

navigator.cookieEnabled checks if *persistent cookies are enabled* -
but it doesn't check for session cookies.

It is technically possible to have a system with session cookies
disabled but persistent cookies enabled: but such system has to be
handcrafted then, as I don't know of a way to achieve it by the
standard privacy settings.

To summarize:

If only session cookies are needed (thus you don't care about the data
after the session's end), then the old write/read trick can be used.

For any other purposes navigator.cookieEnabled check has to be used.

[VK]

VK wrote:

If only session cookies are needed (thus you don't care about the data
after the session's end), then the old write/read trick can be used.

For any other purposes navigator.cookieEnabled check has to be used.

To protect the reputation of the old FAQ version: :-)

navigator.cookieEnabled check couldn't be suggested in the previous
version, because this property originally was IE-only.

As a universal method (still in use on many servers as
script-independent) is indeed write cookie / read it back. A very
important part was missing though in the FAQ: "write cookie on one
page, read cookie from *another* page". Only this way you can tell if a
web browser accepts cookies *for the given domain*, and this is the
question one really may want to know. An abstract "if a web browser
accepts cookies" has not much of sense but can be left for readability.

[Evertjan.]

Randy Webb wrote on 15 dec 2006 in comp.lang.javascript:

Evertjan. said the following on 12/15/2006 3:56 AM:

[...]

>>
No, Randy, our European endless stupidity is only surpassed by the
American counterpart.

[essential part skipped by Randy]

>
Let's see here. Europe has had millennia of experience writing
languages yet there are how many different languages spoken in Europe?

Yes, and that is a joy!

In endless centuries they haven't come up with a single language yet
Americans are stupid yet they have one single language.

Indeed, you could easily say so and could certainly be right!

Having one single language does not preclude stupidity.
Sending vehicles into space where inches and centimeters are mixed up,
because you think that mixing up is not possible with one single
language, is an excellent example of stupidity.

How intuitive....

Should it be intuitive? Why?

And no less, to say that the European Computer Manufacturers
Association language specification should be written in Europe is
"intelligent"?

Did I say that? I don't remember.
Stupidity without intelligence cannot even exist.

If you are from the States and think that "endless stupidity" can be
surpassed, as I said, you could just have proved my point.

;-) ;-) ;-)

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[John G Harris]

In article <x4********************@telcove.net>, Randy Webb
<Hi************@aol.comwrites

<snip>

>Americans are stupid yet they have one single language.

<snip>

Spanish, Pennsylvania Dutch, Choctaw, Navaho, French, Creole, Inuit,
Hawaiian, ... , and a dialect of English with deliberately different
spelling.

John
--
John Harris

[Randy Webb]

VK said the following on 12/15/2006 12:44 PM:

VK wrote:

>If only session cookies are needed (thus you don't care about the data
after the session's end), then the old write/read trick can be used.

For any other purposes navigator.cookieEnabled check has to be used.

To protect the reputation of the old FAQ version: :-)

"protect the reputation"? There is nothing in the FAQ that needs to be
"protected" for the sake of its reputation. If something is wrong, then
its wrong and needs to be corrected.

navigator.cookieEnabled check couldn't be suggested in the previous
version, because this property originally was IE-only.

That is *not* why it isn't suggested. Then or now. It is not in there
now because it is not reliable and won't do what is needed to find out
if a browser accepts cookies or not.

As a universal method (still in use on many servers as
script-independent) is indeed write cookie / read it back.

And does it not occur to you that the reason that method is used is
because it is reliable?

A very important part was missing though in the FAQ: "write cookie on one
page, read cookie from *another* page". Only this way you can tell if a
web browser accepts cookies *for the given domain*, and this is the
question one really may want to know. An abstract "if a web browser
accepts cookies" has not much of sense but can be left for readability.

There is something missing alright, but in the spirit of a friendly
conversation I won't repeat what it is that you are missing.

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

[Michael Winter]

Dr J R Stockton wrote:

In comp.lang.javascript message
<q5*******************@text.news.blueyonder.co.uk> , Thu, 14 Dec 2006
01:50:14, Michael Winter <m.******@blueyonder.co.ukwrote:

[snip]

>The table at the end of "Resolutions of new Date()"
<http://www.merlyn.demon.co.uk/js-dates.htm#Ressis positioned
oddly to the right causing a horizontal scrollbar. Again, in
Firefox.

I see no obvious reason.

The problem is quite clear: the containing div element (which is surely
unnecessary) is assigned an explicit width of 1em. This isn't even close
to an appropriate width (25em is closer) so the table overflows the div
element and extends to the right. As the latter is floated right, this
places the table mostly off the right-hand side of the viewport.

[snip]

Mike

[Dr J R Stockton]

In comp.lang.javascript message <e0******************@text.news.blueyond
er.co.uk>, Thu, 28 Dec 2006 16:10:50, Michael Winter
<m.******@blueyonder.co.ukposted:

>Dr J R Stockton wrote:

>In comp.lang.javascript message
<q5*******************@text.news.blueyonder.co.uk >, Thu, 14 Dec 2006
01:50:14, Michael Winter <m.******@blueyonder.co.ukwrote:

[snip]

>>The table at the end of "Resolutions of new Date()"
<http://www.merlyn.demon.co.uk/js-dates.htm#Ressis positioned
oddly to the right causing a horizontal scrollbar. Again, in
Firefox.

I see no obvious reason.

The problem is quite clear: the containing div element (which is surely
unnecessary) is assigned an explicit width of 1em. This isn't even
close to an appropriate width (25em is closer) so the table overflows
the div element and extends to the right. As the latter is floated
right, this places the table mostly off the right-hand side of the
viewport.

In IE6, and almost certainly IE4, that 1em has the (wanted) effect of
making the table as narrow as possible (forcing line-breaks in
elements), but leaves the right-hand edge aligned with the right
paragraph margin (also wanted). I've now used <brfor the breaks and
moved the rest of the style into <form ... >.

Thanks. I'll look out for any similar cases, but they're not obvious in
IE.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6
news:comp.lang.javascript FAQ <URL:http://www.jibbering.com/faq/index.html>.
<URL:http://www.merlyn.demon.co.uk/js-index.htmjscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/jscr/&c, FAQ items, links.