- 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
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. Peter >>(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 >complexity. > >-Boris
Received on Wednesday, 23 March 2005 18:07:42 UTC