XBL2
Ian Hickson
Over the past few weeks a bunch of us have been working on updating the
XBL 1.0 specification to "XBL 2.0", addressing a bunch of issues we have
with XBL 1.0 and adding new features where necessary.
http://www.mozilla.org/projects/xbl/xbl2.html
(We started this work after failing to reach consensus within the W3C on
how XBL should progress.)
There are still lots of open questions, not least of which the concern
that as specified there may be performance issues. In particular, in XBL
1.0 we have a bunch of hacks that allow most of the binding document DOM
to be discarded; in this version the XBL DOM has to be kept around. There
are also big open questions about hte binding mechanisms and exactly how
stylesheets should apply.
Anyway. Discuss! I'll go through the feedback we get on this list and take
it into account and produce a new draft in the near future.
Highlights of this version:
* <implementation> no longer has <method>, <property> etc, it's up to the
language to define the implementation (e.g. as a JS prototype).
* Error handling is defined in a lot more detail than in XBL 1.0.
Crashing is no longer a correct way to handle invalid content. :-P
* xbl:pseudo="" to allow elements in the shadow template to map to
pseudo-elements in author CSS.
* Instead of constructors and destructors, events fire during attachment
and detachment.
* More event filters. (One open question is how to handle modifiers.)
* Different interaction with the DOM.
* More precise definition of how CSS Selectors are supposed to work
across binding scopes.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Benjamin Smedberg
> * <implementation> no longer has <method>, <property> etc, it's up to the
> language to define the implementation (e.g. as a JS prototype).
Will the ECMAScript binding for <method>/<property>/etc be included in the spec?
> * Instead of constructors and destructors, events fire during attachment
> and detachment.
Why? Does this have to do with sync/async handling of events and running
script during attachment?
We should discuss attachment/detachment/dynamic inheritance at some point in
detail: in particular I want to make sure that the following use-case is
discussed and specified:
"XUL language" XBL is attached via a non-CSS method... author CSS then
specifies another binding: this should cause both bindings to be applied
using dynamic inheritance.
--BDS
Ian Hickson
> >
> > * <implementation> no longer has <method>, <property> etc, it's up to
> > the language to define the implementation (e.g. as a JS prototype).
>
> Will the ECMAScript binding for <method>/<property>/etc be included in
> the spec?
It already is.
http://www.mozilla.org/projects/xbl/xbl2.html#ecmascript
> > * Instead of constructors and destructors, events fire during attachment
> > and detachment.
>
> Why? Does this have to do with sync/async handling of events and running
> script during attachment?
We wanted events anyway, for various reasons; once we had them, we
realised we didn't need the constructor/destructor model any more. Since
the constructor/destructor model had other problems (e.g. poorly defined
processing model), we figured we might as well drop them.
> We should discuss attachment/detachment/dynamic inheritance at some
> point in detail
That point is now. Discuss.
> in particular I want to make sure that the following use-case is
> discussed and specified:
>
> "XUL language" XBL is attached via a non-CSS method... author CSS then
> specifies another binding: this should cause both bindings to be applied
> using dynamic inheritance.
Dynamic inheritance is defined. The binding mechanisms not so much yet.
Benjamin Smedberg
> That point is now. Discuss.
<specialelement class="foo">
Attachment via CSS:
specialelement {
binding: url(path#binding1);
}
.foo {
binding: url(path2#binding2);
}
According to CSS rules, this would leave us with a single binding2. Is there
a CSS syntax which will attach both bindings via dynamic inheritance? That
leaves us with problems representing computed style as a simple override
mechanism. Assuming that we can attach the XUL language bindings via
external means, this isn't nearly so important as it used to be in my mind,
but I do think that conflict between bindings could cause problems in some
environments.
--BDS
Neil
>Discuss!
>
Gecko XBL contains content such as
<content>
<xul:box>
<children/>
</xul:box>
<children includes="menupopup"/>
</content>
Under the equivalent XBL2 template would all menupopups be attached to
the box?
When you have <X><Y/><Z/></X> and X's binding only contains <content
includes="Y"/> what (I'm guessing display:none; here) happens to Z?
Is it clear that <inherited> may contain <content> but not vice versa?
I don't understand the section on CSS rules, and how it might apply to A
> B where (a) A is the parent of B in the unmodified DOM (b) A is the
parent of <content> under which B has been inserted. Also can you
confirm that where A is a bound element and B is its shadow child then A
> B in A's document's stylesheet does not apply to B unless
allowSelectorsThrough is true?
Does an event in a element inserted at a <content> point bubble to the
<content>'s parent in the shadow tree?
I see there is no way of specifying some required modifiers and some
optional modifiers.
I don't know to which KeyEvent interface you refer but I wonder how it
distinguishes (if at all) between characters and special keys.
Can you confirm that the nearest equivalent of Gecko's
document.getAnonymousElementByAttribute(aElement, "id", aID) is
aElement.xblShadowTree.getElementById(aID) ?
--
Warning: May contain traces of nuts.
kurt....@gmail.com
with XSLT now in most of the targeted browsers, it may actually be
preferable to utilize the XSLT engine to parse the browser bindings and
pass this in as defined constructed entities directly into the
scripting environment. This opens up the extension mechanism
considerably - by utilizing bound XSLTs (perhaps via extensions) should
you switch scripting contexts, you could also switch the
transformations associated with the bindings to produce Python, Perl,
etc., XBLs as well.
I'm not suggesting here that the XSLTs should replace the bindings
directly, by the way, only that the XSLT should be used to generate the
bound JS, Python, etc. objects in the first place, including generation
of the data models for subsequent binding generations.
One final note: In developing use cases for XBL 2.0, keep SVG as being
a very likely use case with all that this entails (internal referential
entities being the big one) - currently in order to develop an XBL 1.0
SVG binding, you have to hack the SVG something fierce in order to
insure that subordinated SVG objects with ids have references within
the SVG pointing properly to them.
-- Kurt Cagle
kurt....@gmail.com
kurt....@gmail.com
binding mechanism be provided in addition to the two current methods
(CSS and the attachBinding() method). This binding method would
utilize an XML document to indicate all bound documents, something
along the order of:
<bindings xmlns:xlink="http://www.w3.org/1999/xlink">
<binding namespace="http://www.mynamespace.com"
xlink:href="myBindings.xml" use="myBinding1"
appliesTo="//foo|//bar|//*/title[@bat]"/>
</bindings>
Why this approach? Currently the CSS binding system is pre-bound, and
the extensions for importing CSS after the document has been loaded are
generally poorly understood. By binding through XML you could actually
set up an AJAX based binding architecture where objects would be bound
or unbound as apropriate at any time, where multiple bindings could be
attached or detached as a group, and where such bindings could be
configured according to the device profiles without requiring human
intervention, something that is a problem with the CSS.
-- Kurt Cagle
Brendan Eich
>On Mon, 24 Oct 2005, Benjamin Smedberg wrote:
>
>
>>> * <implementation> no longer has <method>, <property> etc, it's up to
>>>the language to define the implementation (e.g. as a JS prototype).
>>>
>>>
>>Will the ECMAScript binding for <method>/<property>/etc be included in
>>the spec?
>>
>>
>
>It already is.
>
> http://www.mozilla.org/projects/xbl/xbl2.html#ecmascript
>
Just read this, and it is overspecified. You should not enclose the
implementation source in ({}), because that requires that the source
contain property initalisers (ECMA-262 Edition 3, 11.1.5 Object
Initialiser -- the non-terminal name is PropertyNameAndValueList).
Objections:
1. It's weird to require the .js file, if using <implementation/>, to
be ill-formed JS, not a Program (ECMA-262 Edition 3, 14) grammatically;
it's only slightly less weird to do this for inline content.
2. It prevents me writing a function call that returns the object
prototype, or any other kind of expression than (the guts of) an object
initialiser.
I also wonder why the spec talks about "Object" in "a single Object
prototype" -- that sounds like the [[Class]] (ECMA-262 terminology,
again) must be "Object", but it should be possible to use other class
instances as XBL2 implementations.
This might just be a typo or jargon nit -- if you use lowercase-o
"object" here, I think everything's cool. It also avoids confusion with
Object.prototype, which is the ur-object, the root of the object class
prototype delegation tree.
/be
Brendan Eich
Here is an attempt at a rewrite of the offending paragraph:
Regardless of the source, the processing is the same. The implementation
script is evaluated as an ECMAScript Program [ECMA-262 Edition 3,
section 14]. If the result is of Object type, then it is used as the
prototype for the implementation of this binding. Otherwise, it is in
error, there is no implementation for this binding, and the UA must
ignore the implementation.
----- end offending paragraph -----
I'm not sure how many implementations of this binding, or bindings of
this implementation ;-), there might be. If only one, why have the
evaluated result of the Program be a prototype, instead of using it
directly as the object that implements the binding's fields, methods,
properties, and handlers?
Also not clear is how much we want to specify XBL2 member (field,
method, property, handler) to JS property mapping. I should read the
rest of the spec before going further, but if this is enough for now,
please let me know.
/be
Neil
>There are still lots of open questions
>
OK, so I see XBL2 has built-in support for mutation events, so you can
easily tell when someone sets an attribute on an element. But what
concerns me is someone dynamically building a menulist. In Gecko XBL we
do a one-time check (generally when the element is first displayed). In
XBL2 are we expected to use mutation events to ensure that our state is
consistent?
>(One open question is how to handle modifiers.)
>
>
Oops, missed that bit last time :-[
Boris Zbarsky
> * Instead of constructors and destructors, events fire during attachment
> and detachment.
I don't really like this. The problem with DOM events is that the
immediate-dispatch aspect makes any sort of ordering a joke. For example, say
I'm attaching a binding. I fire the "bound" event. A capturing event handler
does something that causes the binding to become detached. Questions:
1) Should the "unbinding" event fire?
2) Should the "bound" event keep propagating?
If the answer to both is yes, then "unbinding" will fire on the bound node
before "bound" does. The net result will be that "bound" fired last, and no
binding is attached.
The "prebind" event makes things a little more complicated, since the binding
can also be detached while totally in the middle of being set up.
I noticed you have a little note that all this needs sorting out, but I think
the simplest way to sort it out is to not employ DOM events...
That said, I realize it's nontrivial to do the existing constructor/destructor
setup in Mozilla in a language-agnostic manner.
One other note: we have been pretty much assuming that there would be no
dynamic detachment for bindings which use xbl:implements (and possibly that
there would be no dynamic attachment for them). At least in the Gecko
implementation.
-Boris
Ian Hickson
>
>
> Attachment via CSS:
>
> specialelement {
> binding: url(path#binding1);
> }
>
> .foo {
> binding: url(path2#binding2);
> }
>
> According to CSS rules, this would leave us with a single binding2. Is
> there a CSS syntax which will attach both bindings via dynamic
> inheritance?
Not yet. There's long been talk of allowing an !additive cascade. I don't
think we want to try and introduce this at the same time as XBL2.
What's the use case? Note that <?xbl?> and <binding element="(selector)">
are the new ways to define binding attachment, and they are additive
automatically.
Ian Hickson
>
> Gecko XBL contains content such as
> <content>
> <xul:box>
> <children/>
> </xul:box>
> <children includes="menupopup"/>
> </content>
>
> Under the equivalent XBL2 template would all menupopups be attached to
> the box?
Yes. You could do what I believe you are asking for by doing:
<template>
<xul:box>
<content includes=":not(menupopup)"/>
</xul:box>
<content includes="menupopup"/>
</template>
> When you have <X><Y/><Z/></X> and X's binding only contains <content
> includes="Y"/> what (I'm guessing display:none; here) happens to Z?
Nothing in particular. They don't get rendered, style doesn't get
computed on them.
> Is it clear that <inherited> may contain <content> but not vice versa?
There is nothing illegal about nesting in either direction.
> I don't understand the section on CSS rules, and how it might apply to A
> > B where (a) A is the parent of B in the unmodified DOM (b) A is the
> parent of <content> under which B has been inserted.
Not sure what the question is, can you expand?
> Also can you confirm that where A is a bound element and B is its shadow
> child then A > B in A's document's stylesheet does not apply to B unless
> allowSelectorsThrough is true?
allowSelectorsThrough _and_ applyAuthorSheets must be true for it to
apply.
> Does an event in a element inserted at a <content> point bubble to the
> <content>'s parent in the shadow tree?
Not in the current model.
> I see there is no way of specifying some required modifiers and some
> optional modifiers.
I will address modifiers separately (I'm going to rewrite this section).
> I don't know to which KeyEvent interface you refer but I wonder how it
> distinguishes (if at all) between characters and special keys.
See DOM3 Events.
> Can you confirm that the nearest equivalent of Gecko's
> document.getAnonymousElementByAttribute(aElement, "id", aID) is
> aElement.xblShadowTree.getElementById(aID) ?
This appears to be correct, yes.
Ian Hickson
>
> I was thinking about bindings this morning, and it occurred to me that
> with XSLT now in most of the targeted browsers, it may actually be
> preferable to utilize the XSLT engine to parse the browser bindings and
> pass this in as defined constructed entities directly into the scripting
> environment. This opens up the extension mechanism considerably - by
> utilizing bound XSLTs (perhaps via extensions) should you switch
> scripting contexts, you could also switch the transformations associated
> with the bindings to produce Python, Perl, etc., XBLs as well.
>
> I'm not suggesting here that the XSLTs should replace the bindings
> directly, by the way, only that the XSLT should be used to generate the
> bound JS, Python, etc. objects in the first place, including generation
> of the data models for subsequent binding generations.
I'm not sure what you are proposing here. Could you give a concrete spec
proposal that we could read to get a better idea of your suggestion?
> One final note: In developing use cases for XBL 2.0, keep SVG as being a
> very likely use case with all that this entails (internal referential
> entities being the big one) - currently in order to develop an XBL 1.0
> SVG binding, you have to hack the SVG something fierce in order to
> insure that subordinated SVG objects with ids have references within the
> SVG pointing properly to them.
I've added a section on how XBL2 and SVG are intended to be implemented.
http://www.mozilla.org/projects/xbl/xbl2.html#svg
Cheers,
Ian Hickson
>
> Ian Hickson wrote:
> > * Instead of constructors and destructors, events fire during attachment
> > and detachment.
>
> I don't really like this. The problem with DOM events is that the
> immediate-dispatch aspect makes any sort of ordering a joke.
I've now nuked these events. Let me know if the new system is better.
> One other note: we have been pretty much assuming that there would be
> no dynamic detachment for bindings which use xbl:implements (and
> possibly that there would be no dynamic attachment for them). At least
> in the Gecko implementation.
<xbl:binding implements=""> is now dead. Still working on a better idea
to replace it, though.
Ian Hickson
(cc'ed mozilla-xbl, hope that's ok)
On Thu, 27 Oct 2005, Brendan Eich wrote:
>
> Here is an attempt at a rewrite of the offending paragraph:
>
> Regardless of the source, the processing is the same. The implementation
> script is evaluated as an ECMAScript Program [ECMA-262 Edition 3, section 14].
> If the result is of Object type, then it is used as the prototype for the
> implementation of this binding. Otherwise, it is in error, there is no
> implementation for this binding, and the UA must ignore the implementation.
>
> ----- end offending paragraph -----
I've changed the error handling -- it's too late to ignore the
implementation if you've evaluated it! :-)
I've also added a statement that the evaluation happens in the scope of
the binding document.
http://www.mozilla.org/projects/xbl/xbl2.html#ecmascript
> I'm not sure how many implementations of this binding, or bindings of this
> implementation ;-), there might be.
Many to many. Each bound element can be associated with multiple bindings,
each with an implementation, with binding inheritance happening as
described in:
http://www.mozilla.org/projects/xbl/xbl2.html#inheritance
And each implementation can be bound to multiple elements. The
implementation is re-evaluated each time, according to the current
definition. Should we say it is evaluated once and the prototype reused
each time?
> If only one, why have the evaluated result of the Program be a
> prototype, instead of using it directly as the object that implements
> the binding's fields, methods, properties, and handlers?
I have no idea either way; what do you recommend?
> Also not clear is how much we want to specify XBL2 member (field,
> method, property, handler) to JS property mapping. I should read the
> rest of the spec before going further, but if this is enough for now,
> please let me know.
I'm not sure what you are asking here, but further feedback from you on
this matter is most welcome!
Cheers,
Ian Hickson
>
> OK, so I see XBL2 has built-in support for mutation events, so you can
> easily tell when someone sets an attribute on an element. But what
> concerns me is someone dynamically building a menulist. In Gecko XBL we
> do a one-time check (generally when the element is first displayed). In
> XBL2 are we expected to use mutation events to ensure that our state is
> consistent?
Can you expand on this? I don't really understand the question.
Boris Zbarsky
> What's the use case? Note that <?xbl?> and <binding element="(selector)">
> are the new ways to define binding attachment, and they are additive
> automatically.
How is the ordering determined? More specifically:
1) If more than one binding can generate shadow trees, how does the whole thing
work?
2) If more than one binding attempts to define a property on the object via its
implementation, what happens?
-Boris
Neil
>On Tue, 25 Oct 2005, Neil wrote:
>
>
>>Is it clear that <inherited> may contain <content> but not vice versa?
>>
>>
>There is nothing illegal about nesting in either direction.
>
>
OK, I guess I misunderstood that bit.
>>I don't understand the section on CSS rules, and how it might apply to A
>>
>>
>>>B where (a) A is the parent of B in the unmodified DOM (b) A is the
>>>
>>>
>>parent of <content> under which B has been inserted.
>>
>>
>Not sure what the question is, can you expand?
>
>
Consider <template><B><content/></B></template> bound to an element A
with an explicit child C. Which of these style rules (in an appropriate
stylesheet) match somewhere: A > B, A > C, B > C?
>>I don't know to which KeyEvent interface you refer but I wonder how it distinguishes (if at all) between characters and special keys.
>>
>>
>See DOM3 Events.
>
>
Ah, so for instance space is named "U+0020".
Neil
>On Fri, 28 Oct 2005, Neil wrote:
>
>
>>OK, so I see XBL2 has built-in support for mutation events, so you can easily tell when someone sets an attribute on an element. But what concerns me is someone dynamically building a menulist. In Gecko XBL we do a one-time check (generally when the element is first displayed). In XBL2 are we expected to use mutation events to ensure that our state is consistent?
>>
>>
>Can you expand on this? I don't really understand the question.
>
>
If an element's initialisation depends on its attributes or children,
when should the element attempt to initialise, or must it assume nothing
and use mutation events to keep track?
Oh, and it's unnecessary to CC me, as I read netscape.public.mozilla.xbl
(although had I subscribed to the mailing list I wouldn't have wanted an
extra copy either, but I don't know how clever the list software is in
this respect).
Neil
> If an element's initialisation depends on its attributes or children,
> when should the element attempt to initialise, or must it assume
> nothing and use mutation events to keep track?
Ah, I see you now have both shadow tree created and binding inserted
methods, which should be satisfactory.
Benjamin Smedberg
> I've also added a statement that the evaluation happens in the scope of
> the binding document.
>
> http://www.mozilla.org/projects/xbl/xbl2.html#ecmascript
This is where I think things are going to get tricky: when you say "each
implementation can be bound to multiple elements", would they all share an
ecmascript scope (global object). I thought that each binding would have
it's own global object, and then the script would be evaluated for each binding.
>> I'm not sure how many implementations of this binding, or bindings of this
>> implementation ;-), there might be.
>
> Many to many. Each bound element can be associated with multiple bindings,
> each with an implementation, with binding inheritance happening as
> described in:
>
> http://www.mozilla.org/projects/xbl/xbl2.html#inheritance
>
> And each implementation can be bound to multiple elements. The
> implementation is re-evaluated each time, according to the current
> definition. Should we say it is evaluated once and the prototype reused
> each time?
--BDS
Jonas Sicking
> I was thinking about bindings this morning, and it occurred to me that
> with XSLT now in most of the targeted browsers, it may actually be
> preferable to utilize the XSLT engine to parse the browser bindings and
> pass this in as defined constructed entities directly into the
> scripting environment. This opens up the extension mechanism
> considerably - by utilizing bound XSLTs (perhaps via extensions) should
> you switch scripting contexts, you could also switch the
> transformations associated with the bindings to produce Python, Perl,
> etc., XBLs as well.
Being one of the main developers of the XSLT engine in mozilla I can
tell you that this is not practical (the idea has been raised several
times before).
The main problem with XSLT is that it is very hard to track
dependencies. Any tiny change in the DOM can cause the result document
to compleatly change. In order to use XSLT (or XPath) in all bindings in
the entire tree would likly have to be rebuilt on every single change in
the DOM.
This would have severe performance problems.
The idea is neat, but unfortunatly XSLT wasn't designed with this in mind.
Best Regards
Jonas Sicking
Ian Hickson
> Ian Hickson wrote:
> > What's the use case? Note that <?xbl?> and <binding element="(selector)">
> > are the new ways to define binding attachment, and they are additive
> > automatically.
>
> How is the ordering determined? More specifically:
>
> 1) If more than one binding can generate shadow trees, how does the whole
> thing work?
http://www.mozilla.org/projects/xbl/xbl2.html#rules
> 2) If more than one binding attempts to define a property on the object via
> its implementation, what happens?
http://www.mozilla.org/projects/xbl/xbl2.html#inheritance
Ian Hickson
> Ian Hickson wrote:
> >
> > I've also added a statement that the evaluation happens in the scope
> > of the binding document.
> >
> > http://www.mozilla.org/projects/xbl/xbl2.html#ecmascript
>
> This is where I think things are going to get tricky: when you say "each
> implementation can be bound to multiple elements", would they all share
> an ecmascript scope (global object).
Yes. The scope of the binding document.
> I thought that each binding would have it's own global object, and then
> the script would be evaluated for each binding.
The script is evaluated for each binding (according to the current spec's
prose; this can change if you don't like it). However, each binding, as
currently defined, shares the binding document scope, allowing common
functions and singletons to be shared across instances of the binding.
Ian Hickson
> > >
> > > I don't understand the section on CSS rules, and how it might apply to A
> > > > B where (a) A is the parent of B in the unmodified DOM (b) A is the
> > > parent of <content> under which B has been inserted.
> > >
> > Not sure what the question is, can you expand?
>
> Consider <template><B><content/></B></template> bound to an element A with an
> explicit child C. Which of these style rules (in an appropriate stylesheet)
>
> "A > B"
Does not match anything, because the allowSelectorsThrough attribute is
not set on the <template> element.
(If it had been set, would match B in the binding's stylesheets, UA
stylesheets, and user stylesheets. If the applyAuthorSheets attribute had
been set as well, then it would match B in the bound document's author
stylesheets too.)
> "A > C"
Matches C in the bound document's stylesheets, UA stylesheets, and user
stylesheets. (If the applyBindingSheets attribute had been set on the
<content> element, would match C in the binding's stylesheets too.)
> "B > C"
Never matches.
HTH,
Ian Hickson
> > On Fri, 28 Oct 2005, Neil wrote:
> >
> > > OK, so I see XBL2 has built-in support for mutation events, so you
> > > can easily tell when someone sets an attribute on an element. But
> > > what concerns me is someone dynamically building a menulist. In
> > > Gecko XBL we do a one-time check (generally when the element is
> > > first displayed). In XBL2 are we expected to use mutation events to
> > > ensure that our state is consistent?
> >
> > Can you expand on this? I don't really understand the question.
>
> If an element's initialisation depends on its attributes or children, when
> should the element attempt to initialise, or must it assume nothing and use
> mutation events to keep track?
It should always use mutation events to keep track. This is the case
whether you use XBL2, XBL1, or even if you implement it in C++. Otherwise
behaviour will not be synchronised with the state of the DOM.
> Oh, and it's unnecessary to CC me, as I read netscape.public.mozilla.xbl
> (although had I subscribed to the mailing list I wouldn't have wanted an
> extra copy either, but I don't know how clever the list software is in
> this respect).
Okie dokie.
Boris Zbarsky
> It should always use mutation events to keep track. This is the case
> whether you use XBL2, XBL1, or even if you implement it in C++. Otherwise
> behaviour will not be synchronised with the state of the DOM.
In C++, I would use nsIDocumentObserver. This has better behavior than mutation
events, but mostly because there are few observers and we can trust them not to
mess with the DOM (mostly, at least; I want to fix the few cases, all involving
XBL, where this fails).
With mutation events all you can tell is that the attribute changed; you have to
query the element to see what the actual value is... Granted, that's enough for
this case.
-Boris
Benjamin Smedberg
> On Fri, 4 Nov 2005, Benjamin Smedberg wrote:
>> Ian Hickson wrote:
>>> I've also added a statement that the evaluation happens in the scope of
the binding document.
>>>
>>> http://www.mozilla.org/projects/xbl/xbl2.html#ecmascript
>> This is where I think things are going to get tricky: when you say "each
implementation can be bound to multiple elements", would they all share an
ecmascript scope (global object).
>
> Yes. The scope of the binding document.
This scope of the binding document, is it only for one bound document, or
one "window", or is it shared across the entire application? i.e. when you
navigate from one page to the next, both using the same binding, is there a
new scope?
--BDS
I apologize if people get multiple copies of this, I've been having email
problems.
Daniel Glazman
should be notified when the bound element becomes selected (ie when
the document's selection starts containing the selection) and when
the bound element becomes unselected (blabla :-).
It's always feasible through a bit of script. But having two callback
methods on XBLImplementation would _greatly_ help.
</Daniel>