As I've written in the summary, getSVGDocument method of the Object element doesn't work. Please check the test page in the URL. User Agent: AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.249.30 Safari/532.5
Created attachment 117763 [details] Example of issue
Created attachment 117764 [details] SVG for attachment 117763 [details]
Problem still exists in Google Chrome 16.0.912.59 beta, Linux x64.
There is no such method in HTML5. Why is it important to support?
I don't care if you don't want to support it, but it's already implemented: var svg = document.getElementById('myembed'); window.alert(typeof svg.getSVGDocument); This will alert 'function' (http://jsfiddle.net/HkVY8/). So either don't support it, or make it work.
You are right, it is supported in WebKit. In your test case, undefined is returned simply because there is no document in <embed> yet at the time when load event is dispatched. It will be there after a timeout. Why do you think that this a is a bug?
I'm already in window.onload in the testcase, why is there no document loaded yet? If you attach to the load event on the embed (or object) element itself, you get the same result. Is it really necessary to resort to setTimeout hacks? Why are these events firing if the content isn't yet loaded? If you try the testcase in Firefox or Opera there will be a document loaded when getSVGDocument is called.
Per HTML5, load event should be delayed until the resource specified by embed's src attribute is fetched. Nothing says that it should be delayed until it's parsed into a document. So, WebKit result on this test doesn't appear non-compliant. That said, a look at Web Inspector timeline reveals that WebKit doesn't delay load event until after fetching the resource specified by the src attribute, which is wrong per HTML5.
I've been able to confirm today that the test case also works in IE9. Chrome is the only browser I have available that it doesn't work in. If the load event doesn't require that the document be parsed when it's getting fired on a document object then it makes the load event kind of useless in that scenario. Should I file a bug on the spec, or do you think this issue would be resolved if the load event was being delayed correctly?
This might be worth discussing with the standards community. Let me add some more background. Object and embed element behavior is primarily tailored for plug-ins, and you don't get much insight into what happens inside a plug-in after fetching its top resource from the network. For many plug-ins, that top resource could be just a small handle to the real data. Plug-ins that do media playback are different yet, the load event definitely shouldn't be delayed until after the media file loads. Such plug-ins often don't even attempt to hold the whole media file locally. It's the same as <video> and <audio> elements in HTML5, which also don't delay the load event. So, it seems that HTML5 is not quite right when it requires that loading plug-in resource must delay the load event. That cannot and shouldn't be done for media at least. Providing different behavior for plug-ins and for types handled internally by the engine seems inconsistent, but could be considered. Practically, I would suggest putting the SVG document in an iframe, not in an embed.
> This might be worth discussing with the standards community. I'll file a bug and see what happens. At the very least, if Firefox, Opera, IE and Chrome are all following the same spec then they should all behave the same way. So if Chrome is arguably doing the right thing then the spec needs to be made more clear. > Practically, I would suggest putting the SVG document in an iframe, not > in an embed. Doesn't really help if the primary reason for using object/embed was to provide fallback content or plugins for older browsers?
+cdumez for thoughts on spec conformance.
We did change the loading behavior in SVG a couple of years ago. At the moment the test case on jsfiddle does work as expected and the same across browsers. Closing.