- From: Drew Wilson <atwilson@google.com>
- Date: Fri, 25 Sep 2009 09:39:48 -0700
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, Sep 25, 2009 at 6:45 AM, Simon Pieters <simonp at opera.com> wrote: > On Fri, 25 Sep 2009 15:31:41 +0200, Jonathan Cook < > jonathan.j5.cook at 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 :) 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. >> > > I'm not sure that throwing an error is a good idea. Would you throw an > error when there's no declared encoding? That seems to be annoying for the > common case of just using ASCII characters. Throwing an error when there is > a declared encoding that is not utf-8 might work, but are there many scripts > that have a declared encoding and are not utf-8? > > I think it is to just ignore any declared encoding and assume utf-8. If > people are using non-ascii in another encoding, then they would notice by > seeing that their text looks like garbage. Browsers could also log messages > to their error consoles about encoding declarations declaring non-utf-8 > and/or sequences of bytes that are not valid utf-8. > > -- > Simon Pieters > Opera Software > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090925/a98d1518/attachment.htm>
Received on Friday, 25 September 2009 09:39:48 UTC