Re: [whatwg] setting .src of a SCRIPT element
On Mon, 21 May 2007, Hallvord R M Steen wrote: if you set the src property of a SCRIPT element in the DOM, IE will load the new script and run it. Firefox doesn't seem to do anything (perhaps a more seasoned bugzilla searcher can tell me if it is considered a known bug?). I think Opera 8 does what IE does, Opera 9 is buggy. I think IE's behaviour is pretty useful and I'd like the spec to make this standards-compliant. It is a common technique to create SCRIPT elements dynamically to load data (particularly because this gets around cross-domain limitations). Firefox's implementation means one has to create a new SCRIPT element each time, keep track of them, and remove them from the document again, whereas with IE's implementation you can have one data loader SCRIPT element and set its .src repeatedly. On Mon, 21 May 2007, Darin Adler wrote: Is this technique easy to use correctly? What if you set the src before a previous script has finished loading? I've heard from several implementors that this would be undesirable. The spec goes to some lengths to stop it from working, in fact. With the definition of XMLHttpRequest, the coming cross-domain nature of that element, the ability to use cross-frame communication, and the simple workaround of creating a new script for each communication, it seems there are enough ways to get around the problem that we don't have to allow it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] setting .src of a SCRIPT element
On Wed, 30 May 2007, Jonas Sicking wrote:
The reason I designed it this way was that it felt like the least
illogical behavior. In general a document behaves according to its
current DOM. I.e. it doesn't matter what the DOM looked like before, or
how it got to be in the current state, it only matters what's in the DOM
now. [...]
For script things are a lot worse. If the contents of a script
element is changed it is impossible to 'drop' the script that was there
before. Once the contents of a script has executed, it can never be
unexecuted. And since we can't undo what the script has already done,
it feels weird to redo the new thing that you're asking it to do.
Another thing that would be weird would be inline scripts. How would the
following behave:
s = document.createElement('script');
document.head.appendChild(s);
for (i = 0; i 10; i++) {
s.textContent += a + i + += 5;;
}
Would you reexecute the entire script every time data was appended to
the script? Would you try to just execute the new parts? Would you do
nothing? IE gets around this problem by not supporting dynamically
created inline scripts at all, which I think is a really bad solution.
So I opted for 'killing' script elements once they have executed, they
become in effect dead elements. This felt simple and consistent.
I'm not sure what you mean when you say you need to keep track of them,
and remove them from the document again. All you need to do every time
you want to execute a script is to insert a new DOM element in the head
of your page. It's not going to be a problem with having too many
script elements in the document unless you start executing millions of
scripts, at which point you'll have bigger performance issues.
On Thu, 31 May 2007, Jonas Sicking wrote:
I don't see that being able to reuse elements adds any value. Could
you give an example where it does?
The global eval equivalent is an example. It's not much of an
improvement over the cloneNode example but I'd like the performance to
be as close to a plain eval as possible. Ability to switch type,
charset, language attributes in chosen user agents may be useful for
things like testing E4X support or ES4 support, or correct broken
encodings. Ability to execute an external resource again may be
useful. All of these are already possible however, so I don't think
they are strong use cases.
If there aren't any strong use cases I think we should go with what's
simple.
I agree with Jonas here (and I apologise for not seeming to have the other
side of this conversation; I assume I put it into another folder and will
get to it in due course).
I haven't changed the spec, since the spec describes what Jonas says.
Please let me know if you disagree with this, especially if you find pages
that break because of it.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] setting .src of a SCRIPT element
On 31/05/07, Jonas Sicking [EMAIL PROTECTED] wrote: I agree this is a problem. I see several non-solutions that simply would close the issue without dealing with valid concerns. The only solution I see that actually handles most concerns is to not execute inline scripts at all without some API call on the script element to tell that it's been set up fully. What if you were building a script body in many text nodes and CDATA nodes and entity reference nodes where you only have a final, executable form once you have set it all up? It makes sense to me to have an API function for triggering evaluation of the script inline contents. What we do is that we don't execute the script until it is inserted into the DOM. This is consistent with how most elements work, i.e. they don't affect the document until they are actually inserted into it. Neither would my suggested behaviour, but executing ONLY when inserting into the document hierarchy would be entirely acceptable in my view. It only makes for script.parentNode.replaceChild(script,script) instead of script.evaluate(true) as the way to evaluate the script after changing it. It relies on being able to execute more than one, but a script.cloneNode(true) should be able to deal with even that. This way you can build a script element containing whatever you want and then insert it into the document. You can even build a script element with both src set and has inline content so that you'll get the fallback behaviour exactly like parsed elements. Which you can in my suggestion too. Any of the actions that mark it as unexecuted will make inserting/reinserting it into the document hierarchy send it to the scripting engine. I have in no way specified any other handling when sending it to the scripting engine than the default with regards to where the code to parse comes from. So, what are these issues I talk about? Well, mostly it's questions about what is appropriate to do in cases like: 1. We have a script element, without inline content, in the document hierarchy. A src attribute is added. 2. We have a script element, with either a src attribute or inline content, in the document hierarchy. A type attribute is added, removed or modified. 3. We have a script element, with inline contents, in the document hierarchy. A src attribute is added. 4. We have a script element, with no inline content but with a src attribute, in the document hierarchy. Inline content is added. 5. We have a script element, with inline content and a src attribute, in the document hierarchy. The src attribute is removed. 6. We have a script element, in the document hierarchy. It is removed from and reinserted into the document hierarchy. 7. We have a script element, with inline content, in the document hierarchy. The inline content is changed. 8. We have a script element, without inline content, not in the document hierarchy. A src attribute is added. 9. We have a script element, with a src attribute, in the document hierarchy. The src attribute is changed. (An similar example cases, on and on...) What we've said is that once a script element can be executed it is, and then it never is again. A script element can be executed once it's in the document and it has either inline content or a src attribute set. As mentioned I don't like the idea of not being able to execute it again. But as long as the execution flag is not preserved through a cloneNode, and the node is guaranteed to be cloneable in all user agents, I don't mind, all the functionality of my suggestion would be replicatable then. I think it would be logical to handle DOM manipulation like so: - Any script element: If a src, type, defer, async, language, charset, for or event attribute is added, removed or changed, the script is flagged as unexecuted. - Any script element: If a src attribute is added or changed, load that resource. - A script element, without src attribute: If inline content is changed, removed or added, the script is flagged as unexecuted. I think it would be logical to handle execution of script like so: - A script element, with an unexecuted flag: If inserted into the document hierarchy, the script is sent to the scripting engine queue and flagged as executed. - A script element, with an unexecuted flag, in the document hierarchy: If an evaluation method on the script element is called or the loading of a resource completes, the script is sent to the scripting engine queue and flagged as executed. - A script element, with an executed flag: If an evaluation method on the script is called with a first argument of true, the script is sent to the scripting engine queue again. That would make doing myScript.src = myScript.src and myScript.textContent = myScript.textContent reevaluate the scripts. It would also make the for-loop in the example I gave above reevaluate the first script part over and over again. The myScript.src example, yes. The
Re: [whatwg] setting .src of a SCRIPT element
The script in question is already as bad as it can be: it needs time 10 *
(5 + content length) and 20 context switches to run. I would not mind
making it even worse by reexecuting the script each time. There is a chance
the script developer would learn how to write better code (that is, a DOM
property value should be built incrementally, if so desired, on the script
side) if he noticed that effect.
Cheers
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jonas Sicking
Sent: Thursday, May 31, 2007 3:27 AM
To: Hallvord R M Steen; whatwg
Subject: Re: [whatwg] setting .src of a SCRIPT element
Another thing that would be weird would be inline scripts. How would the
following behave:
s = document.createElement('script');
document.head.appendChild(s);
for (i = 0; i 10; i++) {
s.textContent += a + i + += 5;;
}
Would you reexecute the entire script every time data was appended to
the script? Would you try to just execute the new parts? Would you do
nothing? IE gets around this problem by not supporting dynamically
created inline scripts at all, which I think is a really bad solution.
Re: [whatwg] setting .src of a SCRIPT element
I don't see that being able to reuse elements adds any value. Could you give an example where it does? The global eval equivalent is an example. It's not much of an improvement over the cloneNode example but I'd like the performance to be as close to a plain eval as possible. Ability to switch type, charset, language attributes in chosen user agents may be useful for things like testing E4X support or ES4 support, or correct broken encodings. Ability to execute an external resource again may be useful. All of these are already possible however, so I don't think they are strong use cases. If there aren't any strong use cases I think we should go with what's simple. / Jonas
Re: [whatwg] setting .src of a SCRIPT element
Hallvord R M Steen wrote:
Hi,
if you set the src property of a SCRIPT element in the DOM, IE will
load the new script and run it. Firefox doesn't seem to do anything
(perhaps a more seasoned bugzilla searcher can tell me if it is
considered a known bug?).
It's by design (see below)
I think Opera 8 does what IE does, Opera 9 is buggy.
I think IE's behaviour is pretty useful and I'd like the spec to make
this standards-compliant. It is a common technique to create SCRIPT
elements dynamically to load data (particularly because this gets
around cross-domain limitations). Firefox's implementation means one
has to create a new SCRIPT element each time, keep track of them, and
remove them from the document again, whereas with IE's implementation
you can have one data loader SCRIPT element and set its .src
repeatedly.
The reason I designed it this way was that it felt like the least
illogical behavior. In general a document behaves according to its
current DOM. I.e. it doesn't matter what the DOM looked like before, or
how it got to be in the current state, it only matters what's in the DOM
now.
For style elements this work great. Whenever the contents of a style
is changed the UA can drop the current style rules associated with the
element, reparse or reload the new stylesheet, and apply the new style
rules to the document. (There was a bug in Firefox up to version 2,
where certain DOM mutations inside the style weren't detected, but
that has been fixed in Firefox 3).
For script things are a lot worse. If the contents of a script
element is changed it is impossible to 'drop' the script that was there
before. Once the contents of a script has executed, it can never be
unexecuted. And since we can't undo what the script has already done,
it feels weird to redo the new thing that you're asking it to do.
Another thing that would be weird would be inline scripts. How would the
following behave:
s = document.createElement('script');
document.head.appendChild(s);
for (i = 0; i 10; i++) {
s.textContent += a + i + += 5;;
}
Would you reexecute the entire script every time data was appended to
the script? Would you try to just execute the new parts? Would you do
nothing? IE gets around this problem by not supporting dynamically
created inline scripts at all, which I think is a really bad solution.
So I opted for 'killing' script elements once they have executed, they
become in effect dead elements. This felt simple and consistent.
I'm not sure what you mean when you say you need to keep track of them,
and remove them from the document again. All you need to do every time
you want to execute a script is to insert a new DOM element in the head
of your page. It's not going to be a problem with having too many
script elements in the document unless you start executing millions of
scripts, at which point you'll have bigger performance issues.
/ Jonas
Re: [whatwg] setting .src of a SCRIPT element
On May 21, 2007, at 10:26 AM, Hallvord R M Steen wrote: with IE's implementation you can have one data loader SCRIPT element and set its .src repeatedly. Is this technique easy to use correctly? What if you set the src before a previous script has finished loading? -- Darin
