You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If SVG's script element is indeed mostly identical to HTML's script element we should simply define it inline and allow them to be used interchangeably.
My proposal, if implementers are willing to take the back-compat risk, is that the element interface for ("http://www.w3.org/2000/svg", "script") becomes HTMLScriptElement. Optionally, we can add an alias window.SVGScriptElement = window.HTMLScriptElement like we've done for Document and HTMLDocument.
This has the following potentially-negative impacts:
It breaks the invariant that all HTMLElement instances have the HTML namespace as their namespace. (I can't think of anything relying on this, but maybe I am not thinking hard enough.)
It breaks the invariant that anything in the SVG namespace inherits from SVGElement. (Again, I can't see any bad consequences of this.)
Several properties get removed:
ownerSVGElement
viewportElement
href (a SVGAnimatedString)
The className property becomes a DOMString instead of a SVGAnimatedString.
Many new properties get added by inheriting from HTMLElement.
I'm not sure if this is acceptable to implementers or the SVGWG. But it seems plausible to me.
If we can't get away with this then I'm not sure we should define SVGScriptElement in HTML. It has enough SVG-specific foibles and dependencies that it doesn't seem to be in our wheelhouse. Instead we should just make sure HTMLScriptElement is well-factored enough that the SVG editors can reference it for any behavior they want to copy.
Yeah, I think it should probably keep the same interface. I guess we should then work on allowing concepts of the HTML script element to be reused in some easy manner and figure out what the implications of the SVG features are on the script processing model. E.g., what does it meant to animate the URL?
Activity
domenic commentedon Mar 18, 2016
My proposal, if implementers are willing to take the back-compat risk, is that the element interface for ("http://www.w3.org/2000/svg", "script") becomes
HTMLScriptElement. Optionally, we can add an aliaswindow.SVGScriptElement = window.HTMLScriptElementlike we've done forDocumentandHTMLDocument.This has the following potentially-negative impacts:
HTMLElementinstances have the HTML namespace as their namespace. (I can't think of anything relying on this, but maybe I am not thinking hard enough.)SVGElement. (Again, I can't see any bad consequences of this.)I'm not sure if this is acceptable to implementers or the SVGWG. But it seems plausible to me.
If we can't get away with this then I'm not sure we should define SVGScriptElement in HTML. It has enough SVG-specific foibles and dependencies that it doesn't seem to be in our wheelhouse. Instead we should just make sure HTMLScriptElement is well-factored enough that the SVG editors can reference it for any behavior they want to copy.
Ms2ger commentedon Mar 19, 2016
I can see plenty of security bugs coming from breaking the namespace-inheritance link, fwiw.
annevk commentedon Mar 21, 2016
Yeah, I think it should probably keep the same interface. I guess we should then work on allowing concepts of the HTML script element to be reused in some easy manner and figure out what the implications of the SVG features are on the script processing model. E.g., what does it meant to animate the URL?