Re: [whatwg] setting .src of a SCRIPT element

liorean wrote:
>> 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.
> 
> 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.

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.

> 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.

> 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.

I don't think any solution here is going to be particularly logical, so 
I'd opt for what's simple.

>> So I opted for 'killing' script elements once they have executed, they
>> become in effect dead elements. This felt simple and consistent.
> 
> ECMAScript doesn't have a continuous effect, nor does it have
> incremental parsing/execution. All of the script is executed in one go
> unless it calls a halting function like alert, but then the script
> execution is just delayed and not cancelled. After executing the
> script is no longer in effect, though it might have had persistent
> side effects.
> 
> In the face of that it doesn't seem like killing the script element is
> much good the script itself dies of itself after execution. This
> behaviour of Gecko only prevents element reuse if you ask me, and
> that's not particularly desired.

I don't see that being able to reuse elements adds any value. Could you 
give an example where it does?

I do however think that allowing reuse causes a lot of weird edge cases 
that needs to be defined and that authors need to learn.

/ Jonas

Received on Thursday, 31 May 2007 05:58:18 UTC