[whatwg] should async scripts block the document's load event?

[Brian Kuhn]

Right.  Async scripts aren't really asynchronous if they block all the
user-visible functionality that sites currently tie to window.onload.

I don't know if we need another attribute, or if we just need to change the
behavior for all async scripts.  But I think the best time to fix this is
now; before too many UAs implement async.

-Brian





On Thu, Feb 11, 2010 at 10:41 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> Though what we want here is a DONTDELAYLOAD attribute. I.e. we want
> load to start asap, but we don't want the load to hold up the load
> event if all other resources finish loading before this one.
>
> / Jonas
>
> On Thu, Feb 11, 2010 at 10:23 PM, Steve Souders <whatwg at souders.org>
> wrote:
> > I just sent email last week proposing a POSTONLOAD attribute for scripts.
> >
> > -Steve
> >
> > On 2/10/2010 5:18 PM, Jonas Sicking wrote:
> >>
> >> On Fri, Nov 6, 2009 at 4:22 PM, Brian Kuhn<bnkuhn at gmail.com>  wrote:
> >>
> >>>
> >>> No one has any thoughts on this?
> >>> It seems to me that the purpose of async scripts is to get out of the
> way
> >>> of
> >>> user-visible functionality.  Many sites currently attach user-visible
> >>> functionality to window.onload, so it would be great if async scripts
> at
> >>> least had a way to not block that event.  It would help minimize the
> >>> affect
> >>> that secondary-functionality like ads and web analytics have on the
> user
> >>> experience.
> >>> -Brian
> >>>
> >>
> >> I'm concerned that this is too big of a departure from how people are
> >> used to<script>s behaving.
> >>
> >> If we do want to do something like this, one possibility would be to
> >> create a generic attribute that can go on things like<img>,<link
> >> rel=stylesheet>,<script>  etc that make the resource not block the
> >> 'load' event.
> >>
> >> / Jonas
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100212/30f0b8f2/attachment-0002.htm>