On 12/14/10 4:50 PM, Tab Atkins Jr. wrote:
I wasn't thinking of positioning the port with respect to explicit
shadow children. That sounds like something that could be simplified
by punting - change the template language so that you can only set
output ports on childless elements (use a void element for output
ports in the template, which becomes an empty container in the
shadow?)
That ends up creating extra elements, right? The common use cases I've
seen do in fact have the port as a child of an element with explicit
shadow children.
Note that with flexbox layout having to insert an element like that
means that some layouts become impossible.
Hierarchy error. Shadow nodes need to be bound to their specific
shadow tree. Anything else is psychotic, as you say. ^_^
OK, good so far! ;)
4. Nodes are added or removed from the DOM which affect the position of a
particular output port in its parent node.
I'm not sure I understand. Can you elaborate with a trivial example?
I've got a few things in mind that you could possible mean, but I'd
rather not guess.
Using XBL1 syntax, because I can't recall what the XBL2 one is off the
top of my head:
<content>
<div>
<span></span>
<children/>
<span></span>
</div>
<content>
And then you remove the first span.
Gecko doesn't have live templates; just mutable shadows.
Okay. So you do something similar to what I've described with
instantiating the template into data structures, just limited to the
C++ side of the code?
I'm not sure what you mean by "limited to the C++ side of the code".
The way Gecko's implementation "works" if one can call it that is that
there is the template DOM and then the shadow DOM. The shadow DOM is
created by cloning the template DOM, more or less. Output ports are
kept track of on the template DOM. When you insert a node as a child
under the bind element, you find the right port in the template DOM,
then try to find the corresponding location in the (possibly mutated)
shadow DOM. This clearly doesn't work very well!
-Boris
