On Wed, 23 Sep 2009 23:40:41 +0200, Jonas Sicking <[email protected]> wrote:
You can also work around it by doing something like this:
test.html:
<!DOCTYPE html>
<html>
<head><title>example</title>
<script>
str = "<script to evaluate>";
w = new Worker("externalStub.js");
w.postMessage(str);
</script>
</html>
externalStub.js:
onmessage = function(e) { eval(e.data); }
Ah, yep. Still requires an external file, but it could be the same for
different uses. Or it could be combined with my hack:
<!--
onmessage = function(e) { eval(e.data); }
/*
-->
<!DOCTYPE html>
<script>
str = "...script to evaluate...";
w = new Worker("");
w.postMessage(str);
</script>
<!--
*/
//-->
or even:
<!--
onmessage = function(e) { eval(e.data); }
/*
-->
<!DOCTYPE html>
<script type=text/x-worker id=worker>
...script to evaluate...
</script>
<script>
str = document.getElementById('worker').text;
w = new Worker("");
w.postMessage(str);
</script>
<!--
*/
//-->
What's the use case?
As I said:
This would allow easier testing, mashups, small standalone apps, and so
forth.
In particular, though, I suspect that people will work around this
limitation by one of the means we've come up with so far, or maybe people
with come up with even uglier workarounds. If we remove the limitation,
people will have no reason to come up with ugly hacks but instead use the
obvious supported way to do it, and it will be easier to debug and follow
code.
I think making data: urls is an ok solution,
unless the usecases are compelling enough that we think it's something
that people will do a lot.
Yeah, I think supporting data: URLs would be good.
--
Simon Pieters
Opera Software
