On Mon, 8 Dec 2008, Dean Edridge wrote:
Where you have p class=warningThis is a warning./p in the page
there is a funny character that pops up to the left of this, it looks
like a character encoding problem. I'm using firefox 3, in Google Chrome
it's fine. You are probably aware of this
Ian Hickson wrote:
As far as I can tell everything is correct here, the problem is on your
end.
I wasn't saying that the problem was at your end; whether it's a problem
with firefox or whatever, I was just letting you know that the problem
existed, that's all, just like I emailed you
-public-html, +www-archive
This isn't a popularity contest. The reasoning behind not using the empty
string was quite adequately given by both Henri and Smylers, and quoted in
my original message.
No, it isn't.
This is a Working Group trying to come up with a good solution, and I don't
Off-list, as this isn't really related to the development of HTML
whatsoever.
On 3 Mar 2008, at 08:54, Martin Duerst wrote:
I don't see anything making a BOM illegal in UTF-16LE/UTF-16BE, in
fact, the only mention I find of it with regards to either in Unicode
5.0 is In UTF-16(BE|LE), an
Geoffrey Sneddon wrote:
In particular, whenever a data stream is declared to be UTF-16BE,
UTF-16LE, UTF-32BE or UTF-32LE a BOM must not be used.
If somebody wants to include a zero-width non-breaking space
(ZWNBSP) at the beginning of a stream, they have to use U+2060 WORD
JOINER
On 29 Feb 2008, at 13:38, Brian Smith wrote:
Ian Hickson wrote:
However, when the encoding is UTF-16LE or UTF-16BE (i.e.
supposed to be signatureless), do we really want to drop
the BOM silently? Shouldn't it count as a character that
is in error?
Do the UTF-16LE and UTF-16BE specs make a
