- From: Simon Pieters <zcorpan@gmail.com>
- Date: Wed, 27 Jun 2007 02:01:37 +0200
- To: "Addison Phillips" <addison@yahoo-inc.com>, fantasai <fantasai.lists@inkedblade.net>
- Cc: www-style@w3.org, member-i18n-core@w3.org
On Wed, 27 Jun 2007 00:57:23 +0200, Addison Phillips <addison@yahoo-inc.com> wrote: > We didn't say that either solution was unacceptable. We only pointed out > that introducing a parse error would make the issue easier to > debug---and that this is much more likely than any reasonable use of > out-of-range sequences. I don't think it would be easier to debug. In the case of 'content', you would see on the page directly where in the replaced content there was an error. > So I think that the Internationalization Core WG would be *more* > satisfied with a solution that produces or allows a parse error. IE7, Firefox, Opera and Safari all replace invalid escapes with U+FFFD. I don't think it is worth trying to change this when there is interop already and the change would result in the same effect in the common case. Moreover, all browsers replace � in HTML with a U+FFFD, so I would expect CSS to do the same. > Having a validator or parser to flag it would tell people what was wrong > with their file. Indeed. > U+FFFD is an acceptable option, but less desirable only because it > produces no sign of why the failure occurred. I don't understand why a parse error produces any more sign of why the error occured than replacing with U+FFFD. > I think, personally, that this is a minor issue. Out of range escapes > will be rare in the wild, usually as some form of typo. Agreed, and indeed. -- Simon Pieters
Received on Wednesday, 27 June 2007 00:01:43 UTC