[whatwg] Proposal for separating script downloads and execution
getify at gmail.com
Mon May 30 16:35:38 PDT 2011
> This isn't practical if the contents of the <script> are not under the
author's direct control. For example, an author that wanted to use jquery
would create a <script> tag with the src set to one of the popular jquery
mirrors (to maximize the chance of the resource being cached), but then have
no control over when the script actually evaluated.
EXACTLY! That is the main crux of the argument against those who keep saying
"just modify the script to not have side-effects". That sounds great in
theory, but it doesn't mean anything useful in practice on today's web with
today's scripts. And that reality isn't gonna change any time in the
foreseeable future. We need a better mechanism now, that recognizes the
realities of the current ecosystem of scripts that pages load.
> For this use case I think it would be handy to have a way to express
download this script but do not start evaluating it until I'm ready". As a
straw man, what about using the disable attribute? When the load completes,
if the disabled attribute is set then the script is not evaluated until the
disabled attribute is unset.
While I like the spirit of what you're asking for, you're actually going to
create more confusion by creating yet another proposal (#4 or #5 at this
point) to deal with, but your proposal is not fundamentally different/better
than the existing ones (in fact, it falls short). I really hope we can keep
bikeshedding and distractions to a minimum, at this point in the discussion,
as we already have lots of discussion baggage to wade through.
The `disabled` proposal is elegant in its simplicity, on the surface, and
would likely cover the use-cases well, but it maps functionally almost
identically to Nicholas' proposal (proposal #2). However, where Nicholas'
proposal is better though is that he covers the necessity for event handling
notification, where it's quite unclear how a simple notification of such
would happen within the semantics of a `disabled` script.
In any case, we've already treaded through the pluses and minuses of that
proposal, so we'd be re-treading the same ground to explore the `disabled`
proposal you put forth. I'd rather us focus our energy on helping to show
Ian (and others) the necessity of a solution, rather than on arguing (right
now) which solution is best.
More information about the whatwg