This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html Multipage: http://www.whatwg.org/C#htmlobjectelement Complete: http://www.whatwg.org/c#htmlobjectelement Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/ Comment: Please define getSVGDocument Posted from: 87.64.200.82 by ms2ger@gmail.com User agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0
Isn't that specced by the SVG spec?
Definitely not in the detail I'd like to see. ISTR that it was discussed before, and the SVG people were happy to have it specced in HTML; that'd also make it easier to make sure that all elements that need it get it.
If the SVG WG wants to transfer ownership of this API to HTML, I'm happy to spec it. Can I get confirmation from an SVG spec editor?
I don't mind too much where getSVGDocument lives, if we do indeed need to keep it. I'd love to see some usage data for it. As it will be pretty much an alias for contentDocument, it would be simpler if it was defined in HTML. Let me bring it up on the SVG group's list just to see if anyone has any objections moving it over.
http://lists.w3.org/Archives/Public/public-svg-wg/2014AprJun/0083.html
Checked in as WHATWG revision r8713. Check-in comment: getSVGDocument() http://html5.org/tools/web-apps-tracker?from=8712&to=8713
It's needed for at least object and iframe as well. Maybe frame also. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3103
Also, step 3 seems unnecessarily restrictive. At least Blink/Gecko/Presto returns the document after the element has been further navigated, even to a non-SVG document. (Haven't tested IE.) It seems like Safari 7.0.5 returns null if the document is not an SVGDocument, but it returns the document after navigation to another SVG. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3105 For iframe, Presto/Gecko just always returns the document, but WebKit/Blink return null for non-image/svg+xml it seems. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3108
The current step 3 was based on this: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3102 document xml svg svg-as-xml xml-as-svg Chrome null null object null object Firefox object object object object error* Safari null null object null object * it's trying to cast the XMLDocument to SVGDocument. In all cases, what matters is the currently loaded document, not what the <embed> originally pointed to. "Blink/Gecko/Presto returns the document after the element has been further navigated, even to a non-SVG document" appears to be false for Blink, at least in the case of navigating to a non-SVG document without an SVG MIME type.
You're right. I think I also misread the spec, I thought it would always return null after further navigation but it seems that is not the case. So I think it's OK, just need it on the other elements.
Checked in as WHATWG revision r8811. Check-in comment: Add getSVGDocument() to object and iframe also, with the same definition as for embed. https://html5.org/tools/web-apps-tracker?from=8810&to=8811
It needs to be nullable in the IDL.
Checked in as WHATWG revision r8814. Check-in comment: getSVGDocument() can return null (IDL fix). https://html5.org/tools/web-apps-tracker?from=8813&to=8814