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

Received on Monday, 4 June 2007 22:19:48 UTC