Re: charset parameter

At 05:38 01/07/26 +0200, Terje Bless wrote:

>If I take my own preference and modify it to be more in line with what you
>and Bj$B‹S(Bn are saying (AFAICT), I think we end up with the following
>pseudo-algorithm.
>
>1) Check HTTP for charset.
>   a) If found, use it (for now).

No. If found, use it, done.


>   b) If not found, assume to be ASCIIpatible (for now).
>
>2) Check for META charset (using explicit or implied HTTP charset).
>   a) If found, use unconditonally, overriding HTTP.

No, don't override. See HTML 4, section 5.2.


>   b) If not found...
>      I. If HTTP had explicit charset, keep using it.

That can then go, too.

>     II. If no HTTP charset, punt and tell the user to "deal with it"
>
>3) Check for a CGI "charset" parameter.
>   a) If found, use unconditionally, overriding META, but mark doc invalid.

This overrides both META and HTTP, so it should come first.
The 'charset' parameter corresponds to an explicit (per page) user setting
in a browser.

>   b) If not found...
>      I. If META or HTTP had explicit charset, keep using it.
>     II. If no META or HTTP charset, punt and tell the user to "deal with
>         it"
>
>This pseudo-algorithm has the property that we accept the HTTP defaulting
>behaviour for just long enough to try to find a better source for the
>information, while still refusing to go on _just_ the HTTP defaulting.

Yes, this is the right thing to do.


>This, however, still leaves us with the problem that a great majority of
>pages rely on the HTTP defaulting and so we are no longer meeting user
>expectations.

A great deal of pages in Europe rely on that, but it's not something
that works worldwide.


The current implementation is already as close as it gets to this,
except for file upload/fragment.



Regards,    Martin.

Received on Friday, 27 July 2001 22:55:49 UTC