- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 03 Dec 2008 19:02:19 -0800
- To: Boris Zbarsky <bzbarsky@MIT.EDU>, Ian Hickson <ian@hixie.ch>, Henri Sivonen <hsivonen@iki.fi>, Jonas Sicking <jonas@sicking.cc>, HTML WG <public-html@w3.org>, www-svg@w3.org
Cameron McCormack wrote: > Boris Zbarsky: >> That said, discussion on www-svg (say in the thread starting at >> <http://lists.w3.org/Archives/Public/www-svg/2002Nov/0002.html>) 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'd strongly recommend removing onload entirely. Are there any implementations out there that implement it "correctly"? With "correctly" meaning exactly when all resources needed by the element is loaded. And does this include resources linked to from style attributes as well as style-rules added by stylesheets. And what happens if those stylesheets haven't been loaded yet. If it is in fact true that there are no conforming implementations, I'd say that is a good indication that the feature needs to be dropped. It further would be the only event that fires during actual parsing, which has all sorts of performance and security issues. / Jonas
Received on Thursday, 4 December 2008 03:08:01 UTC