On Thu, 24 Sep 2009 22:49:51 +0200, Michael Nordman micha...@google.com
wrote:
That probably makes sense too in some use cases. Without practical
experience with this thing, its difficult to 'guess' which is of more
use.
Really? It seems quite natural to specify a catch-all fallback
On Wed, 23 Sep 2009 23:40:41 +0200, Jonas Sicking jo...@sicking.cc wrote:
You can also work around it by doing something like this:
test.html:
!DOCTYPE html
html
headtitleexample/title
script
str = script to evaluate;
w = new Worker(externalStub.js);
w.postMessage(str);
/script
/html
http://www.whatwg.org/specs/web-workers/current-work/#interface-objects-and-constructors
seems to say that there must be no interface object for Worker and
SharedWorker, but the constructors are to be available, which doesn't make
any sense since the constructor and the interface object are
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
I think that Workers should retain the same-origin policy. There is no
reason to use an ugly hack to bring in source from another domain,
there is a really normal way to do it given the current spec.
If there exists the need for a worker that runs cross-domain code
(whether that code is
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:26:40 +0200, Jonathan Cook
jonathan.j5.c...@gmail.com wrote:
I think that Workers should retain the same-origin policy.
So do I, modulo for data: URLs.
There is no reason to use an ugly hack to bring in source from another
domain,
I think you may have
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
In
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-September/023192.html
Robert O'Callahan wrote:
The unlocking around plugin calls is a problem, but it seems to me that any
given library function is much more likely start with a plugin-based
implementation and eventually switch to a
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
14 matches
Mail list logo
