On Fri, 25 Sep 2009, Simon Pieters wrote:
Workers are new and seems very likely to be incompatible with existing
scripts. So it is not subject to legacy content with legacy encodings.
Therefore, we should be able to always use utf-8 for workers. Always
using utf-8 is simpler to implement
On Fri, 25 Sep 2009 19:34:18 +0200, Drew Wilson atwil...@google.com
wrote:
Again, apologies if I'm misunderstanding the suggestion.
I thought that by default encoding you meant the encoding that would be
used if other means of getting the encoding failed. If there is only one
encoding it
Leaving legacy encodings behind would be a good thing if we can get away
with it... jmho.
On Mon, Sep 28, 2009 at 9:59 AM, Drew Wilson atwil...@google.com wrote:
Ah, sorry for the confusion - my use of default was indeed sloppy. I'm
saying that if the server is explicitly specifying the
Workers are new and seems very likely to be incompatible with existing
scripts. So it is not subject to legacy content with legacy encodings.
Therefore, we should be able to always use utf-8 for workers. Always using
utf-8 is simpler to implement and test and encourages people to switch to
The importScripts portion of the Web Workers API is compatible with
existing scripts, but I'm all for more UTF-8 :) If the restriction is
added to the spec, I'd want to know that a very clear error was going to
be thrown explaining the problem.
Regards,
Jonathan 'J5' Cook
Simon Pieters
On Fri, 25 Sep 2009 15:31:41 +0200, Jonathan Cook
jonathan.j5.c...@gmail.com wrote:
The importScripts portion of the Web Workers API is compatible with
existing scripts,
Only if those scripts don't use any of the banned interfaces and
constructors, right?
but I'm all for more UTF-8 :)
Are you saying that if I load a script via a script tag in a web page,
then load it via importScripts() in a worker, that the result of loading
that script in those two cases should/could be different because of
different decoding mechanisms?
If that's what's being proposed, that seems bad.
-atw
On Fri, 25 Sep 2009 18:39:48 +0200, Drew Wilson atwil...@google.com
wrote:
Are you saying that if I load a script via a script tag in a web page,
then load it via importScripts() in a worker, that the result of loading
that script in those two cases should/could be different because of
Certainly. If I explicitly override the charset, then that seems like
reasonable behavior.
Having the default decoding vary between importScripts() and script seems
bad, especially since you can't override charsets with importScripts().
-atw
On Fri, Sep 25, 2009 at 10:08 AM, Anne van Kesteren
On Fri, 25 Sep 2009 19:16:47 +0200, Drew Wilson atwil...@google.com
wrote:
Certainly. If I explicitly override the charset, then that seems like
reasonable behavior.
It does not need to be overridden per se. If the document character
encoding is different from UTF-8 then a script loaded
Then I'm misunderstanding the suggestion then. My reading of:
Therefore, we should be able to always use utf-8 for workers. Always using
utf-8 is simpler to implement and test and encourages people to switch to
utf-8 elsewhere.
...was we should ignore charset headers coming from the server and
11 matches
Mail list logo
