This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22696 - inline <script async>
Summary: inline <script async>
Status: RESOLVED WONTFIX
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 enhancement
Target Milestone: Needs Impl Interest
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-16 17:17 UTC by Ian 'Hixie' Hickson
Modified: 2014-09-26 21:24 UTC (History)
3 users (show)

See Also:


Attachments

Description Ian 'Hixie' Hickson 2013-07-16 17:17:28 UTC
On Thu, 30 Aug 2012, Jonas Sicking wrote:
> 
> The current ES6 drafts have the ability to declaratively linking to
> script modules. These modules live in external resources, i.e. they
> are a separate script file. The intent is that these should be
> loaded before the script is executed and so no blocking IO is
> required, even though the syntax "looks" synchronous, i.e. doesn't
> have any asynchronous callbacks or similar.
> 
> This is very similar to how the @import rules work in CSS.
> 
> You can read more about them at
> http://calculist.org/blog/2012/03/29/synchronous-module-loading-in-es6/
> 
> This will work fine in HTML for plain <script src="..."> and
> <script> appearing in the markup. The browser simply blocks the
> parser until all dependent script modules have been loaded and then
> executes the script like normal. However it's not currently possible
> to do something like
> 
> <script defer>
> import $ from "jquery.js";
> $(...);
> </script>
> 
> or
> 
> <script async>
> import $ from "jquery.js";
> $(...);
> </script>
> 
> since the defer and async attributes are ignored for inline scripts.
> This technically works, but means that you can't take advantage of
> the performance advantages that defer and async provides, unless you
> also break out your script into an external file which cause an
> additional resource load.
> 
> We could define that async and defer only has effect on inline
> scripts if these scripts contain references to external modules.
> However that means making their behavior a lot more inconsistent and
> error prone. Especially if contents of the script element contains
> server-side generated code which may or may not include module
> references.
> 
> So I propose that we make defer and async consistently apply in
> inline scripts. The defer attribute used to apply to inline scripts
> in the firefox and IE implementations. It no longer does in Firefox,
> but I haven't tried in IE. However this still seems to lessen the
> risk of webcompat regressions significantly. The async attribute is
> new enough that I wouldn't be worried that there is a lot of content
> out there that would be affected by this change.
Comment 1 Paul Hammant 2014-02-02 18:52:55 UTC
I sure hope this issue isn't abandoned.

I would like defer to be allowed for inline scripts too.  I'm not proposing anything fancy, as this example that should be compatible to 'HTML < 5' too:

<script defer src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>

<script type="text/javascript">
function fixupText(attr) {
 // etc
}  
</script>

<script defer type="text/javascript"> 
$(document).ready(function() {
  fixupText("blah");
});

Script #1 and #3 are 'defer' types. Script #2 is not, but is a function only invoked in script #3.

Whether or not the browser is HTML-5.x compliant, the right thing should happen here. defer is either obeyed (in order), or ignored.
Comment 2 Ian 'Hixie' Hickson 2014-02-07 18:17:46 UTC
This isn't abandoned, it's just awaiting implementation interest from two vendors. Right now, we have one vendor interesting (sicking).
Comment 3 Ian 'Hixie' Hickson 2014-09-26 21:24:02 UTC
Closing this for now. If you're interested in this, I encourage you to follow up on this thread:

   http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Sep/0012.html