On 2011-11-18 13:44, Simon Pieters wrote:
On Fri, 18 Nov 2011 13:22:42 +0100, Julian Reschke
<julian.resc...@gmx.de> wrote:
On 2011-11-18 13:03, Simon Pieters wrote:
UTF-8-only for workers is deliberate. I don't see any reason to reject
scripts that have other charset. Rejecting the script would mean that
some authors can't use workers at all because their server uses charset
and they can't change it.
What kind of server sets a charset on JS *and* cannot be configured
not to?
I don't know. I know we changed appcache to not do MIME type checking of
the cache manifest because authors had trouble changing it. I know we
sniff text/plain; charset=iso-8859-1, text/plain; charset=ISO-8859-1 and
text/plain; charset=UTF-8 because it's the default in some servers.
And, if this is the case, isn't this a good reason to actually require
that the charset is handled correctly?
For new features, we try to force UTF-8 (e.g. cache manifest, WebVTT,
workers).
That's fine if you use a new type, or profile an existing one.
But claiming that charset=... means something else before depending on
the context it's used in is asking for trouble.
I really believe that piling up workarounds and inconsistencies like
these makes the whole platform much harder to use than necessary.
Just use UTF-8. If you can't use UTF-8 in your workers, use ASCII and
character escapes. AFAIK there's have been no requests to support legacy
encodings in workers in Opera.
I'm ok with that. I'm not ok with treating something that has a charset
of ISO-8859-1 silently as UTF-8, in particular when other parts of the
platform disagree.
Best regards, Julian
