- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Mon, 18 Jul 2005 15:15:38 -0500
- To: Ian Hickson <ian@hixie.ch>
- CC: www-svg@w3.org
Ian Hickson wrote: > On Mon, 28 Mar 2005, Boris Zbarsky wrote: >> I'm not quite clear on exactly what <content> does, or more precisely on >> which nodes it operates. Section 4.2 talks about "explicit children", >> but consider the situation represented by the diagram in that section -- >> node 3 has an sXBL binding bound to it which makes nodes 4 and 5 >> children of the leftmost purple node (call it node A) in the flattened >> tree. >> >> Now say node A has an sXBL binding bound to it, and this binding has >> <content> elements. Would those be able to reposition node 4 and node 5 >> in the flattened tree under node A? It seems that the intent is that >> they should, yet node 4 and node 5 are not at all explicit children of >> node A... Some clarification here would be nice. > > The <content> element is the one that is an explicit child of A. So that's > what gets "repositioned". And in the final flattened tree, it gets > replaced by what matches it, as normal. So in other words, in the flattened tree nodes 4 and 5 can't be repositioned to different <content> insertion points in the binding attached to A (since it's the <content> node that's a child of A being repositioned, you can't filter 4 and 5 into different insertion points). Is that correct? > This all seems well-defined if you take the spec literally... Perhaps the problem is that as I read I'm mapping onto the Mozilla XBL implementation, looking for the differences, and trying to understand them... -Boris
Received on Monday, 18 July 2005 20:34:55 UTC