Re: XBL in document fragments

Boris Zbarsky wrote:
> In that case the UA will seem hung to the user until the load completes 
> (possibly quite a long time).  That's not really desirable.
> 
>> If the binding document is already loaded then this should be an issue
> 
> 
> You mean "should not be"?  What if it's not already loaded?

Then I guess blocking is the only option.

> As it is, however, it is possible for script to execute before the CSS 
> files are loaded even in browsers where loading of CSS blocks the 
> parser.  Such scripts can ask for style information about the page, and 
> they'll see a state with the CSS not loaded.  It sounds like you're 
> trying to prevent this situation arising with XBL, and it's not clear to 
> me how you prpose to do that.

I know it is not easy to implement this but think of it from a 
developer/api perspective where XBL is used to create (user interface) 
components. Do we want the state to be indeterminable and dependent on 
timing issues? Just think of a very simple scenario.

var comp = document.createElementNS(myns, "comp");
comp.method();

vs.

var comp = document.createElementNS(myns, "comp");
comp.addEventListenerNS( xblns, "bind", function (e) {
     comp.method();
}, false );

and this is only where one component is used. Modify this to use tons of 
different components which all have load time dependencies and it 
becomes a total mess to maintain.

Compared to this I think it is preferred to have an increased loading 
time of the initial document.

erik

Received on Wednesday, 29 September 2004 12:36:10 UTC