- From: Drew Wilson <atwilson@google.com>
- Date: Fri, 25 Sep 2009 10:34:18 -0700
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 always treat script data imported via importScripts() as if it were encoded as utf-8" (i.e. skip step 3 of section 4.3 of the web workers spec), which seems like it's effectively changing the default decoding. Which means that someone naively serving up an existing Big5-encoded script (containing, say, string resources) with the appropriate charset header will find it fails when loaded into workers. Again, apologies if I'm misunderstanding the suggestion. -atw On Fri, Sep 25, 2009 at 10:21 AM, Anne van Kesteren <annevk at opera.com>wrote: > On Fri, 25 Sep 2009 19:16:47 +0200, Drew Wilson <atwilson at 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 through <script> will > be decoded differently from a script loaded through importScripts() as well. > > > Having the default decoding vary between importScripts() and <script> >> seems bad, especially since you can't override charsets with >> importScripts(). >> > > This is already the case. The suggestion was not about changing the > default. > > > > -- > Anne van Kesteren > http://annevankesteren.nl/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090925/d2c0a816/attachment.htm>
Received on Friday, 25 September 2009 10:34:18 UTC