Re: Executing script-inserted external scripts in insertion order

On Sun, Oct 17, 2010 at 6:23 PM, Getify <getify@gmail.com> wrote:
> ?> As of http://trac.webkit.org/changeset/67245, WebKit is in compliance
>>
>> with HTML5 and no longer hits the network for scripts it doesn't plan
>> to execute.
>
> It also occurs to me that while this is Webkit getting into compliance with
> spec (which I think is currently short-sighted on this topic), in and of
> itself admirable progress, it represents a change which is quite problematic
> for backwards compatibility because it changes a fundamental behavior in a
> way that is not feature-testable.
>
> This means that LABjs and any other sites and libs that have relied on this
> behavior in Webkit (Safari and Chrome, etc) will now be broken in a way that
> cannot just be corrected with a feature-test patch, but which must instead
> fall back on more crappy browser sniffing/inferences to fix compat-wise.

Can you provide examples of sites that break?  It's easier to reason
about concrete broken sites than about these things in the abstract.

> I think it even further underscores the need for a spec change (that all the
> browsers can agree on) which gives a reliable and straightforward answer to
> "parallel-load-serial-execute" use case in a performance-oriented and
> feature-testable way.

Isn't this what defer does?  I guess you're saying it's not
performance-oriented?

> Since Webkit has made this change that is in a non-compat way with existing
> content, are they willing to support the proposed change as a
> feature-testable addition (to spec and the browsers) that provides an answer
> to the use-case?

I believe tonyg said that he thought the proposed change would slow
down a bunch of real-world web sites that use script-inserted scripts
to achieve parallel loading in existing browsers.  Generally, folks
aren't going to be that exciting about slowing down web sites.

Adam

Received on Monday, 18 October 2010 04:01:01 UTC