Re: lynx-dev HTML4.0 and default charset

[Leonid Pauzner]

27-Feb-99 21:21 Alan J. Flavell wrote:

> Greetings,

> In HTML4.0 section 5.2.2 there's a rather odd sentence; I'd better
> quote the complete paragraph so as not to take it out-of-context:

>  The HTTP protocol ([RFC2068], section 3.7.1) mentions ISO-8859-1
>  as a default character encoding when the "charset" parameter is
>  absent from the "Content-Type" header field. In practice, this
>  recommendation has proved useless because some servers don't allow a
>  "charset" parameter to be sent, and others may not be configured to
>  send the parameter. Therefore, user agents must not assume any
>  default value for the "charset" parameter.

> Now, that last sentence, on the face of it, forbids a browser to
> assume a default value for the "charset" parameter.  In order to
> solve the problem it has just described, however, the browser clearly
> must have a user-configurable "charset default", to be used when the
> incoming document lacks one.

> Paradox?

> Of course, Lynx has such a configurable default (as do other WWW
> browsers, for sure); but it seems to me that every one of them has
> some initial selection of this default, and therefore must be rated
> non-compliant with HTML4.0 on the grounds that it 'assumes a default
> value for the "charset" parameter', the very thing which the spec
> forbids.

We found a compromize: "assumed charset" may be configurable on-line
by user but this value will not be saved permanently as default
for next Lynx session. (unless someone change lynx.cfg for this item
which is not recommended because of reason you quoted above).

> Perhaps the spec was worded infelicitously - maybe it meant to forbid
> a client to have a fixed default setting, but must make it user
> configurable.  I don't know, but, for now, it says what it says.

> Aside from the fact that I'm probably being pedantic (nothing new in
> that), is there some logical way of making a browser that both
> conforms to the last sentence _and_ allows the reader to solve the
> indicated problem?

The most logical way to have servers configured properly :-)
IMO, charset parameter should be always specified when document
have characters >128. Unfortunately, http/html specs keep compatibility
with very old browsers which does not understand charset parameter
and even can not ignore it (and such browsers are obviously broken
for any modern HTML in any case). That is the root of the problem.

> best regards