Re: Black-box equivalence of parsing fragments directly into context node

Boris Zbarsky:
> That said, discussion on www-svg (say in the thread starting at  
> <>) makes  
> it clear that SVGLoad is not fully async, and that in particular it must  
> fire before painting (and presumably layout) happens in various cases. I 
> have no idea _why_ such a requirement is in place, but it's there.

Being a decision made before I was around, I’m not certain, but probably
the intention was to ensure that layout has been done so that calls to
SVG DOM methods that rely on object geometry would work (e.g.
getBBox()).  There used to be implementations that hadn’t done layout by
the time SVGLoad was fired, and authors had to use tricks like
onload="setTimeout(someStuffThatCallsGetBBox, 0)" to get around it.

> I suspect that to really proceed here the SVG working group would need
> to:
> 1)  Investigate when current UAs fire this event.
> 2)  If they do this interoperably at parse-close-tag time, decide
>     whether current content depends on this behavior.
> 3)  Specify more clearly when the event can be fired with respect to
>     the content model.  Such a definition would at the very least need
>     to define whether, given
>    <svg xmlns="">
>      <svg onload="alert(document.getElementsByTagName('svg').length)"/>
>      <svg/>
>    </svg>
>     the alert is allowed to show 3.

A similar problem existed with implementations handling <svg:script>.
Desktop browsers processed them as with HTML (executing them when the
</svg:script> tag was parsed, and blocking further parsing of the
document), while Batik loaded the whole SVG document and then executed
each of the <svg:script> elements.  I think we ended up requiring the
HTML-like way in SVG Tiny 1.2, although it may be problematic for
implementations (like Batik) that can accept an already constructed
Document object for display (as its JSVGCanvas component can).

Cameron McCormack ≝

Received on Thursday, 4 December 2008 01:28:04 UTC