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 <[email protected]>wrote: > On Fri, 25 Sep 2009 19:16:47 +0200, Drew Wilson <[email protected]> > 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/ >
