[whatwg] setting .src of a SCRIPT element

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'