Script Execution Control - Revision history

Getify: updating link to spec location for discussion about the "true preloading" technique.

2012-09-12T15:17:12Z

updating link to spec location for discussion about the "true preloading" technique.

← Older revision		Revision as of 15:17, 12 September 2012
Line 81:		Line 81:
	This proposal is, in spirit, very similar to [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29\|Proposal 1]], but is a little bit simpler (in that it doesn't add a new property or unprecedented event mechanism). Whereas Proposal 1 seeks to add a `preload` attribute to the script element to signal that it should have the preloading (load-but-not-execute) behavior, this proposal builds on automatic behavior for preloading already suggested by the current HTML Specification:		This proposal is, in spirit, very similar to [[Script_Execution_Control#Proposal_1_.28Nicholas_Zakas.29\|Proposal 1]], but is a little bit simpler (in that it doesn't add a new property or unprecedented event mechanism). Whereas Proposal 1 seeks to add a `preload` attribute to the script element to signal that it should have the preloading (load-but-not-execute) behavior, this proposal builds on automatic behavior for preloading already suggested by the current HTML Specification:

	[http://www.w3.org/TR/html5/~~scripting~~-1.html#~~running~~-a-~~script~~ HTML Spec, 4.3.1, '~~Running~~ a script' ~~algorithm~~]		[http://www.w3.org/TR/html5/the-script-element.html#script-processing-src-prepare HTML Spec, 4.3.1, 'Preparing a script']

	Specifically, in step 12 (which is about fetching a `src` URL):		Specifically, in step 14 (which is about fetching a `src` URL):

	<blockquote>		<blockquote>

Getify: adding limitations for proposal 3, as well as links to discussion

2011-03-04T23:56:33Z

adding limitations for proposal 3, as well as links to discussion

← Older revision		Revision as of 23:56, 4 March 2011
Line 173:		Line 173:
	* In addition to programmatic preloading, scripts can also be preloaded in markup and later activated by scripts.		* In addition to programmatic preloading, scripts can also be preloaded in markup and later activated by scripts.

			--[[Talk:Script_Execution_Control#Discussion_for_2.3_Proposal\|discussion]]

			==== Limitations ====
			1. From the markup perspective, this approach does not have graceful degradation, since in browsers without `noexecute` support, such scripts would execute right away, even though told not to. Markup doesn't provide the ability to feature-detect.
			* [[Talk:Script_Execution_Control#Discussion_for_2.3_Proposal\|discussion]]

			2. As stated in support sections for the other proposals, this proposal requires a fundamental change to how IE operates. As such, the feasibility of getting such a change into a released version of IE is, at best 18-24 months down the road, and that's if IE even agreed to change their existing preloading behavior.
			* [[Talk:Script_Execution_Control#Discussion_for_2.3_Proposal\|discussion]]

	== Insufficient Solution Suggestions ==		== Insufficient Solution Suggestions ==

Glenn: add noexecute

2011-03-04T22:00:06Z

add noexecute

← Older revision		Revision as of 22:00, 4 March 2011
Line 135:		Line 135:

	5. This proposal doesn't specify fetch error handling. onerror is currently not fired on scripts which are not in a document.		5. This proposal doesn't specify fetch error handling. onerror is currently not fired on scripts which are not in a document.

			=== Proposal 3 (Glenn Maynard) ===

			This proposal keeps changes to script preparation and execution to a bare minimum. Changes are described in terms of actual spec changes, to describe its behavior clearly and to show how it fits in with the existing spec. Briefly, a "noexecute" attribute is added to block execution of the script, which is cleared to reenable execution. More precisely:

			* Add the following attribute definition:
			The noexecute attribute is a boolean attribute that indicates that the
			script should not be executed.
			* Add the following flag definition:
			The fifth is a flag indicating that a script is "pending-execution". Initially,
			script elements must have this flag unset. This flag is used to trigger execution
			if execution was deferred due to a noexecute attribute.
			* Add the following to "execute a script block", before "1. Initialize the script block's source as follows":
			0. If the element has a "noexecute" attribute, set the "pending-execution" flag
			and abort these steps.
			* For each part of step 15 "Then, the first ..." of "prepare a script", the noexecute attribute being set implies the async attribute is also set, eg. "... and the element has neither an async nor a noexecute attribute". That is, noexecute implies async.
			* If the "noexecute" attribute is changed, and the "pending-execution" flag is set, clear the "pending-execution" flag and queue a task to execute the script block.
			* When the fetch algorithm completes without error, fire a simple event named "fetch" at the element.

			Notes:

			* Invariant: if the "pending-execution" flag is set, the "already started" flag is also set.
			* The attribute name "noexecute" reflects its behavior more clearly than "preload". API naming should reflect what the API does, not name a use case.
			* For feature detection: typeof(document.createElement("script").noexecute) == "boolean".
			* Scripts are still only executed once, regulated by the "already started" flag.
			* The "pending-execution" flag is not copied to clones, so a script that has run "prepare a script" will run again in a clone.
			* The onfetch event is orthogonal to the rest, and should be fired whether or not noexecute is set. It's symmetric with onerror. (onreadystatechange is not recommended; it clashes with existing IE behavior. IE fires onreadystatechange with "loaded" for both success and error, making it hard to tell whether the load actually succeeded.) The "fetch" event isn't a new concept, it's simply the "load" of Progress Events-like contexts; a different name is used because script events already have a "load" event with a different meaning.
			* <script noexecute> is comparable to <style disabled>, which can also be used for advance resource loading.
			* The fetch event should be fired at most once, if the fetch algorithm finishes without error. That's not the top of "execute a script block" since that can be executed more than once. I'm not sure what the correct spec mechanism is to describe this.
			* This could be extended slightly to support inline scripts, with additional modifications to "prepare a script" step 15.

			Advantages:

			* Feedback is that this approach is more likely to see implementation in Gecko, and it avoids potential issues related to fetching resources when not added to a document without needing additional resource limiting.
			* DOM event consistency is maintained by not requiring elements be kept out of the document while loading. Fetch and error events can be captured, so event delegation continues to work consistently.
			* Fetch error handling (DNS errors, 404 errors) is handled with no changes to current behavior.
			* In addition to programmatic preloading, scripts can also be preloaded in markup and later activated by scripts.


	== Insufficient Solution Suggestions ==		== Insufficient Solution Suggestions ==

Glenn at 20:02, 4 March 2011

2011-03-04T20:02:48Z

← Older revision		Revision as of 20:02, 4 March 2011
Line 75:		Line 75:

	5. Doesn't support inline script "preloading" (see [[Script_Execution_Control#Limitations_2\|2.2.1.2]])		5. Doesn't support inline script "preloading" (see [[Script_Execution_Control#Limitations_2\|2.2.1.2]])

			6. This proposal doesn't specify fetch error handling. onerror is currently not fired on scripts which are not in a document.

	=== Proposal 2 (Kyle Simpson) ===		=== Proposal 2 (Kyle Simpson) ===
Line 131:		Line 133:

	4. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control#Discussion_for_2.2.1.4_Limitations]])		4. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control#Discussion_for_2.2.1.4_Limitations]])

			5. This proposal doesn't specify fetch error handling. onerror is currently not fired on scripts which are not in a document.

	== Insufficient Solution Suggestions ==		== Insufficient Solution Suggestions ==

Getify: /* Limitations */

2011-03-04T19:33:36Z

Limitations

← Older revision		Revision as of 19:33, 4 March 2011
Line 128:		Line 128:
	b) implement a cap on the number of scripts that will be preloaded, for instance at 200 or 500. If the cap is high enough, almost all normal sites which will use preloading will never need that many scripts waiting in a preloading queue. And the run-away sites will be prevented from consuming more than that cap. Any script preload requests above the cap will simply sit and wait for a preloading slot to become available. The resolution is to simply start executing some scripts by adding them to the page, thereby freeing up more preloading slots.		b) implement a cap on the number of scripts that will be preloaded, for instance at 200 or 500. If the cap is high enough, almost all normal sites which will use preloading will never need that many scripts waiting in a preloading queue. And the run-away sites will be prevented from consuming more than that cap. Any script preload requests above the cap will simply sit and wait for a preloading slot to become available. The resolution is to simply start executing some scripts by adding them to the page, thereby freeing up more preloading slots.

	-- a sub-idea for this suggestion is to have, instead of a hard-cap, a soft-cap, where if it's hit, a user-prompt happens (like the "long-running JavaScript" prompt), where a user can decide if the browser should be allowed to keep going with preloading or be capped.		* a sub-idea for this suggestion is to have, instead of a hard-cap, a soft-cap, where if it's hit, a user-prompt happens (like the "long-running JavaScript" prompt), where a user can decide if the browser should be allowed to keep going with preloading or be capped.

	4. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control#Discussion_for_2.2.1.4_Limitations]])		4. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control#Discussion_for_2.2.1.4_Limitations]])

Getify: /* Limitations */

2011-03-04T19:33:02Z

Limitations

← Older revision		Revision as of 19:33, 4 March 2011
Line 123:		Line 123:

	Two suggestions for how to address:		Two suggestions for how to address:

	a) implement some content-uniqueness in-memory cache which only keeps one copy of each unique set of resource content in memory, to prevent needless duplication. the algorithm for how to do this correctly is probably quite complicated to actually do.		a) implement some content-uniqueness in-memory cache which only keeps one copy of each unique set of resource content in memory, to prevent needless duplication. the algorithm for how to do this correctly is probably quite complicated to actually do.

Getify: adding cross-link to other proposal's limitation description on not supporting inline script "preloading"

2011-03-04T19:30:23Z

adding cross-link to other proposal's limitation description on not supporting inline script "preloading"

← Older revision		Revision as of 19:30, 4 March 2011
Line 73:		Line 73:

	4. Run-away memory usage (see [[Script_Execution_Control#Limitations_2\|2.2.1.3]])		4. Run-away memory usage (see [[Script_Execution_Control#Limitations_2\|2.2.1.3]])

			5. Doesn't support inline script "preloading" (see [[Script_Execution_Control#Limitations_2\|2.2.1.2]])

	=== Proposal 2 (Kyle Simpson) ===		=== Proposal 2 (Kyle Simpson) ===

Getify: adding cross-link to other proposal's limitation description on "run-away memory"

2011-03-04T19:28:08Z

adding cross-link to other proposal's limitation description on "run-away memory"

← Older revision		Revision as of 19:28, 4 March 2011
Line 71:		Line 71:

	3. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control#Discussion_for_2.2.1.4_Limitations]])		3. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control#Discussion_for_2.2.1.4_Limitations]])

			4. Run-away memory usage (see [[Script_Execution_Control#Limitations_2\|2.2.1.3]])

	=== Proposal 2 (Kyle Simpson) ===		=== Proposal 2 (Kyle Simpson) ===

Getify: updating link

2011-03-04T19:25:16Z

updating link

← Older revision		Revision as of 19:25, 4 March 2011
Line 125:		Line 125:
	-- a sub-idea for this suggestion is to have, instead of a hard-cap, a soft-cap, where if it's hit, a user-prompt happens (like the "long-running JavaScript" prompt), where a user can decide if the browser should be allowed to keep going with preloading or be capped.		-- a sub-idea for this suggestion is to have, instead of a hard-cap, a soft-cap, where if it's hit, a user-prompt happens (like the "long-running JavaScript" prompt), where a user can decide if the browser should be allowed to keep going with preloading or be capped.

	4. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control]])		4. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control#Discussion_for_2.2.1.4_Limitations]])

	== Insufficient Solution Suggestions ==		== Insufficient Solution Suggestions ==

Getify: updating link

2011-03-04T19:24:11Z

updating link

← Older revision		Revision as of 19:24, 4 March 2011
Line 70:		Line 70:
	[[User:Getify\|Getify]] 15:27, 14 February 2011 (UTC)		[[User:Getify\|Getify]] 15:27, 14 February 2011 (UTC)

	3. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control]])		3. DOM event propagation (discussion moved to: [[Talk:Script_Execution_Control#Discussion_for_2.2.1.4_Limitations]])

	=== Proposal 2 (Kyle Simpson) ===		=== Proposal 2 (Kyle Simpson) ===