W3C home > Mailing lists > Public > www-svg@w3.org > March 2005

Re: sXBL issue -- bindings getting notified when the bound element is inserted into a document

From: Peter Sorotokin <psorotok@adobe.com>
Date: Wed, 23 Mar 2005 10:07:38 -0800
To: Boris Zbarsky <bzbarsky@mit.edu>, Jon Ferraiolo <jon.ferraiolo@adobe.com>, www-svg@w3.org
Message-id: <>

At 06:08 PM 3/22/2005 -0600, Boris Zbarsky wrote:

>Jon Ferraiolo wrote:
>>(1) Boris seems to be saying that in XBL2 a bound element will have 
>>different methods depending on whether it has been inserted into the 
>>document or not.
>No.  I am saying that I hope this does NOT end up the case.  I am also 
>saying that this IS the case in Mozilla XBL in some cases, and that this 
>causes a fair amount of grief.
>Further, I am saying that the best way to prevent this problem cropping up 
>in XBL2 is to consider binding attachment now, before it becomes 
>effectively set in stone by sXBL.

That would mean
  - binding must happen before element is ever accessed (e.g at parse time 
and in createElementNS or similar methods)
  - bindings cannot be changed through styling

That seems to go against the direction of XBL2. We cannot have both 
well-defined methods and dynamic binding attachment

>>I agree that it is likely that somehow or other XBL2 will allow bindings 
>>to define methods and DOM attributes for bound elements. Under that 
>>assumption, thinking ahead to XBL2, doesn't it make sense that these APIs 
>>would be available at the time the xbl:bound event is raised, no matter 
>>whether the bound element is inserted into the document or not?
>Yes, agreed.  I have been operating on the assumption that this is the case.
>I am also operating on the assumption that people will want to use XBL2 to 
>create reusable bindings, which other developers will then use in their 
>pages. If this is not the case, then never mind me.

This is certainly the primary use that I have in mind.


>>(2) I still don't understand why the binding can't just register a 
>>DOMNodeInsertedIntoDocument listener on the bound element. I apologize 
>>for my inability to follow the discussion fully. Is it because 
>>DOMNodeInsertedIntoDocument results in common scenarios where the node 
>>might not be in the document anymore, which causes a large percentage of 
>>developers to have to put in a lot of checks into their scripting logic?
>I would not call the scenarios common.  But they're not particularly rare 
>either (there are certainly HTML pages out there that have <script> nodes 
>that remove themselves from the DOM, or tear down the entire DOM, when 
>they execute, which is more or less the same idea).  And if we accept my 
>premise that people are trying to create reusable bindings, then they need 
>to operate in a wide range of environments, which means they need to deal 
>with this issue.
>>Boris described a case where a binding is added at the same time that 
>>script is removing a node.
>No.  I described a case where the insertion of a node fires events or 
>scripts that remove it.
>>Is this a common case?
>Again, it happens....
>>I am wondering if we can at least warn developers about processing model 
>>complexities and suggest some techniques to avoid these complexities.
>You may want to view my suggestion as a proposal to simplify the 
>processing model so that developers need not deal with quite as much 
Received on Wednesday, 23 March 2005 18:07:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:02 UTC