Hi Sebastian,

There is critical point, however: if/when Internet Explorer will fully support XHTML documents, if the load order bug will still be there even with the XHTML DOM, then we will probably be forced to modify the way applications are initialized (o we will need to switch to preprocessing the header file): and if this has to be done, the sooner is better.

It would be very interesting if someone who is already using IE7 could try my test page, particularly the DOM-pre and  DOM-post links, and see if the load order bug has been fixed. If it is, then we can definitely stick to document.write() for IE6 without further concerns.

Do you agree?

Mhh, just one question. Is it possible to use only one script element? e.g. switch the source after each load? That would be interesting to make it perform a little better.

Sorry no, it isn't! I've updated my test page with this technique (DOM-post-single-elem). In Firefox only the first script gets loaded and parsed. In Opera the first script gets loaded multiple times. In IE6 only the last script gets loaded. And even if it worked, I believe classes would again lose their relationship with the original source files, since the single script element would only point to the last source loaded.

In general I think it is completely OK to use document.write in Internet Explorer as long as the browser supports this. Maybe after some years it really supports XHTML. It is also OK to switch afterwards I think. So I would say:

1. document.createElement & appendChild => Gecko, Opera, Safari, etc.
2. document.write => IE

I have my problems to understand why document.write(manyscriptags) work, but document.getElementsById("head")[0].innerHTML += manyscripttags not. Are you sure you also has the problems regarding code evaluation in this case?

Yes, I am: here the three majors agree: FireFox, Opera and IE6 all ignore <script> tags added by innerHTML to head or body while loading the document; that is, they create the corresponding DOM nodes, but they seem not to parse the related _javascript_: you can try it yourself by clicking on the innerHTML link on my test page.

This puzzles me too. IMHO this behavior is due to the fact that document.write() always appends new code *after* the current parsing point (I guess it could push text into the buffer used while reading the document), so newly added script tags get handled only when control comes back from the _javascript_ interpreter to the HTML parser which can easily handle them by calling the _javascript_ interpreted again, as if they were in the original document source from the beginning. On the contrary, innerHTML acts on the DOM node, out of the parsing stream: new code assigned to innerHTML needs to be parsed and script tags have to be handed to the _javascript_ interpreter while it is still running the code which is acting on the innerHTML attribute, so the interpreter should be somewhat reentrant, and probably it isn't. It's just an hypothesis, though.

There are also plans to improve the demo section even more. Maybe we find another solution in some month, but for now this is completely OK.

Ok, thank you. In the next few days I will be cleaning up the code, and I hope to commit all changes by the end of the week.

Alessandro

begin:vcard
fn:Alessandro Sala
n:Sala;Alessandro
email;internet:alessandro {dot} sala {at} mclink {dot} net
version:2.1
end:vcard

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to