135698 2014-08-07 05:12:09 -0700 SVGElement has no innerHTML property 2014-12-15 10:01:25 -0800 1 1 1 Unclassified WebKit SVG 528+ (Nightly build) All All RESOLVED DUPLICATE 136903 P2 Normal --- 1 pere.jobs webkit-unassigned caitp damien.nozay galineau julien.sanchez krit zimmermann oldest_to_newest 1027467 0 pere.jobs 2014-08-07 05:12:09 -0700 In webkit, we can't access the innerHTML of an inline <SVG> element in an html document. Steps to reproduce: In the console, type 'innerHTML' in SVGSVGElement.prototype Results: On Firefox and Chrome: true On webkit: false 1027476 1 krit 2014-08-07 06:09:49 -0700 (In reply to comment #0) > In webkit, we can't access the innerHTML of an inline <SVG> element in an html document. > > Steps to reproduce: > In the console, type > > 'innerHTML' in SVGSVGElement.prototype > > Results: > On Firefox and Chrome: true Is that the case for any SVG element in an HTML document? Even for <rect>, <circle>? Or just outer <svg> element? > On webkit: false 1027477 2 pere.jobs 2014-08-07 06:15:28 -0700 This is the case for all SVG elements (they all inherit from SVGElement, which doesn't have innerHTML) > 'innerHTML' in SVGRectElement.prototype < false > 'innerHTML' in SVGElement.prototype < false 1027478 3 krit 2014-08-07 06:27:02 -0700 (In reply to comment #2) > This is the case for all SVG elements (they all inherit from SVGElement, which doesn't have innerHTML) I was asking for Blink and Firefox. Does it work for all elements there, or just on the root <svg> element in HTML? (Beside all HTMLElements of course.) > > > 'innerHTML' in SVGRectElement.prototype > < false > > > 'innerHTML' in SVGElement.prototype > < false 1027479 4 pere.jobs 2014-08-07 06:30:55 -0700 > I was asking for Blink and Firefox. Does it work for all elements there, or just on the root <svg> element in HTML? (Beside all HTMLElements of course.) Yes, it works on every svg element on chrome and firefox (because all SVG elements inherit from SVGElement). 1027480 5 krit 2014-08-07 06:33:30 -0700 (In reply to comment #4) > > I was asking for Blink and Firefox. Does it work for all elements there, or just on the root <svg> element in HTML? (Beside all HTMLElements of course.) > > Yes, it works on every svg element on chrome and firefox Ok. So they probably moved innerHTML on Element or added it to SVGElement. I assume innerHTML = "<rect>" still gives you an HTMLUnknownElement/HTMLElement on Blink and Firefox? > (because all SVG elements inherit from SVGElement). Hehe, SVG elements always inherit from SVGElement and always did. The problem is/was that innerHTML is just defined for HTMLElement. 1027481 6 pere.jobs 2014-08-07 06:45:00 -0700 > Ok. So they probably moved innerHTML on Element or added it to SVGElement. I assume innerHTML = "<rect>" still gives you an HTMLUnknownElement/HTMLElement on Blink and Firefox? Yes. In the Firefox console: > div = document.createElement("div"); > div.innerHTML = "<svg></svg>"; > div.firstChild.innerHTML = "<rect>" > div.firstChild.firstChild.__proto__ < HTMLUnknownElementPrototype (But IMO, it's a pitty. It makes it more complex to use templates to create SVG elements, for example). 1027482 7 pere.jobs 2014-08-07 06:48:15 -0700 And firefox folks intend to change that behavior: https://bugzilla.mozilla.org/show_bug.cgi?id=886390 1027483 8 pere.jobs 2014-08-07 06:50:19 -0700 And in chrome, it works: < div = document.createElement("div"); < div.innerHTML = "<svg></svg>"; < div.firstChild.innerHTML = "<rect>" < div.firstChild.firstChild.__proto__ > SVGRectElement 1033960 9 caitp 2014-09-08 14:42:46 -0700 The base interface for SVGElements does not have innerHTML exposed to scripts in its IDL --- in Blink and Gecko, innerHTML is exposed on the Element interface rather than HTMLElement interface, so they can share this common functionality. It's probably not a terribly difficult patch to write to fix this, if I have some spare cycles in 2 weeks I'll be happy to take a shot at it. 1033964 10 caitp 2014-09-08 14:53:28 -0700 (In reply to comment #9) > The base interface for SVGElements does not have innerHTML exposed to scripts in its IDL --- in Blink and Gecko, innerHTML is exposed on the Element interface rather than HTMLElement interface, so they can share this common functionality. > > It's probably not a terribly difficult patch to write to fix this, if I have some spare cycles in 2 weeks I'll be happy to take a shot at it. fwiw, the webkit treatment appears to be spec-correct, but I would treat it as a bug due to being incompatible with 2 major vendors. 1034254 11 julien.sanchez 2014-09-10 02:51:03 -0700 (In reply to comment #10) > fwiw, the webkit treatment appears to be spec-correct, but I would treat it as a bug due to being incompatible with 2 major vendors. It's no more correct. The spec has been fixed last year [1]. innerHTML is now defined on Element (implemented in Chrome [2] and Firefox) *and* should create elements with correct namespace (ok in chrome [2], not yet in Firefox [3]). [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17924 [2] https://code.google.com/p/chromium/issues/detail?id=311080 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=886390 1034280 12 julien.sanchez 2014-09-10 06:34:33 -0700 Testcase (http://marianoguerra.github.io/bugs/svgbug/) from the following issue on Github: https://github.com/facebook/react/issues/1900 . Webkit is also impacted as innerHTML is not defined on SVG elements. Only the second example ("innerHTML") is relevant here. It is certainly more complicated than just define innerHTML on Element because it should also create the <text> node as SVGTextElement and not as HTMLUnknownElementPrototype. 1034282 13 caitp 2014-09-10 06:40:35 -0700 (In reply to comment #11) > (In reply to comment #10) > > fwiw, the webkit treatment appears to be spec-correct, but I would treat it as a bug due to being incompatible with 2 major vendors. > > It's no more correct. The spec has been fixed last year [1]. innerHTML is now defined on Element (implemented in Chrome [2] and Firefox) *and* should create elements with correct namespace (ok in chrome [2], not yet in Firefox [3]). > > [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17924 > [2] https://code.google.com/p/chromium/issues/detail?id=311080 > [3] https://bugzilla.mozilla.org/show_bug.cgi?id=886390 Not according to any of the DOM specs which have made it to REC, or the WHATWG's DOM. However, this is academic, because if 2 major vendors are exposing this on Element, then it really doesn't matter what the spec says. (In reply to comment #12) > Testcase (http://marianoguerra.github.io/bugs/svgbug/) from the following issue on Github: https://github.com/facebook/react/issues/1900 . > Webkit is also impacted as innerHTML is not defined on SVG elements. > > Only the second example ("innerHTML") is relevant here. > It is certainly more complicated than just define innerHTML on Element because it should also create the <text> node as SVGTextElement and not as HTMLUnknownElementPrototype. Yes, it's obviously necessary to use the correct parsing insertion mode. By "not terribly difficult" I'm not saying it's a one-line patch, just that it's clear what is needed to be done. Would you care to write the patch? I will not have time for at least 2 weeks. 1034301 14 julien.sanchez 2014-09-10 08:14:35 -0700 > Not according to any of the DOM specs which have made it to REC, or the WHATWG's DOM. > > However, this is academic, because if 2 major vendors are exposing this on Element, then it really doesn't matter what the spec says. Right. I was referring to the DOM parsing living standard and latest candidate rec. > Yes, it's obviously necessary to use the correct parsing insertion mode. By "not terribly difficult" I'm not saying it's a one-line patch, just that it's clear what is needed to be done. > > Would you care to write the patch? I will not have time for at least 2 weeks. I would be really happy to do it. Unfortunately, I am afraid that it would be too difficult for me and presently I have neither enough time nor deep technical knowledge of Webkit to make it right and quick (within your two weeks for instance). However, I will try have a look at least out of curiosity. 1034304 15 caitp 2014-09-10 08:22:58 -0700 (In reply to comment #14) > > Not according to any of the DOM specs which have made it to REC, or the WHATWG's DOM. > > > > However, this is academic, because if 2 major vendors are exposing this on Element, then it really doesn't matter what the spec says. > > Right. I was referring to the DOM parsing living standard and latest candidate rec. > > > Yes, it's obviously necessary to use the correct parsing insertion mode. By "not terribly difficult" I'm not saying it's a one-line patch, just that it's clear what is needed to be done. > > > > Would you care to write the patch? I will not have time for at least 2 weeks. > > I would be really happy to do it. Unfortunately, I am afraid that it would be too difficult for me and presently I have neither enough time nor deep technical knowledge of Webkit to make it right and quick (within your two weeks for instance). However, I will try have a look at least out of curiosity. Cool, the Blink implementation should serve as somewhat of a guide --- it looks like much of editing/markup's API has not changed too much since the Blink fork, and the Blink innerHTML routine is just a call to createMarkup() with "this" (*this in the case of WebKit) and the element's childNodes --- It probably needs some adjustment to work correctly in WebKit, but following those lines is probably adequate, provided WebKit's createMarkup() is smart enough to figure out the correct insertion mode to use. 1034386 16 julien.sanchez 2014-09-10 13:28:56 -0700 (In reply to comment #15) > Cool, the Blink implementation should serve as somewhat of a guide --- it looks like much of editing/markup's API has not changed too much since the Blink fork, and the Blink innerHTML routine is just a call to createMarkup() with "this" (*this in the case of WebKit) and the element's childNodes --- It probably needs some adjustment to work correctly in WebKit, but following those lines is probably adequate, provided WebKit's createMarkup() is smart enough to figure out the correct insertion mode to use. Thanks a lot for the guidelines. I didn't even think to look at related Blink changes. Now that I did, it doesn't seem so hard to try and adapt them. 1048829 17 damien.nozay 2014-11-14 12:04:19 -0800 see also https://bugs.webkit.org/show_bug.cgi?id=136903 (bug 136903) there is some work in progress there. 1055652 18 galineau 2014-12-15 10:01:25 -0800 *** This bug has been marked as a duplicate of bug 136903 ***