-
-
Save pier-oliviert/ae0320dce453b414309e to your computer and use it in GitHub Desktop.
| var div = document.createElement('div') | |
| div.innerHTML = "<script></script>" | |
| var s = div.children[0] | |
| s.src = "//connect.facebook.net/en_US/all.js#xfbml=1" | |
| // true | |
| s instanceof HTMLScriptElement | |
| // Will NOT load the script | |
| document.head.appendChild(s) |
| var s = document.createElement('script') | |
| s.src = "//connect.facebook.net/en_US/all.js#xfbml=1" | |
| // true | |
| s instanceof HTMLScriptElement | |
| // Will load the script | |
| document.head.appendChild(s) |
I don't know if it's expected, but I kind of get why it wouldn't execute, only for a specific reason. I'm guessing that the browsers don't execute scripts that are sub-nodes because they could be nodes that are manipulated and not newly created (I don't know if I'm explaining this correctly). In other words, I don't exepect that a script element that is moved through the dom to execute every time I append it somewhere new. In that particular case, I guess that the browsers don't have a way of knowing it's a non-executed script yet when created with innerHTML (and that could be the underlying problem in a way... why wouldn't they be able to know that?).
Or it could be basically because the node has been "marked" as non-executable because it was created through a innerHTML. Maybe internally everything that is built with innerHTML is considered as plain dom, but that doesn't make sense... why discriminate the way the element was created by its method?
I don't think it's just a Webkit bug, if a bug it is, because I reproduced the same behavior over on Firefox.
It's not started since if it would be, the network panel would log the activity. My belief is that there's a misconception with what kind of parent are allowed for the script. https://developer.mozilla.org/en/docs/Web/HTML/Element/script
I believe that <div> should be but it's not entirely clear. Well that's what I'm going for anyway.
Just tested. It's not because it's a sub-node, really just because it's created with innerHTML. I guess you can file that as a bug somewhere, but maybe there's an underlying explanation. Curious to know.
@david-treblig you are right I don't think it's a webkit bug either (tested on FF & safari too and I actually made that distinction when I submitted the bug over to chromium.)
I also think that the node is internally marked differently. I really think this is unintended behavior, but as my bug report are usually dismissed, I wouldn't be surprised if they dismiss it.
Thanks for the follow up David, I'm going to add your findings to the bug report https://code.google.com/p/chromium/issues/detail?id=448783&colspec=ID%20Pri%20M%20Week%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified#makechanges
Dah, just found this http://www.w3.org/TR/2008/WD-html5-20080610/dom.html#innerhtml0
That's why.
http://www.w3.org/TR/html5/scripting-1.html#the-script-element I believe that since you've already created and appended the script element(via innerHTML), its "already started" flag has been set. Further modifying the src property and appending it doesn't cause it to execute again.