- From: Denis Bohm <denis@fireflydesign.com>
- Date: Thu, 23 Oct 2003 09:47:35 -0700
- To: "Gavin Kistner" <gavin@refinery.com>
- Cc: <www-svg@w3.org>
From: "Gavin Kistner" <gavin@refinery.com> > On Thursday, October 23, 2003, at 09:50 AM, Denis Bohm wrote: > > I would like to create an element with a reference to an external > > resource after the document has been loaded from JavaScript (possibly > > on a user initiated event). [...] So I would like an event that is > > triggered when the external resource has been loaded [...] Will the > > wording cover this situation? > > It was your desire that sparked me looking at this. I hadn't realized > that you were dynamically creating the element, though IMO what you > desire should be made possible by the UA. Code like the following > should (IMHO) fire the Loaded() function only after that element has > been loaded from the url: > > function ThisIsCalledAfterTheDocumentIsLoaded(){ > var foo = svgDoc.createElement('use'); > foo.addEventListener('load',Loaded,false); > foo.setAttribute('externalResourcesRequired','true'); > foo.setAttributeNS('http://www.w3.org/1999/ > xlink','xlink:href','bar.svg#foo'); > svgDoc.documentElement.appendChild(foo); > } That's the flow that I had in mind and was testing (and onload wasn't called by ASV6). > However, I can see how this could get 'tricky' if the UA loaded the url > asynchronously, as soon as it was set. Should the below code fire the > load event, when the SVGLoad handler is attached to the object after it > has fully loaded? > > function ThisIsCalledAfterTheDocumentIsLoaded(){ > var foo = svgDoc.createElement('use'); > foo.setAttribute('id','foo'); > foo.setAttribute('externalResourcesRequired','true'); > foo.setAttributeNS('http://www.w3.org/1999/ > xlink','xlink:href','bar.svg#foo'); > svgDoc.documentElement.appendChild(foo); > } > > function ThisIsCalledFiveMinutesLater(){ > svgDoc.getElementById('foo').addEventListener('load',Loaded,false); > } > > (IMHO the answer is no, the SVGLoad event should not fire in the above > case.) Agreed. BTW: Seems like a function to query if a resource has been loaded could also be useful. > What about this code, if the referenced URL is already cached and > fetched before the SVGLoad handler is attached? > > function ThisIsCalledAfterTheDocumentIsLoaded(){ > var foo = svgDoc.createElement('use'); > svgDoc.documentElement.appendChild(foo); > foo.setAttributeNS('http://www.w3.org/1999/ > xlink','xlink:href','bar.svg#foo'); > foo.addEventListener('load',Loaded,false); > foo.setAttribute('externalResourcesRequired','true'); > } > > (IMHO the answer is "Dude, you're just asking for trouble.") Seems like since the JavaScript processing model seems to be "synchronous" that the above should work as in the first example above. It shouldn't matter where the JavaScript attaches the onload listener - as long as it does it before control is returned. But it wouldn't bother me if this wasn't the case - it does seem like "Dude, you're just asking for trouble." land. > Denis, in case the savvy ASV developers have implemented the xlink:href > fetching asynchronously, have you tried ensuring that your code is as > the first example, setting the SVGLoad handler before the xlink:href? Yes. > The sample wording I previously supplied may or may not be interpreted > to cover your desired case. Frankly, given the issues I've raised above > regarding asynchronous fetching, I think: > > * a decision needs to be made on how to handle asynchronous fetching of > external resources created dynamically via code: > -- externalResourcesRequired="true" -> synchronous ? > -- externalResourcesRequired="false" -> asynchronous ? > -- what if the externalResourcesRequired flag is set during an > asynchronous fetch? > > * a decision needs to be made on how to handle an SVGLoad event > dynamically attached to an object after it has finished loading: > -- should it fire immediately? > -- never? > -- only if any externalResources are changed and loaded? Can external resources be reloaded? Is there any control for that (via scripting)? > * the results of these decisions needs to be included explicitly in the > 1.2 specs. That would be great!
Received on Thursday, 23 October 2003 12:50:34 UTC