This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Reported at https://code.google.com/p/chromium/issues/detail?id=416036 As <script>, it should be disabled when injected by innerHTML. cf. http://www.w3.org/TR/2008/WD-html5-20080610/dom.html#innerhtml0
Why? The <script> thing was mostly done in order to get compatibility with existing content. Specifically there was a lot of content out there that did things like: <div id=elem> <script>...</script> lots of content here <div> document.getElementById('elem').innerHTML += "hello world"; This code did not expect the script elements to execute again because back in those days dynamically inserted <script> elements almost never executed. I don't think any of those reasons apply here. First of all "reimporting" the same URL is a no-op since we de-duplicate imports, right? Second, there's no existing content that we need to be compatible with since imports are a new feature. The reason I'd rather not make exceptions for innerHTML is that it creates arbitrary and hard-to-learn inconsistencies. Why innerHTML but not outerHTML or insertAdjecentHTML? What about the jQuery provided $("markup here") and parseHTML?
Good question. Your points are valid. I heard that the <script> blacklisting is a safeguard for reducing XSS. Is it misunderstanding the intention of the spec?
The current limitation was mainly added in order to be compatible with the web. It was originally not added for any security reasons. I don't think that blocking <script> in innerHTML is a meaningful XSS-prevention mechanism. But others might disagree.
Moved to https://github.com/w3c/webcomponents/issues/193