John Resig Video
Garrett Smith
http://www.youtube.com/watch?v=13-3VMzfU3Y
Some other comments mentioned that John was wrong about border-radius in
Opera (I didn't watch that far).
The first commenter stated:
"I'm really starting to think their are clones of you. There is just no
way you can be doing THIS much stuff and be one person!"
John seems to make stuff up when he doesn't know. What is even funnier:
People readily believe it.
The defer script
http://www.w3.org/TR/REC-html40/interact/scripts.html#h-18.2.1
| defer [CI]
| When set, this boolean attribute provides a hint to the user
| agent that the script is not going to generate any document content
| (e.g., no "document.write" in javascript) and thus, the user agent
| can continue parsing and rendering.
What John taught Google about defer is quite different. I heard:-
| It allows to say, you know, that given this script, to load it
| asynchronously and then execute it again at a later time -- it doesn't
| matter when this script executes.
|
| Um, but additionally, there's some properties of a deferred script
| like it can still document write and when it document write's, it
| still does it in the correct location. Ah, things like that.
To say 'it doesn't matter when this script executes' is false. The order
scripts are executed matters very much. Deferred scripts have an
execution order. That order is not stated by the specification, but IE
does execute the scripts in a certain order.
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?
The HTML 4.01 specification states that a deferred script cannot use
javascript to document.write.
Example:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html lang="en">
<head>
<title>Untitled</title>
</head>
<body>
<h1>old document</h1>
<script type="text/javascript" defer>
document.write('new document');
document.close();
</script>
</body>
</html>
This results in the current document being replaced with "new document"
in Firefox 3.1.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1b3pre)
Gecko/20090121 Shiretoko/3.1b3pre
I am surprised at what I heard in that video.
Garrett
--
comp.lang.javascript FAQ <URL: http://jibbering.com/faq/ >
David Mark
> I stumbled on John Resig video recently.
>
> http://www.youtube.com/watch?v=13-3VMzfU3Y
>
> Some other comments mentioned that John was wrong about border-radius in
> Opera (I didn't watch that far).
The man is a menace.
>
> The first commenter stated:
> "I'm really starting to think their are clones of you. There is just no
> way you can be doing THIS much stuff and be one person!"
It is all too easy to do lots of stuff if you half-ass everything.
>
> John seems to make stuff up when he doesn't know. What is even funnier:
> People readily believe it.
Yes, he reminds me of one of those "no money down" real estate guys
that come on at 4 in the morning.
>
> The defer script
>
> http://www.w3.org/TR/REC-html40/interact/scripts.html#h-18.2.1
> | defer [CI]
> | When set, this boolean attribute provides a hint to the user
> | agent that the script is not going to generate any document content
> | (e.g., no "document.write" in javascript) and thus, the user agent
> | can continue parsing and rendering.
>
> What John taught Google about defer is quite different. I heard:-
>
> | It allows to say, you know, that given this script, to load it
> | asynchronously and then execute it again at a later time -- it doesn't
> | matter when this script executes.
> |
> | Um, but additionally, there's some properties of a deferred script
> | like it can still document write and when it document write's, it
> | still does it in the correct location. Ah, things like that.
He's nuts with that defer stuff. It's widely known to be useless. I
find it beyond belief that his document ready function hinges on it.
Then, so does YUI's.
Of course, he doesn't seem to care about catastrophic failures,
despite the fact that most jQuery apps and add-ons assume that jQuery
will work. For instance, turn off ActiveX in IE and see how how far
these sites get.
>
> To say 'it doesn't matter when this script executes' is false. The order
> scripts are executed matters very much. Deferred scripts have an
> execution order. That order is not stated by the specification, but IE
> does execute the scripts in a certain order.
>
> 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?
God only knows. He often glosses over trivia like that.
>
> The HTML 4.01 specification states that a deferred script cannot use
> javascript to document.write.
Of course it can't.
>
> Example:
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
> "http://www.w3.org/TR/html4/loose.dtd">
> <html lang="en">
> <head>
> <title>Untitled</title>
> </head>
> <body>
> <h1>old document</h1>
> <script type="text/javascript" defer>
> document.write('new document');
> document.close();
> </script>
> </body>
> </html>
>
> This results in the current document being replaced with "new document"
> in Firefox 3.1.
> Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1b3pre)
> Gecko/20090121 Shiretoko/3.1b3pre
That's what I would expect.
>
> I am surprised at what I heard in that video.
Nothing he says or does surprises me at this point. Read the jQuery
dev threads that Matt cited in the previous jQuery thread. They are a
fascinating glimpse into the mind of the Javascript ninja (and some of
the plug-in developers.) They are obviously, maddeningly ten years
behind. One of the examples posted used browser sniffing to detect
opacity support (and I don't recall anyone pointing out how ridiculous
it was.) It wouldn't bother me if this stuff weren't pushed like
crack. It is an epidemic of ignorance.
[snip]
Richard Cornford
>I stumbled on John Resig video recently.
>
> http://www.youtube.com/watch?v=13-3VMzfU3Y
Hay you got a source for the video in a proper video format (i.e. not
swf)?
> Some other comments mentioned that John was wrong about
> border-radius in Opera (I didn't watch that far).
>
> The first commenter stated:
> "I'm really starting to think their are clones of you. There is
> just no way you can be doing THIS much stuff and be one person!"
>
> John seems to make stuff up when he doesn't know.
That assumes that he appreciates that, and when, he doesn't know. It is
entirely possible that he believes every statement he makes to be
factual and accurate (recall VK; someone who could spend a month
studying a subject and (by drawing, and then believing, his own false
conclusions) end up knowing less than when he started).
> What is even funnier: People readily believe it.
There will always be credulous people in the world. The pity of it is
that if enough people say "John Resig is awesome", ofrent enough, there
will be people who will beleave everything he say without regard fo
anything else (including demonstrable facts). I suppose that is what
'awe' does for you.
> The defer script
>
> http://www.w3.org/TR/REC-html40/interact/scripts.html#h-18.2.1
> | defer [CI]
> | When set, this boolean attribute provides a hint to the user
> | agent that the script is not going to generate any document content
> | (e.g., no "document.write" in javascript) and thus, the user agent
> | can continue parsing and rendering.
>
> What John taught Google about defer is quite different. I heard:-
>
> | It allows to say, you know, that given this script, to load it
> | asynchronously and then execute it again at a later time -- it
> | doesn't matter when this script executes.
> |
> | Um, but additionally, there's some properties of a deferred
> | script like it can still document write and when it document
> | write's, it still does it in the correct location. Ah, things
> | like that.
>
> 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 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.
> 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.
> 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
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.
> 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
- no statements from that source will surprise me. (His new book has
some equally bizarre aggregations of words.)
Richard.
Richard Cornford
>>I stumbled on John Resig video recently.
>>
>> http://www.youtube.com/watch?v=13-3VMzfU3Y
>
That should have been "Have you got ... "
Richard.
Thomas 'PointedEars' Lahn
> Garrett Smith wrote:
>> I stumbled on John Resig video recently.
>>
>> http://www.youtube.com/watch?v=13-3VMzfU3Y
>
> Hay you got a source for the video in a proper video format (i.e. not
> swf)?
A friend recently recommended <http://www.arrakis.es/~rggi3/youtube-dl/> to
me (he did not write it). I have not had the time to test it yet, so thanks
for any feedback you can provide.
PointedEars
Eric Bednarz
> Richard Cornford wrote:
>> Garrett Smith wrote:
>>> I stumbled on John Resig video recently.
>>>
>>> http://www.youtube.com/watch?v=13-3VMzfU3Y
>>
>> Hay you got a source for the video in a proper video format (i.e. not
>> swf)?
>
> A friend recently recommended
> <http://www.arrakis.es/~rggi3/youtube-dl/>
I haven’t used it, but the page says that the program saves the flv, so
that doesn’t seem to help much.
You can actually get mp4 files from
http://www.youtube.com/get_video?fmt=18
by adding the ‘video_id’ and ‘t’ parameters from the flashvars to the
query string (I think there are more formats, but this is proper enough
for me). I have no idea what the legal situation of that is, though.
Garrett Smith
> 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. Modern browsers perform parallel downloads. The
resources are downloaded asynchronously, interpreted in sequential order.
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.
>> 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.
>> 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.
The download of the resource is not coupled to its execution.
The defer does attribute not indicate execution order. Non-deferred
scripts are executed in order; deferred scripts are executed when the
DOM is ready. There is not a standard that defines the order for
deferred scripts. What IE does with inline scripts is weird/complicated.
>> 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.
> 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. I
pointed out that calling document.write "onready" does not work:-
http://ejohn.org/blog/degrading-script-tags/#comment-319983
>> 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. He is still saying stuff that appears to be totally made up.
> - 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?
> Richard.
Garrett
[1]http://www.whatwg.org/specs/web-apps/current-work/#attr-script-async
Richard Cornford
> 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.
Richard Cornford
<snip>
> ... (because variable
> instantiation may be inflamed by ...
<snip>
That should have been "influenced by".
Richard.
Peter Michaux
wrote:
> 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,
It isn't?
From http://www.w3.org/TR/REC-html40/interact/scripts.html
"""
defer [CI]
When set, this boolean attribute provides a hint to the user agent
that the script is not going to generate any document content (e.g.,
no "document.write" in javascript) and thus, the user agent can
continue parsing and rendering.
"""
"""
All SCRIPT elements are evaluated in order as the document is loaded.
"""
I think it is reasonable from the word "hint" that "defer" was
intended only as an optimization hint and not otherwise change the
behavior of the web page. Scripts still need to execute in order as
one non-deferred script may depend on a previous deferred script. It
isn't clear enough and it seems it is not the behavior desired in HTML
5.
From http://dev.w3.org/html5/spec/Overview.html
"""
If the document is still being parsed, and the element has a defer
attribute, and the element does not have an async attribute
The element must be added to the end of the list of scripts that
will execute when the document has finished parsing.
This isn't compatible with IE for inline deferred scripts, but
then what IE does is pretty hard to pin down exactly. Do we want to
keep this like it is? Be more compatible?
"""
So they know they need to specify the order part better.
Peter
Richard Cornford
<snip>
"""
All SCRIPT elements are evaluated in order as the document is loaded.
"""
That statement is not achievable, if it is intended to refer to the
tokenising, parsing and execution of script code where it says
"evaluated", as any SCRIPT element with a TYPE attributed that specifies
an unsupported scripting language cannot be evaluated (in that sense) at
all.
Richard.
Garrett Smith
> Garrett Smith wrote:
>> Richard Cornford wrote:
>>> Garrett Smith wrote:
>>
>
>> 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
None of the above. They are interpreted in the order in which they
appear in the source code.
<script src="a.js"></script>
test
<script src="b.js"></script>
a.js must be executed first.
> 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?
>
What 'async' means is that b.js could run first. The order is unimportant.
>>>> 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.
>
[from executing that same script non-deferred].
<script src="p.js"></script>
<script src="q.js"></script>
Adding "defer" to p.js would likely have a different result.
>>>> 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.
>
I think "only" is too strong a word here. Where compatibility is
desired, other browsers might copy that implemented behavior. The use of
of that thing's unspecified features can influence other
implementations to follow suit.
https://bugzilla.mozilla.org/show_bug.cgi?id=28293#c19
The spec is silent about the order. IE does have an order. Order matters.
https://bugzilla.mozilla.org/show_bug.cgi?id=28293
Comments 19, 31, 35 are interesting. Comments 63 and 64 took the author
1 year to change his mind.
Firefox 3.1pre (current) has a working implementation of defer.
>> 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.
>
For implementations that support defer, those scripts run only after the
document is parsed and rendered. When the "DOMContentLoaded" event
(Gecko, Opera), and document.readyState (Webkit) fires is not guaranteed.
>> 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.
>
Other browsers' documentation should also be considered. If there is a
webkit bug and a Mozilla bug and they agree on copying IE, and the
respective implementations do copy IE, and Opera copies IE, would that
not be enough?
Defer is is not implemented in many recent, modern browsers. Adding
defer attribute to a script will likely result in the program behaving
differently.
>> 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.
>
Apparently, inline deferred scripts execute before the external deferred
scripts, regardless of source order.
http://www.websiteoptimization.com/speed/tweak/defer/
>> 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?
>
I did say so below.
[...]
Here:
>>
>> 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.
>
To make such statements, one would have to be completely oblivious to
what the defer attribute does or can do.
>>
>> 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?
>
I suppose it is possible that he does not know that he does not know
what defer is.
"Can be refuted" and "are refuted" are different things. When said facts
are refuted, those refutations can be interpreted as hostile, even if
they are carefully worded to not appear so.
When the misconception receives a majority of replies such as "awesome
post", it is not hard for the casual reader dismiss the one long-winded
argument.
Garrett
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn <Point...@web.de> writes:
>> Richard Cornford wrote:
>>> Garrett Smith wrote:
>>>> I stumbled on John Resig video recently.
>>>>
>>>> http://www.youtube.com/watch?v=13-3VMzfU3Y
>>> Hay you got a source for the video in a proper video format (i.e. not
>>> swf)?
>> A friend recently recommended
>> <http://www.arrakis.es/~rggi3/youtube-dl/>
>
> I haven’t used it, but the page says that the program saves the flv, so
> that doesn’t seem to help much.
FLV (Flash Video) is a proprietary, yet well-supported video format:
<http://en.wikipedia.org/wiki/Flash_Video#Free_software>. I presume
my friend uses mplayer on Debian GNU/Linux to play it.
PointedEars
Eric Bednarz
> Eric Bednarz wrote:
>>> Richard Cornford wrote:
>>>> Hay you got a source for the video in a proper video format (i.e. not
>>>> swf)?
>> I haven’t used it, but the page says that the program saves the flv, so
>> that doesn’t seem to help much.
>
> FLV (Flash Video) is a proprietary, yet well-supported video format:
Richard asked for a “proper video format”, so I assumed he didn’t want
FLV; but he actually wrote “not swf”, so maybe I got his intentions
wrong.
Of course SWF is not a video format at all, but neither is FLV (or MP4,
for that matter).
beegee
wrote:
I tried it on a Macbook Pro OS X 10.5. Generally, it works fine. The
Resig video is big so I gave up after a while. Smaller videos
downloaded and played back great. The real problem is finding
anything on YouTube worth downloading. Thanks for the link.
Bob
Richard Cornford
> Richard Cornford wrote:
>> Garrett Smith wrote:
>>> Richard Cornford wrote:
>>>> Garrett Smith wrote:
>>> 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
>
> None of the above. They are interpreted in the order in which they
> appear in the source code.
>
> <script src="a.js"></script>
> test
> <script src="b.js"></script>
>
> a.js must be executed first.
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.
<snip>
>>> 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?
>
> What 'async' means is that b.js could run first.
That would be a reasonable interpretation of asynchronous.
> The order is unimportant.
The order is uncertain. But what has that to with fulfilling the
"doesn't matter when it executes" statement?
<snip>
>>> 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.
>>
>
> I think "only" is too strong a word here. Where compatibility is
> desired, other browsers might copy that implemented behavior.
Yes they might, but expecting them to without any better reason would be
reckless.
> The use of of that thing's unspecified features can influence other
> implementations to follow suit.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=28293#c19
>
> The spec is silent about the order. IE does have an order.
> Order matters.
Order only matters if the scripts being loaded have not been designed
such that order doesn't matter. As the order of execution is not
specified in relation to the DEFER attribute using it on scripts for
which the order of execution did matter would be a mistake.
<snip>
> For implementations that support defer, those scripts run only
> after the document is parsed and rendered. When the
> "DOMContentLoaded" event (Gecko, Opera), and document.readyState
> (Webkit) fires is not guaranteed.
That is just an observation about specific implementations.
>>> 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.
>
> Other browsers' documentation should also be considered. If
> there is a webkit bug and a Mozilla bug and they agree on
> copying IE, and the respective implementations do copy IE,
> and Opera copies IE, would that not be enough?
For an intranet application with known and fixed expectations of
browsers that are to be used with the application. For general
cross-browser code that assumption is little better than "this site is
best viewed with IE" or the "both browsers" attitudes of the turn of the
century.
> Defer is is not implemented in many recent, modern browsers.
> Adding defer attribute to a script will likely result in the
> program behaving differently.
Differently from what? If a DEFER attribute is only ever added to a
SCRIPT element for which the time of execution of the corresponding
script does not matter at all then the overall outcome should not be
different at all.
>>> 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.
>
> Apparently, inline deferred scripts execute before the external
> deferred scripts, regardless of source order.
Differently from what? If a DEFER attribute is only ever added to a
SCRIPT element for which the time of execution of the corresponding
script does not matter at all then the overall outcome should not be
different at all.
<snip>
>>> 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.
>
> To make such statements, one would have to be completely oblivious
> to what the defer attribute does or can do.
To make such a statement while maintaining your interpretation of
"correct location". With an alternative meaning the statement containing
"correct location" could become less technically objectionable.
<snip>
>>> 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?
>
> I suppose it is possible that he does not know that he does not
> know what defer is.
Entirely possible.
> "Can be refuted" and "are refuted" are different things.
But possibly only in short term.
> When said facts are refuted, those refutations can be interpreted
> as hostile,
Can be? They very often are.
> even if they are carefully worded to not appear so.
>
> When the misconception receives a majority of replies such as
> "awesome post", it is not hard for the casual reader dismiss the
> one long-winded argument.
A rational person dismissing reasoned argument knows they are making a
mistake. But demonstrations are harder to dismiss than arguments, and
where the technical aspects of javascript and/or browser scripting is
concerned the truth can always be demonstrated.
Richard.
Richard Cornford
> Thomas 'PointedEars' Lahn writes:
<snip>
>> FLV (Flash Video) is a proprietary, yet well-supported
>> video format:
>
> Richard asked for a “proper video format”, so I assumed he
> didn’t want FLV;
I didn't. MP4 did very well, thanks. Though I still haven't had time to
watch the video.
> but he actually wrote “not swf”, so maybe I got his intentions
> wrong.
<snip>
Or I wasn't being very precise.
Richard.
Garrett Smith
In a general sense, one implication of the word 'asynchronous' would be
'a could run first'. I'm talking about the async attribute, specifically
here.
>> The order is unimportant.
>
> The order is uncertain. But what has that to with fulfilling the
> "doesn't matter when it executes" statement?
>
If the program does not rely on order of scripts, it can load and
execute them asynchronously.
It would be somewhat desirable to have better control over script
loading. In order to process a resource, it must first be loaded.
The scripts are normally declared in the HTML, the browser loads them
when it thinks it should (depends on browser) and, if the resource is
not deferred, executes it in order (of appearance in the document).
If the resource is deferred, then it would execute after the page has
been rendered. (though nonstandard, this is the way IE has handled defer
for many years)[1].
If the async attribute is present, then the script will execute as soon
as it is available. (Running an async script before that part of the
document has rendered would seem to be highly undesirable, but that is
what Ian has decided to require).
> <snip>
>>>> 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.
>>>
>>
>> I think "only" is too strong a word here. Where compatibility is
>> desired, other browsers might copy that implemented behavior.
>
> Yes they might, but expecting them to without any better reason would be
> reckless.
>
A better reason such as broad use? How about what MSDN says and what IE
has done for years? Not enough?
I suspect defer would be more commonly used on closed IE-only
applications than on public sites.
> <snip>
>> For implementations that support defer, those scripts run only
>> after the document is parsed and rendered. When the
>> "DOMContentLoaded" event (Gecko, Opera), and document.readyState
>> (Webkit) fires is not guaranteed.
>
> That is just an observation about specific implementations.
>
The statement 'those scripts run only after the document is parsed and
rendered' is based on what IE does explicitly, by design. For an
implementation to design a new implementation of DEFER that it is
executed before the document is rendered would not give anyone and
advantage; it would be pointless.
>>>> 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.
>>
>> Other browsers' documentation should also be considered. If
>> there is a webkit bug and a Mozilla bug and they agree on
>> copying IE, and the respective implementations do copy IE,
>> and Opera copies IE, would that not be enough?
>
> For an intranet application with known and fixed expectations of
> browsers that are to be used with the application. For general
> cross-browser code that assumption is little better than "this site is
> best viewed with IE" or the "both browsers" attitudes of the turn of the
> century.
>
>> Defer is is not implemented in many recent, modern browsers.
>> Adding defer attribute to a script will likely result in the
>> program behaving differently.
>
> Differently from what? If a DEFER attribute is only ever added to a
> SCRIPT element for which the time of execution of the corresponding
> script does not matter at all then the overall outcome should not be
> different at all.
>
Reworded:
If a DEFER attribute is only ever added to a SCRIPT element for which
the *order* of execution of the corresponding script does not matter at
all then the overall outcome should not be different at all.
Observable differences become noticeable with network latency for that
script or for a stylesheet in that page.
For example:-
<script defer src="a" type="text/javascript"></script>
<link type="text/css" rel="stylesheet" href="b">
If defer is not implemented, the script runs before b loads. Otherwise,
the opposite may be true (Firefox 3.1 DEFER'd script waits for link to
finish[2]). This affects page rendering and what is displayed and
how/where.
In firefox <= 3.x, a script that follows a stylesheet will not load
until the stylesheet loads.
If the script is DEFER'd, the actions the browser takes in loading and
rendering the page will differ between non-DEFER'd and DEFER'd in
implementations.
There is no way to declare dependency of a script. The order that
resources are loaded varies in implementations.
>>>> 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.
>>
>> Apparently, inline deferred scripts execute before the external
>> deferred scripts, regardless of source order.
>
> Differently from what? If a DEFER attribute is only ever added to a
> SCRIPT element for which the time of execution of the corresponding
> script does not matter at all then the overall outcome should not be
> different at all.
>
Did you want to say something else?
> <snip>
>>>> 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.
>>
>> To make such statements, one would have to be completely oblivious
>> to what the defer attribute does or can do.
>
> To make such a statement while maintaining your interpretation of
> "correct location". With an alternative meaning the statement containing
> "correct location" could become less technically objectionable.
>
I cannot think of a plausible alternative meaning.
> <snip>
>>>> 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?
>>
>> I suppose it is possible that he does not know that he does not
>> know what defer is.
>
> Entirely possible.
>
It might also be possible to decide to make a presentation on browser
performance, develop an outline, and then fill in the discussion with
"stuff like that."
>> "Can be refuted" and "are refuted" are different things.
>
> But possibly only in short term.
>
>> When said facts are refuted, those refutations can be interpreted
>> as hostile,
>
> Can be? They very often are.
>
>> even if they are carefully worded to not appear so.
>>
>> When the misconception receives a majority of replies such as
>> "awesome post", it is not hard for the casual reader dismiss the
>> one long-winded argument.
>
> A rational person dismissing reasoned argument knows they are making a
> mistake. But demonstrations are harder to dismiss than arguments, and
> where the technical aspects of javascript and/or browser scripting is
> concerned the truth can always be demonstrated.
>
While your optimism is admirable, not one person is 100% rational.
It can be easier to dismiss a long-winded post than to copy-paste the
example into an editor, run it, check the results. Not everyone has the
time to do that; those who do might not have the technical ability to
make judgments.
> Richard.
Garrett
[1]http://msdn.microsoft.com/en-us/library/ms533719(VS.85).aspx
[2]http://dhtmlkitchen.com/jstest/block/link-defer-top.html