Re: [whatwg] Script preloading

FWIW, I'd be much more in favor of Jonas' proposal, at this point, than the dependencies=.. proposal. The `noexecute/execute()` is conceptually pretty similar to the preload proposal I've been pushing. As far as I can tell from how Jonas describes it, it looks like it would fit most of the use-cases I've put forth as caring about.

There's a few details to iron out, however:

1. Will it cause confusion for authors that the behavior of the `onload` event on script elements is modified from its current long-standing "loaded and executed" to just "loaded" when in the presence of the `noexecute` attribute/property? Seems like it could cause a fair bit of confusion.

That's why the preload proposal proposed another event (`onpreload`), to reduce the conflation/confusion. But it might be tenable for authors. I'm sure as a script loader author I can work around it just fine if I need to.



2. What will the interaction be, if any different, with the `onerror` events? Script preloading not-withstanding, there's little cross-browser compatibility on the topic of just what exactly constitutes a script "error" event. Some browsers fire it for all of the common network error conditions (404, 5xx), others only some of them.

In particular, if we're just building off existing mechanisms and not inventing whole new ones, it would be nice, from an author perspective, if EITHER the `onload` or the `onerror` event ALWAYS fired, and never both, and never neither, and if it was consistent when each happened.

I asked a couple of years ago on this list for that exact thing to be clarified in the spec, and was told at that time that implementors were left with the discretion, which accounted for the disparity. I of course would renew my request to reverse that and land on some common spec.



3. The main reason people seem to favor the `dependencies=..` proposal or its variants is the idea of "markup-only" preloading, where the loading of a subsequent script tag or tags can implicitly be the signal to execute another previously loaded-and-waiting script. Not clear if/how Jonas' proposal could suit that view. Perhaps similar to how I proposed handling that desire in the preload proposal.



--Kyle




On Jul 22, 2013, at 4:00 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, Jul 9, 2013 at 12:39 PM, Ian Hickson <ian@hixie.ch> wrote:
>> The proposals I've seen so far for extending the spec's script preloading
>> mechanisms fall into two categories:
>> 
>> - provide some more control over the mechanisms already there, e.g.
>>   firing events at various times, adding attributes to make the script
>>   loading algorithm work differently, or adding methods to trigger
>>   particular parts of the algorithm under author control.
>> 
>> - provide a layer above the current algorithm that provides strong
>>   semantics, but that doesn't have much impact on the loading algorithm
>>   itself.
>> 
>> I'm very hesitant to do the first of these, because the algorithm is _so_
>> complicated that adding anything else to it is just going to result in
>> bugs in browsers. There comes a point where an algorithm just becomes so
>> hard to accurately test that it's a lost cause.
>> 
>> The second seems more feasible, though.
> 
> FWIW, I don't really know what functionality you put in the first
> category, and what you put in the second.
> 
> However, as an implementor, I definitely think that the current
> proposal is more complicated to implement than the proposal that I
> pushed for before. I.e. adding a "noexecute" attribute on the <script>
> element which causes the script element not to execute when it
> normally would. Instead it fires the "load" event when the script has
> been loaded and does nothing more.
> 
> Once the page wants the script to execute, it would call a new
> .execute() function on the script which would cause the loaded script
> to execute. If the function is called before the load event has fired,
> an InvalidStateError exception would be thrown.
> 
> I could absolutely believe that this is harder to specify than your
> proposal. I haven't looked at the spec in enough detail to know. But
> it's definitely easier to implement in at least Gecko. I'd be
> interested to hear what other implementors think. And implementations
> have a higher priority than spec writing in the hierarchy of
> constituents.
> 
> I also think it's a simpler model for authors to understand.
> 
> Now, even higher priority in the hierarchy of constituents are
> authors. So if your proposal above is written with the goal of
> creating something authors prefer over the noexecute proposal, then
> that definitely seems like the right goal. I haven't read enough of
> the feedback here to get a clear picture of if the proposal in this
> thread is considered better than noexecute.
> 
> I could definitely see that the "dependencies" feature could be
> attractive if it indeed would let authors avoid manually scheduling
> scripts for execution. But as always when building high-level
> features, there's a risk that if they don't solve the use-cases
> exactly, that they won't get used.
> 
> / Jonas

Received on Monday, 22 July 2013 21:36:22 UTC