[whatwg] Script-related feedback

[Ian Hickson]

On Wed, 9 Jan 2013, Adam Barth wrote:
> 
> Working through some examples, that seems really strange:
> 
> foo();
> breakParsing();
> bar();
> 
> In this case, breakParsing() works a bit like "yield()" in other
> programming languages: first foo() executes, then the event loop
> spins, then bar() executes.  However, if we wrap the code in an
> anonymous function block (as would make sense for JavaScript):
> 
> (function() {
>   foo();
>   breakParsing();
>   bar();
> })();
> 
> Now I get either get a parse error, if breakParsing() actually breaks up 
> the parsing, or breakParsing() does nothing, both of which are 
> surprising.

That's why I originally proposed it as a pragma comment (which I'm pretty 
sure would be just as safe, because anything that stops someone from 
escaping a string injection in any way will stop both identifiers and 
comments, and it seems highly unlike that someone would go out of their 
way to let you escape a string literal and be allowed to inject a comment 
but not be allowed to inject a division or method call or whatnot).


> Worse, other seemingly trivial syntactic transformation also break the 
> magic:
> 
> foo();
> breakParsing.call();
> bar();
> 
> Now the JavaScript parse won't recognize the magic "breakParsing();" 
> production, and my script executes slowly.

So let's not use something that looks like a method call -- I agree that 
isn't ergonomically or aesthetically pleasing.

/*@BREAK*/


> I guess I don't understand the advantage of trying to cram this into 
> JavaScript syntax.

Advantages of putting this in JS over multipart:

 - it's backwards-compatible
 - it's easier to parse a static barrier than a multipart/*'s wacky 
   syntax.
 - it doesn't impact any of the current fetching logic, since it's 
   still just one resource instead of introducing a layer in between 
   <script>'s logic and the JS logic.
 - it automatically works anywhere you can use JS, not just where HTTP is 
   involved.
 - it can be shimmed more easily (if you trust the JS not to have 
   arbitrary injection and be written with the shim in mind, especially).
 - it doesn't run into weird problems like what if a part has the wrong 
   MIME type.
 - it's way easier to deploy (authors hate having to set MIME types).
 - it doesn't run into the problem that all UAs have historically ignored 
   the MIME type of script.


> HTTP already has an efficient mechanism for delivering several 
> JavaScript programs in sequence: multipart.

"Efficient" isn't the word I would have used.


> Given that <img> and <iframe> already support multipart, it seems much 
> simpler just to make <script> support multipart as well.

Given how much pain multipart was to handle in <img> and <iframe>, 
avoiding it like the plague seems like the more appropriate lesson. :-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'