Dynamic Script Execution Order - Revision history

Getify: bolding the update text

2011-02-21T14:51:13Z

bolding the update text

← Older revision		Revision as of 14:51, 21 February 2011
Line 1:		Line 1:
	This page is intended to formalize the discussion around an important but currently underserved use-case (in both spec and various browser implementations): the need for a dynamic script loading facility that can download resources in parallel but ensure that they execute serially in insertion order, for dependency reasons.		This page is intended to formalize the discussion around an important but currently underserved use-case (in both spec and various browser implementations): the need for a dynamic script loading facility that can download resources in parallel but ensure that they execute serially in insertion order, for dependency reasons.

	*Update: The main proposal listed here, also known as "async=false", was recently [http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295 officially adopted] [http://ln.hixie.ch/?start=1296711456&count=1 by Ian Hixie] into the HTML Specification.		'''*Update: The main proposal listed here, also known as "async=false", was recently [http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295 officially adopted] [http://ln.hixie.ch/?start=1296711456&count=1 by Ian Hixie] into the HTML Specification.'''
	[[User:Getify\|Getify]] 00:31, 14 February 2011 (UTC)		[[User:Getify\|Getify]] 00:31, 14 February 2011 (UTC)

Getify: adding note about adoption into the spec

2011-02-14T00:31:49Z

adding note about adoption into the spec

← Older revision		Revision as of 00:31, 14 February 2011
Line 1:		Line 1:
	This page is intended to formalize the discussion around an important but currently underserved use-case (in both spec and various browser implementations): the need for a dynamic script loading facility that can download resources in parallel but ensure that they execute serially in insertion order, for dependency reasons.		This page is intended to formalize the discussion around an important but currently underserved use-case (in both spec and various browser implementations): the need for a dynamic script loading facility that can download resources in parallel but ensure that they execute serially in insertion order, for dependency reasons.

			*Update: The main proposal listed here, also known as "async=false", was recently [http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295 officially adopted] [http://ln.hixie.ch/?start=1296711456&count=1 by Ian Hixie] into the HTML Specification.
			[[User:Getify\|Getify]] 00:31, 14 February 2011 (UTC)

	A long email thread on the W3C public-html list, which began [http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html here] and for which a recent message is [http://lists.w3.org/Archives/Public/public-html/2010Oct/0415.html here], has been discussing this problem, but the email thread is becoming unruly and hard to track, so this wiki page will now be the official location to discuss the topic.		A long email thread on the W3C public-html list, which began [http://lists.w3.org/Archives/Public/public-html/2010Oct/0088.html here] and for which a recent message is [http://lists.w3.org/Archives/Public/public-html/2010Oct/0415.html here], has been discussing this problem, but the email thread is becoming unruly and hard to track, so this wiki page will now be the official location to discuss the topic.

Annevk: /* Do nothing and encourage vendors implement the existing suggestion */

2011-01-26T12:10:17Z

Do nothing and encourage vendors implement the existing suggestion

← Older revision		Revision as of 12:10, 26 January 2011
Line 377:		Line 377:


			[[Category:Proposals]]
	[[Category:~~Feature Request\|Dynamic Script Execution Order~~]]

Serverherder: /* Alternate Proposals */

2010-12-23T20:58:48Z

Alternate Proposals

← Older revision		Revision as of 20:58, 23 December 2010
Line 363:		Line 363:

	[http://lists.w3.org/Archives/Public/public-html/2010Dec/0174.html Need to: "preload" CSS and JS]		[http://lists.w3.org/Archives/Public/public-html/2010Dec/0174.html Need to: "preload" CSS and JS]

			==== Do nothing and encourage vendors implement the existing suggestion ====
			As noted by Getify above, the spec all ready makes the suggestion that a script's SRC attribute be fetched immediately upon assignment.

			[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

			While not explicit, it seems the specification all ready deals with the use-case this is hoping to achieve: It makes parallel loading scripts '''optional'''. Execution order can all ready be handled by loaders using onload-chaining. Therefore, parallel loading can be achieved, but only in browsers that have chosen to implement the suggestion.

			Given this, the discussion can shift to:
			# Should the suggestion be changed to a mandate?
			# Should the specification include a way to '''force''' parallel loading?
			# Should we be petitioning vendors, not the the W3C, to implement the existing suggestion?



	[[Category:Feature Request\|Dynamic Script Execution Order]]		[[Category:Feature Request\|Dynamic Script Execution Order]]

Getify: updating comments around the "preloading" technique IE (and the spec) give

2010-12-23T19:32:36Z

updating comments around the "preloading" technique IE (and the spec) give

← Older revision		Revision as of 19:32, 23 December 2010
Line 60:		Line 60:
	</blockquote>		</blockquote>

	Moreover, you're suggesting something that is AFAIK only IE right now, and definitely appears to not be standardized. In the same way that I'm hesitant to continue pinning loading behavior on hacks like the invalid type attribute value, I wouldn't want to approach loading with this technique (even if it were proven reliable on all IE's under all caching circumstances) unless it was a serious proposal to the W3C to have this technique be the new standard (as opposed to the current proposal, as implemented by Mozilla and Webkit now).		Moreover, you're suggesting something that is AFAIK only IE right now, <del>and definitely appears to not be standardized. In the same way that I'm hesitant to continue pinning loading behavior on hacks like the invalid type attribute value, I wouldn't want to approach loading with this technique (even if it were proven reliable on all IE's under all caching circumstances) unless it was a serious proposal to the W3C to have this technique be the new standard (as opposed to the current proposal, as implemented by Mozilla and Webkit now).</del>

			Update: the behavior is in fact in the spec as a suggestion (aka, with "may" instead of "should"). The wording in question is located in [http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML5 4.3.1, "Running A Script" algorithm] step, 12, which states:

			<blockquote style="background-color:#f1dac9">
			For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
			</blockquote>

			[[User:Getify\|Getify]] 19:32, 23 December 2010 (UTC)

	<blockquote style="background-color: #EEEEEE">		<blockquote style="background-color: #EEEEEE">
	I think you're right: Only IE impelements this event and property on script elements. The readystatechange event, however, is widely understood due to the XmlHttpRequest implementation and `readyState` property has been added to the `document` in WebKit, Mozilla and IE.		I think you're right: Only IE impelements this event and property on script elements. The readystatechange event, however, is widely understood due to the XmlHttpRequest implementation and `readyState` property has been added to the `document` in WebKit, Mozilla and IE.
	</blockquote>		</blockquote>

	That having been said, I think this is at least a viable candidate for "Alternate Proposals" and deserves to be listed as such. As always, I welcome input from the community on all the ideas presented here, including this one. But, since the main proposal (async=false) is already being implemented by at least two major browsers, I'm not sure if the tide will be changed or not.		That having been said, I think this is at least a viable candidate for "Alternate Proposals" and deserves to be [[Dynamic_Script_Execution_Order#readyState_.22preloading.22\|listed as such]]. As always, I welcome input from the community on all the ideas presented here, including this one. But, since the main proposal (async=false) is already being implemented by at least two major browsers, I'm not sure if the tide will be changed or not.

	</blockquote>		</blockquote>

Getify: adding link to mozilla bug about attribute/property consistency

2010-12-22T03:07:10Z

adding link to mozilla bug about attribute/property consistency

← Older revision		Revision as of 03:07, 22 December 2010
Line 152:		Line 152:

	* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=602838 Mozilla Bug #602838]</cite>		* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=602838 Mozilla Bug #602838]</cite>

			* <cite>[https://bugzilla.mozilla.org/show_bug.cgi?id=620852 Mozilla Bug #620852]</cite>

	* <cite>[https://bugs.webkit.org/show_bug.cgi?id=50115 Webkit Bug #50115]</cite>		* <cite>[https://bugs.webkit.org/show_bug.cgi?id=50115 Webkit Bug #50115]</cite>

Getify: adding proposal amendment: regarding async attribute/property consistency

2010-12-22T03:05:57Z

adding proposal amendment: regarding async attribute/property consistency

← Older revision		Revision as of 03:05, 22 December 2010
Line 191:		Line 191:

	It's also important to note that there is no implied or requested effect or dependency between script-inserted script elements and parser-inserted script elements -- the two types of scripts would load and execute in entirely separate behavioral sandboxes.		It's also important to note that there is no implied or requested effect or dependency between script-inserted script elements and parser-inserted script elements -- the two types of scripts would load and execute in entirely separate behavioral sandboxes.

			==== Proposal Amendment: Need Attribute/Property Semantic Inconsistency ====
			In order to achieve consistency between the semantics of how the parser-inserted script element's `async` attribute and the script-inserted script element's `async` property behave, a slight change needs to be made to the value parsing/interpretation for parser-inserted script elements' `async` attribute.

			If a parser-inserted script element has the `async` attribute present, but its value is exactly "false" (or any capitalization thereof), the script element should behave EXACTLY as if no `async` attribute were present.

			If the attribute is present and either has no value, or has any other value except "false" (for instance, "true" or "async"), then it should be interpreted to be turning on "async" for that element.

			Because it is highly unlikely (and indeed, quite irrational) that any existing web content is doing `async="false"` in HTML markup and yet still expecting "async" behavior to be turned on, it is pretty unlikely that this minor interpretation change will cause backwards-compatibility issues.
			[[User:Getify\|Getify]] 03:05, 22 December 2010 (UTC)

	==== Proposal Amendment: Events ====		==== Proposal Amendment: Events ====

Getify: adding comment about spec's support for the `readyState` proposal

2010-12-20T14:10:58Z

adding comment about spec's support for the `readyState` proposal

← Older revision		Revision as of 14:10, 20 December 2010
Line 326:		Line 326:

	In this way, a script loader could "preload" a set of scripts all in parallel, but control their execution order by delaying the appending of the element to the DOM until execution is desired.		In this way, a script loader could "preload" a set of scripts all in parallel, but control their execution order by delaying the appending of the element to the DOM until execution is desired.

			'''Update''' [[User:Getify\|Getify]] 14:10, 20 December 2010 (UTC)

			[http://www.w3.org/TR/html5/scripting-1.html#running-a-script HTML Spec, 4.3.1, 'Running a script' algorithm]

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

			<blockquote>
			For performance reasons, user agents may start fetching the script as soon as the attribute is set, instead, in the hope that the element will be inserted into the document. Either way, once the element is inserted into the document, the load must have started. If the UA performs such prefetching, but the element is never inserted in the document, or the src attribute is dynamically changed, then the user agent will not execute the script, and the fetching process will have been effectively wasted.
			</blockquote>

			This seems to be the spec stating that browsers may do what IE's behavior on scripts does, which is to start fetching the resource once the `src` property is set, but not execute it until the script element is inserted into the DOM.

			It would seem then that browsers could/should be petitioned to consider implementing this suggestion, perhaps taking the `readyState` implementation from IE as guidance. While I'm still not sure that this would be my preferred method of solving the overall use-case in discussion on this page, it would be an option for such, and it would also help other use-cases, such as those being discussed in this W3C public-html thread:

			[http://lists.w3.org/Archives/Public/public-html/2010Dec/0174.html Need to: "preload" CSS and JS]


	[[Category:Feature Request\|Dynamic Script Execution Order]]		[[Category:Feature Request\|Dynamic Script Execution Order]]

Getify: reply comment regarding "load" event semantics

2010-12-15T20:33:27Z

reply comment regarding "load" event semantics

← Older revision		Revision as of 20:33, 15 December 2010
Line 313:		Line 313:
	Both seem to violate current `onload` semantics.		Both seem to violate current `onload` semantics.
	[[User:Serverherder\|Serverherder]] 20:27, 15 December 2010 (UTC)		[[User:Serverherder\|Serverherder]] 20:27, 15 December 2010 (UTC)

			<blockquote style="background-color:#ccc">
			As far as I'm concerned, I think the "load" event should happen immediately after a script loads, but before it executes, as I spell out in the [[Dynamic_Script_Execution_Order#Proposal_Amendment:_Events\|Events proposal ammendment section]]. [[User:Getify\|Getify]] 20:33, 15 December 2010 (UTC)
			</blockquote>

	</blockquote>		</blockquote>

Serverherder: /* Explicit support for "text/cache" MIME type behavior */

2010-12-15T20:27:22Z

Explicit support for "text/cache" MIME type behavior

← Older revision		Revision as of 20:27, 15 December 2010
Line 308:		Line 308:

	The browser would probably need to keep track (via some internal flag) that the script node is only ever executed once. Also, it's an open question if such a "cached" script node should be able to have its script content modified before execution via the `text` property.		The browser would probably need to keep track (via some internal flag) that the script node is only ever executed once. Also, it's an open question if such a "cached" script node should be able to have its script content modified before execution via the `text` property.
			<blockquote style="background-color:#eee">
			And does the onload event fire again after the script executes? <br/>
			Or only when it's loaded? <br/>
			Both seem to violate current `onload` semantics.
			[[User:Serverherder\|Serverherder]] 20:27, 15 December 2010 (UTC)
			</blockquote>

	==== readyState "preloading" ====		==== readyState "preloading" ====