- From: Adam Barth <w3c@adambarth.com>
- Date: Sun, 17 Oct 2010 21:36:06 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Getify <getify@gmail.com>, public html <public-html@w3.org>
On Sun, Oct 17, 2010 at 9:13 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 10/17/10 11:59 PM, Adam Barth wrote: >> Can you provide examples of sites that break? > > He already did earlier in this thread, no? Sorry, Tony's having trouble getting his email through to the list. He looked at (some of) the sites listed before and didn't see any problems. Maybe we need to study them in more detail. >>> I think it even further underscores the need for a spec change (that all >>> the >>> browsers can agree on) which gives a reliable and straightforward answer >>> to >>> "parallel-load-serial-execute" use case in a performance-oriented and >>> feature-testable way. >> >> Isn't this what defer does? > > No, because that defers the scripts to onload. The goal here is to execute > a set of scripts as soon from now as possible, but in a particular order. I believe defer doesn't wait until onload. It just wants for parsing to be finished, which is considerably earlier: http://www.whatwg.org/specs/web-apps/current-work/#attr-script-defer That's seems like a good balance of performance and predictability. The scripts are loaded in parallel, but executed in order relative to each other and relative to inline / external scripts in the document. >>> Since Webkit has made this change that is in a non-compat way with >>> existing >>> content, are they willing to support the proposed change as a >>> feature-testable addition (to spec and the browsers) that provides an >>> answer >>> to the use-case? >> >> I believe tonyg said that he thought the proposed change would slow >> down a bunch of real-world web sites that use script-inserted scripts >> to achieve parallel loading in existing browsers. > > 1) Which change(s) are we talking about here?? There are at least 3 > mutually exclusive proposed changes at this point, I think. Honestly, I'm lost w.r.t. all the proposals. There was something about an ordered property that I never understood. There was a proposal to make non-async script-inserted scripts have order relative to themselves (and possibly relative to other things). There was a proposal to have async have different semantics on parser- and script-inserted scripts. > 2) I'd be interested in mention of actual sites that are slowed down by the > changes in question (esp. the one where async is just allowed to apply to > script-inserted stuff. Well, every site on the Internet that uses more than one script-inserted script without an async attribute. The proposal was to add an ordering dependency between these scripts. This has been advocated by web performance experts for a while. For example, read this article: http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/ [[ In many situations, the Script DOM Element is a good choice. It works in all browsers, doesn’t have any cross-site scripting restrictions, is fairly simple to implement, and is well understood. ]] Adam
Received on Monday, 18 October 2010 04:37:11 UTC