Re: John Resig Video

Garrett Smith wrote:
Richard Cornford wrote:
Garrett Smith wrote:

To say 'it doesn't matter when this script executes' is false.

Isn't that precisely the implication of the DEFER attribute;
that it should only be used on script resources where it
doesn't matter when the script executes?

The defer attribute tells the parser that it can continue
downloading and rendering the page.

As stated in the HTML spec.

Modern browsers perform parallel downloads.

Non-modern browsers probably also do/did that, subject to simultaneous HTTP connection constraints.

The resources are downloaded asynchronously, interpreted in
sequential order.

But which sequential order; the order in which they are requested, the order in which they start to arrive or the order in which they finish arriving? Granted you cannot do the execution for the global execution context until the entire source code ahs been received (because variable instantiation may be inflamed by even the last line of code to arrive) but you certainly can tokenise and parse as the source code is delivered.

The HTML 5 draft proposes an async attribute[1]:-
| If the async attribute is present, then the script will be
| executed asynchronously, as soon as it is available.

That fulfills the "doesn't matter when it executes" statement.

In what sense?

The order scripts are executed matters very much.

Can "matter very much", even 'usually matters very much', but
there are scripts for which it doesn't matter at all.

Sure. It can go either way. The result of executing of a deferred script would usually be different.

There is something missing from that last statement.

Deferred scripts have an execution order.

But not any sort of specified execution order. Just the order in
which particular instances of browser software can be observed to
execute them.

That order is not stated by the specification,

There you go.

but IE does execute the scripts in a certain order.

It is not in the nature of computer software to do this sort of
thing randomly. It is certain that what IE does with a deferred
script could be expressed in terms of an algorithm, and likely
that the outcome of applying that algorithm will be consistent,
predictable and systematic.

The async attribute allows the browser to run the script when
it is loaded. The defer attribute is implemented to preserve
a particular order.

How something has been implemented only says so much about how it may be implemented.

The download of the resource is not coupled to its execution.

Beyond being a necessary pre-requisite.

The defer does attribute not indicate execution order. Non-deferred scripts are executed in order; deferred scripts are executed when
the DOM is ready.

Ready for what? You risk ending up with a definition of "ready" that means no more than that deferred scripts are executed when they are executed. If the browser finishes parsing the HTML, building the DOM, executing inline scripts, etc, before the deferred script has finished downloading then doesn't it still have to wait before it gets executed? And in environments were defer is not implemented that same script is going to processed inline and so be executed before the DOM is complete, which could still happen even if defer is implemented as "can continue parsing ..." does not say 'MUST continue parsing ... ' or deny the possibility of the script being executed asynchronously by a separate thread while the parser continues parsing.

There is not a standard that defines the order for deferred scripts.

Both order and timing are left open-ended by the HTML specification. Thus the only rational response would be to only use DEFER with scripts where neither matter.

What IE does with inline scripts is weird/complicated.

From some perspective or another, everything web browsers do is weird
and/or complication, but little is gained by saying just that.

Regarding the statement:
| it can still document write and when it document write's, it
| still does it in the correct location

- which browser does that?

Isn't that going to hang on the intended meaning of "correct".
As a

The meaning of "location" could be "order in the html source" or "window.location". I think I got what he meant.

But you are not going to say what that was?

script that includes a - document.write - is not (generally) a
suitable candidate for use with the DEFER attribute (as stated
in the HTML spec) we are in the area of 'error correction' (well,
at least at "garbage in ...") and at that point expectations of
what qualifies as "correct" vary enormously (and can be very
personal).

I would think that if the thing you are doing (using -
document.write - in a DEFER script) makes no sense then whatever
outcome you get can be regarded as the "correct" outcome.

When he said "correct location," I think he meant, "where
document.write would normally go to" (in a non-deferred script).

However, John should already know that it does not work that way.

Or at lest be able to see how very unlikely it would that things could work in that way.

I pointed out that calling document.write "onready" does not
work:-
http://ejohn.org/blog/degrading-script-tags/#comment-319983

You may have been ignored. That happens.

The HTML 4.01 specification states that a deferred script
cannot use javascript to document.write.

More like it implies that such a script should not. It is the
ECMAScript spec and the DOM/browser object model that determine
whether it can be done.

<snip>
I am surprised at what I heard in that video.

Having read:-

"Since valid HTML is simply a subset of XML, having an efficient
way to parse and browser DOM documents is an absolutely essential
for making JavaScript development easier." - John Resig: Pro
JavaScript Techniques. 2006


That was 2006. It is been three years and a lot of c.l.js
criticism later.

You don't have to have that much actual knowledge to see that the relationship between the first assertion and the second in no way warrants a "since" attempting to link the two.

He is still saying stuff that appears to be totally made up.

Is "made up" an appropriate way of labelling a misconception? It implies deliberate intent. It is hard to see how anyone could believe they could get away with that in a technical field where facts can be objectively verified/refuted. And what would be to gain?

- no statements from that source will surprise me. (His new
book has some equally bizarre aggregations of words.)

Are you going to be his technical editor?

If asked, have time, are properly paid and with a suitable contract (guaranteeing anonymity) I would, so probably not.

Richard.

.

Relevant Pages

  • Files appear to be cross linked
    ... script requires a number of standard environment variables to be set ... so it calls a second shell script to set these at the session level, ... control should return to the first shell script, ... that the script executes to the last line prior to the displaying of ...
    (comp.unix.solaris)
  • Re: John Resig Video
    ... Modern browsers perform parallel downloads. ... The statement I was commenting on came at the end of a paragraph that commenced "The defer attribute tells the parser that it can continue downloading and rendering the page", so an example that does not feature the DEFER attribute seems to serve no purpose as a clarification of what you were talking about. ... That fulfills the "doesn't matter when it executes" statement. ... It would be somewhat desirable to have better control over script ...
    (comp.lang.javascript)
  • Permission to execute jobs but nothing else
    ... This script is executed by a scheduled SQL job which ... executes a CSCRIPT command pointing to this script on the ... to me as long as I can setup a weak Login ID that can do ...
    (microsoft.public.sqlserver.security)
  • Re: How about a stupid question?
    ... it reads it and executes it. ... > 2) if the shell is run as a non-login, interactive shell, it only attempts to ... > 3) When bash is started non-interactively, to run a shell script, for example, ...
    (comp.unix.solaris)
  • Problem using Xterm in Expect script
    ... I have written a script which will spawn an xterm and executes the ... got to rwc test ...
    (comp.lang.tcl)