W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > February 2011

[Bug 12049] Script defer/async attributed have no realistic usage scenario

From: <bugzilla@jessica.w3.org>
Date: Sun, 13 Feb 2011 14:29:36 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1PocxE-0002hA-K5@jessica.w3.org>

--- Comment #4 from Kyle Simpson <w3c@getify.myspamkiller.com> 2011-02-13 14:29:36 UTC ---
If you're suggesting that the default behavior of script tags in markup change
from not-async to async, I think that's an impossible change to request. Far
too many websites expect that scripts execute in the order they appear in the
DOM. This would cause enormous web-compat issues with millions of sites. By
definition, when `async` is turned on, scripts execute in "as-soon-as-possible"

BTW, the "async=false" thing, which I was the one primarily who pushed that
proposal, that's not about script default behavior with markup script elements.
It's about the default behavior of script-created script elements. An implicit
assumption was made there, mostly for web-compat reasons, that if people do
script tags in markup, by default they want ordered execution, and if they do
them with a script loader, by default they want un-ordered execution. And we
gave them the ability to opt-out of the default behavior in either case.

If you're suggesting that the default behavior of script tags in markup change
from not-defer to defer, this has less of a potential for breaking web-compat,
but is still a really bad idea in my opinion.

Before I explain *why* I think it's a bad idea, though... how would you suggest
that a web author opt a markup script element out of `defer` (or `async`)
behavior? In markup, you *cannot* do "defer=false" (boolean attributes in HTML
don't work like that). So, you'd have to invent a new attribute like "noDefer"
or "noAsync". Is that what you're thinking?


Regardless, you're essentially saying that most people want their scripts to
defer. But that's not true. A lot of websites use heavy amounts of JavaScript
to build out the UI of their site/application, and they *want* the blocking
behavior of their script loading because they don't have any content they want
to show to the user until the JavaScript has had a chance to attach and build
out the presentation.

In all cases, I disagree completely with the notion that less control over such
behavior is appropriate -- in fact, the opposite, I'm lobbying for more
controls. I also think it's impossible to assert that the long-standing default
is now irrelevant. Web authors have the ability to opt-in to be more performant
behavior, assuming they understand the UX implications. 

I don't think we should assume that every site on the net already has that
figured out yet, though. There's still LOTS of work to be done in that area.
This proposal may be more appropriate 6-8 years from now, but at the moment, I
think it's completely the wrong thing for today's (and tomorrow's) web.

Also, one last critical thing this proposal would break on millions of sites:
DOM-ready detection. Libraries like jQuery rely on the fact that it was loaded
before DOM-ready (so that the library itself can detect DOM-ready), or the
library has to rely on some hacky fallbacks (depending on different browsers)
to try and detect if DOM-ready has already passed. BUT, while jQuery has this
logic in it, several other major JavaScript libraries (like Prototype and Dojo)
do *not* have the same "safe DOM-ready" detection logic, and would thus
completely die if loaded via a script with defer set on. We simply cannot
expect millions of sites using such libraries to change their script tags to
somehow opt out of defer.

There's millions of sites out there who rely on the script loading of script
tags in markup to block the page's DOM-ready, so that when DOM-ready fires,
they can assume that all scripts are loaded. I don't think this is a GOOD
practice to make that assumption (in fact, I think it's a terrible
anti-pattern). But nonetheless, it's true on the vast majority of sites
(especially those using jQuery, where that pattern is most prevalent).

Bottom line: I think it's an impossible task (any time soon enough to be still
in my career) to change such a fundamental default. Even if the spec did it, I
think the browsers would universally push back because of such fears about
compat. The burden would be on you to prove that 99.9% of sites wouldn't break
with your proposal, and I think that's a pretty tough task to do.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Sunday, 13 February 2011 14:29:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:41 UTC