Re: [whatwg] Script preloading

On Aug 30, 2013, at 4:36 PM, Garrett Smith <dhtmlkitchen@gmail.com> wrote:

> On 8/30/13, Ryosuke Niwa <rniwa@apple.com> wrote:
>> 
>> I don't think it'll be hard to add the media attribute on the script element
>> at least in WebKit.
>> 
>> It'll be much harder to implement a new dependency API that replies on CSS
>> selectors if we care about the performance at all.
>> 
> What is this in response to? What dependency API that relies on CSS
> selectors? (I'm assuming you mean relies and not replies, but still
> not sure what you mean).

Sorry, I meant to say "relies".  I was referring to the Jake's version of the dependency resolution mechanism as seen below:

On Aug 29, 2013, at 9:42 AM, Jake Archibald <jaffathecake@gmail.com> wrote:
> I'm not sure it's possible to get into loops with this. I imagined
> dependency resolution to happen once, on element creation or adding to
> document (whichever happens latest). So with:
> 
> <script src="a.js" needs="script[src=b.js]"></script>
> <script src="b.js" needs="script[src=a.js]"></script>
> 
> …the first script would have zero dependencies, because the selector
> matches zero elements. The second would depend on the first, so the
> execution order is a.js, b.js. The thing I like about the selector thing is
> you can very easily get (almost) async=false behaviour:



Going back to Ian's proposal.

On Aug 27, 2013, at 2:55 PM, Ian Hickson <ian@hixie.ch> wrote:
> Here's a proposal that attempts to address all the use cases:
> 
> High-level overview:
> 
>  <script> elements get a new whenneeded="" attribute, which delays the 
>  execution of the script until the <script> element's execute() method is 
>  called. (This essentially provides the same as the "preload" 
>  suggestions.)
> 
>  <script> elements also get a new needs="" attribute, which takes a list 
>  of URLs. A <script> won't run (even if you call execute()) until all the 
>  <script src=""> elements referenced by its needs="" attribute are 
>  themselves ready to run. For example:
> 
>     <script src="b.js" needs="a.js"></script>
>     <script src="a.js" async></script>
> 
> ...will execute a.js when it's ready, and only then execute b.js. "needs" 
> basically implies "async" if its needs aren't met when it first tries to run.
> 
> <script whenneeded="jit"> is a special mode where instead of running once 
> the script's dependencies are met, it additionally waits until all the 
> scripts that depend on _it_ are ready to run. ("Just in time" exection.) 
> (The default is whenneeded=asap, "as soon as possible" exection.)
> 
> You can manually increase or decrease a dependency count on <script> 
> elements by calling incDependencies() and decDependencies().
> 
> 
> Details (tersely):
> 
>  scripts have a "whenneeded" mode, initially "none", can also be "asap", "jit".

I don't quite understand why we need two values for "whenneded".

Why can't we simply have "prefetch" (since we already use that term in the link element) and "needs" (I'd prefer calling it "requires") content attributes?

When a script element has the prefetch attribute, it doesn't execute until execute() is called upon the element unless
(i.e. the script is executed immediately when the script has been loaded) if at least one of its dependencies is not a prefetch
(i.e. doesn't have the "prefetch" content attribute).

Could you clarify which use case this alternative proposal doesn't address?

>  <script> gets a method, execute():
>    0. mark as needed
>    0. call execute() on each script we depend on  
>    0. if we didn't depend on any, check if we need to run
> 
>  <script> gets a pair of methods, incDependencies() and decDependencies(), 
>  that increase and decrease the dependency count by one, respectively
>  decDependencies() throws if called when the count is zero. If 
>  decDependencies() is called and it reduces the number to zero,

I strongly oppose to adding incDependencies/decDependencies.  We try not to add those pairwise functions as much as possible our C++ code because it's really hard to always pair function calls.

- R. Niwa

Received on Saturday, 31 August 2013 00:22:49 UTC