If you've visited here before you may want to jump straight to the latest additions:
Netscape claimed to have fixed this in Communicator 4.5PR. And indeed, for a while it seemed like it had been fixed. But now it looks like it hasn't.
Someone recently pointed out to me the following behaviour in Communicator 4.75 under Mac OS 8.1, and I was able to confirm it with Communicator 4.74 under Mac OS 9.0.4: There is still a redraw when the user's default char set is different form the char set declared by the webpage. But, again only when the page's char set is set through a META HTTP-EQUIV. There is no redraw when the char set is declared through a real HTTP Content-Type header.
Note that this has been confirmed by Netscape and that, since Communicator 4.x is only in maintenance mode, they're not planning on fixing this. As far as I can tell Mozilla doesn't have this problem. However, I have received a report that Netscape 6 somehow magically does have this problem still/again...
Initially, these pages were set up solely with the purpose of demonstrating/testing a Netscape bug. By now, also an attempt is made at providing some advice to HTML authors on how to cope with this bug.
Thanks to Alan J. Flavell and Arnoud 'Galactus' Engelfriet for providing the necessary information and feedback and pointing me towards related reference material.
The presence of:
<META HTTP-EQUIV="content-type" CONTENT="text/html;charset=something">
in the source code of a HTML document, will make Navigator/Communicator render the page twice.
In the occurrences where I've seen it, this tag seemed to have been automagically (and needlessly) inserted by certain so-called WYSIWYG HTML editors, which is probably the reason this annoying 'redraw' is seen more and more on the Web these days.
I've set up a few test pages, so you can see it for yourself:
According to RFC2070 (section 6), this META HTTP-EQUIV should be as early as possible in the HEAD section of a HTML document. This makes sense of course: The browser should know the character set before it starts rendering the document. So putting this META HTTP-EQUIV after the <TITLE> element, as the WYSIWYG HTML editors seem to be doing, is just plain wrong.
Possibly, what happens is that Netscape tries to give a 'preview', then notices the META HTTP-EQUIV, realises it needs to check with the server for the correct character set and then starts rendering the definite version, which, of course, is the same version still.
If this is in fact what happens, it seems it could be argued that Netscape is in violation of RFC2070 (section 6), which, to me, seems to be saying the browser should first check the headers.
This is not the whole story though, because having this META HTTP-EQUIV in the correct place still ignites this Netscape bug.
As it turned out, there can be 2 situations where having META HTTP-EQUIV in the correct place still ignites this Netscape bug:
Having a comment tag before this META HTTP-EQUIV (which, according to RFC1866 (section 3.4) is perfectly legal).
Though it shouldn't be necessary, a workaround would be to simply put any comment tags after this META HTTP-EQUIV.
and
Having a Document Type Declaration...
That's right. <BLINK> It's the (obligatory) DOCTYPE declaration Netscape chokes on! </BLINK>
In case you find this hard to believe you can of course check the source code yourself. For example, you'll find test 1b uses this construction:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="content-type" CONTENT="text/html;charset=iso-8859-1">
<TITLE>testpage</TITLE>
(etc.)
The redraw does not occur when the page is already cached. This seems to be confirmed by the redraw not occurring when viewing off-line (meaning from the local harddisk - no server involved).
It was suggested to me this might simply be because of the greater speed with which this bug would manifest itself in those cases. Slowing the pages down by adding up to 800K of images inside tables still didn't make it visible though.
I've received some reports suggesting server versions may also be playing a role in this. Ed Barker told me:
using the same browser (3.0), I get the redraw when the SERVER is apache (V 1.2.6 and others) running under Linux 2.0.33. However, if the server is IIS 3.0 running under NT server 4.0, I get no redraw.
A HTML page created by a cgi in response to a <form> can in some cases cause the browser to put up a message box asking the user if she would like to repost the form data.
In <URL:news:comp.infosystems.www.authoring.html>, in article ID <35576F93.7A7B@las-inc.com>, Ed Barker wrote:
I have a cgi app written in C to accept a string, do some calculations, and produce some HTML output. I have cross compiled the code for both Unix (Linux 2.0.33) and WinNT 4.0.
The problem is that when using NS 3.0 browser, and the cgi app is running on the Apache server, NS automatically reloads the page after it has been displayed, and I get a message box asking if I would like to repost the form data. Using the same brower to hit the same code running under IIS 3.0 on WinNT, I see no such problem.
Under NS 4.0, the result page flickers as though it is reloading, but I do not get the prompt about reloading the form data (and I can tell from my cgi logs that there is not a second request being issued. This is in contrast to NS 3.0, which does issue a second request).
This 'feature' seems to be present in many different versions of Netscape's browsers, but apparently not in all. I would like to offer an inventory, but am dependent on your feedback for that.
So far, this is what it looks like:
Note: It would be nice if you'd also give me some feedback when the result you get is already listed here, as I seem to be getting conflicting reports.
Please make sure to empty your browser's cache before trying the tests a second time.
Complain to Netscape.
On August 7, 1998 (over a year after this page was published), Netscape acknowledged this bug (In Message-ID: <smfr-0708981031570001@simon.mcom.com>, in <URL:news:comp.infosystems.www.browsers.mac>) and announced they plan for it to be fixed in version 4.5.
In fact, I just (September 1, 1998) received word from Simon Fraser announcing it is fixed in Communicator 4.5PR2, which is to be released in a few weeks.
Of course it will be a long time still before most users will have upgraded, so the responsibility for HTML authors to take this bug into account will remain! (Read on.)
Figure out how to make the best of it while all these versions of Netscape browsers are still in use.
A legitimate approach would of course be to encourage people to use a decent browser.
However, that does ignore the fact that this bug seems to come in 2:
After all the reference material I had to dig through in order to be able to provide some sort of advice here, I cannot imagine many HTML authors actually know and understand the arguments for and/or against using this tag.
According to both RFC2068 and RFC2616 (both at section 3.7.1), ISO 8859-1 is the default character set to be used. Only when another character set is to be used it must be specified.
Or, to put it in lay-man's terms:"Don't use this META tag, unless you know you need to".
Note: HTML 4.0 (at section 5.2.2) seems to contradict this, as it states that user agents must not assume a default character set. (Exactly what a web browser should do then when no char-set header is provided remains a mystery...)
For users of the Mac version of Navigator/Communicator, Hartmut Buhrmester suggested a hack. Although it would seem to have some drawbacks, some of you may want to try this.
When a character set other than ISO 8859-1 is to be used, a header must be sent along to the user agent to indicate this. However, it seems that most servers aren't configured to do so (see <URL:http://koi8.pp.ru/>).
In comes our META tag: I'm told that originally, META HTTP-EQUIV was meant to be used as a way to put such information inside the HTML document to be used by the server to compose the correct HTTP header for the document. And in fact the HTML 4.01 definition, at point 7.4.4, confirms this.
But apparently, in practice this is hardly ever done. What's more, according to RFC2070 (section 6), a browser is allowed to directly harvest the character set information from the META tag.
Now this could be a work-around for authors who have to depend on those incorrectly configured servers and... might be the reason some (confused) people started thinking it would be 'extra safe' to make use of META HTTP-EQUIV regardless of the situation.
The problem with that, is this META HTTP-EQUIV really is only a work-around for authors who both
In all other situations META HTTP-EQUIV is not needed. And not only that, there are also good reasons to not use it:
META HTTP-EQUIV unpredictable.
If you're serious about your HTML authorship, stay away from WYSIWYG HTML editors and learn HTML. It's really not that hard, but more important: It's really necessary that you do.
Both WYSIWYG and HTML are beautiful things, but the combination of the 2 is a 'contradictio in terminis'.
See also my page The Log (an introduction to Web publishing and HTML).
If anyone has more information about any of this and cares to share it, I'd be happy to add that information here.
If you're interested in how the results as published here were reached, read a compilation of the preceeding discussion between Alan J. Flavell and me.
For more information on this issue visit Alan Flavell's The Netscape charset burp.