W3C home > Mailing lists > Public > www-international@w3.org > July to September 2003

Re: several messages

From: John Cowan <cowan@mercury.ccil.org>
Date: Fri, 19 Sep 2003 07:20:46 -0400
To: Ian Hickson <ian@hixie.ch>
Cc: Martin Duerst <duerst@w3.org>, Francois Yergeau <FYergeau@alis.com>, "kuro@sonic.net" <kuro@sonic.net>, Paul Deuter <PaulD@plumtree.com>, "www-international@w3.org" <www-international@w3.org>
Message-ID: <20030919112046.GG28272@mercury.ccil.org>

Ian Hickson scripsit:

>    If the form data set contains characters that are outside the
>    acceptable submission character sets, the user agent SHOULD inform
>    the user that his submission will be changed, for example using a
>    dialog in the form:

This seems good.

>    If the submission is not cancelled, the user agent MUST replace
>    each character that is not in the submission character set with a
>    single replacement character, either U+FFFD, "?", or some other
>    character depending on the availability of characters in the
>    submission character set.

How does it enhance interoperability to insist on replacing all the
untransmissible characters with a single character, and not prescribe
the single character?

As written, it would be conformant to change "die schöne Müllerin" (in
a US-ASCII-encoded form) to "die schXne MXllerin", but changing it to
"die schoene Muellerin" would be non-conformant.  That makes no sense
to me.  Similarly, in an ISO-8859-1-encoded form, it might be reasonable
to transliterate Greek or Russian entries.  (An application could infer
the language of input from the user's locale or other sources.)

It seems to me that you're requiring a browser *not* to provide
intelligent fallbacks without even guaranteeing a uniform fallback
behavior.

Furthermore, mentioning U+FFFD in this connection is the merest futility.
If U+FFFD is transmissible, any Unicode character will be.

-- 
Go, and never darken my towels again!           John Cowan
        --Rufus T. Firefly                      www.ccil.org/~cowan
Received on Friday, 19 September 2003 07:21:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 19:17:02 GMT