XBL 2.0 now a W3C Candidate Recommendation
Jonathan Watt
Does Mozilla intend to implement the W3C XBL 2? Last I heard (admittedly some
time ago) the W3C version was considered completely incompatible and was not
going to be considered. I'd be interested to know if and how that position may
have changed.
-Jonathan
Nickolay Ponomarev
XBL2-compatible.
W3C XBL2 is (almost) the same thing as
http://www.mozilla.org/projects/xbl/xbl2.html , both edited by Hixie.
While it is not compatible with our XBL implementation, we planned to
implement and eventually switch to XBL2.
I would be surprised if this course of action has changed. IIRC,
sicking was sentenced to implementing it, so maybe he can provide us
with updates on this.
Nickolay
Ian Hickson
>
> W3C XBL2 is (almost) the same thing as
> http://www.mozilla.org/projects/xbl/xbl2.html , both edited by Hixie.
To clarify, the only differences are:
* The headers are different -- the W3C one has a different Status of this
Document section (it's longer and has more legalese), and the W3C one
has a "Feedback requests" section that isn't in the Mozilla one.
* The Mozilla one has a more relaxed copyright license. (Creative
Commons, as opposed to the W3C one which is W3C copyright, all rights
being reserved and not granted.)
* The style is different.
The actual spec (everything from the Table of Contents to the bottom) is
the same exact text and markup, built from the same source file.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Martijn
> W3C XBL2 is (almost) the same thing as
> http://www.mozilla.org/projects/xbl/xbl2.html , both edited by Hixie.
> implement and eventually switch to XBL2.
Shouldn't that document be removed, since there is an w3c version
somewhere online?
Regards,
Martijn
Laurent Jouanneau
> While it is not compatible with our XBL implementation, we planned to
> implement and eventually switch to XBL2.
No bug about it ? I didn't find any bug about xbl 2 in the bugzilla.
Laurent
Laurent Jouanneau
Jonas Sicking
It's correct that we weren't too exited about sXBL, however XBL2 looks
like a really nice spec and I'm working on implementing it. However it's
a big and complicated spec and it'll take some time to implement, which
means it's unlikely that Firefox 3 will support XBL2.
(and please don't spam the filed bug with comments about how great it
would be for you to have xbl2 support yesterday, it doesn't help, we
already know)
Best Regards,
Jonas Sicking
Jonas Sicking
not jwatt. Just making a general statement to avoid having the bug
killed by spam.
/ Jonas
Arthur Barstow
On Mar 17, 2007, at 3:22 AM, ext Ian Hickson wrote:
> On Sat, 17 Mar 2007, Nickolay Ponomarev wrote:
>>
>> W3C XBL2 is (almost) the same thing as
>> http://www.mozilla.org/projects/xbl/xbl2.html , both edited by Hixie.
>
> To clarify, the only differences are:
...
> The actual spec (everything from the Table of Contents to the
> bottom) is
> the same exact text and markup, built from the same source file.
Excellent!
Jonathan Watt
> It's correct that we weren't too exited about sXBL, however XBL2 looks
> like a really nice spec and I'm working on implementing it. However it's
> a big and complicated spec and it'll take some time to implement, which
> means it's unlikely that Firefox 3 will support XBL2.
Cool. I'm glad to hear the Mozilla folks in the know are happy enough with it
and that work is happening to implement it. Could you give a high level summary
of the changes from XBL1 or XBL2? Also, does XBL2 obviate the need for XTF, or
are there a few things XTF is still good at that XBL2 is not?
> (and please don't spam the filed bug with comments about how great it
> would be for you to have xbl2 support yesterday, it doesn't help, we
> already know)
I'll try my best. ;-)
-Jonathan
Jonas Sicking
> Jonas Sicking wrote:
>> It's correct that we weren't too exited about sXBL, however XBL2 looks
>> like a really nice spec and I'm working on implementing it. However
>> it's a big and complicated spec and it'll take some time to implement,
>> which means it's unlikely that Firefox 3 will support XBL2.
>
> Cool. I'm glad to hear the Mozilla folks in the know are happy enough
> with it and that work is happening to implement it. Could you give a
> high level summary of the changes from XBL1 or XBL2? Also, does XBL2
> obviate the need for XTF, or are there a few things XTF is still good at
> that XBL2 is not?
XBL1 and XBL2 are vastly different actually. Some of the changes listed:
* The markup is different. For example
<xbl1:content/> = <xbl2:template/>
<xbl1:children/> = <xbl2:content/>
<xbl1:resources><xbl:stylesheet/></xbl1:resources> = <xbl2:style>
xbl:inherits = xbl:attr
* The implementation is fully written in javascript (or other language)
rather than an unholy mixture of XML and javascript.
* XBL2 supports other "automatic" binding mechanisms than CSS which
means that you can easily have multiple bindings attached to the same
element. XBL2 also has various mechanisms to deal with these multiple
bindings living on an element, e.g. the .baseBinding property and the
<inherited> element.
* XBL2 has a proper spec that will hopefully be followed ;)
* XBL2 doesn't allow access to the shadow tree
* In XBL2 the anonymous content lives in the script context of the
binding document. In XBL1 it lives in the bound document's script
context.
* In XBL1 the anonymous content is pseudo-inserted into the bound
document. In XBL2 the anonymous content is not inserted at all, but
rather only affects rendering and some other defined things.
* And plenty more.
I am hoping that XBL2 will remove the need for XTF. If not the plan is
to add things to it such that it does.
/ Jonas
Jonathan Watt
> XBL1 and XBL2 are vastly different actually. Some of the changes listed:
>
> rather than an unholy mixture of XML and javascript.
I'm not sure quite what you mean here.
> * XBL2 supports other "automatic" binding mechanisms than CSS which
> means that you can easily have multiple bindings attached to the same
> element. XBL2 also has various mechanisms to deal with these multiple
> bindings living on an element, e.g. the .baseBinding property and the
> <inherited> element.
Does this allow bindings to be active on an element that isn't currently in a
document? My number one gripe with XBL1 is that you loose your binding if you
move a node from one place in the document to another, and bindings aren't
active during the time the node is not in the document (when you use
createElementNS to create a new element say - at least not until you insert it
into the document). Very frustrating. One of XTF's great strengths is that the
behaviors applied to elements are active at all times.
> * XBL2 doesn't allow access to the shadow tree
Is this for performance/optimization reasons?
> * In XBL2 the anonymous content lives in the script context of the
> binding document. In XBL1 it lives in the bound document's script
> context.
Great. Nice change.
> I am hoping that XBL2 will remove the need for XTF. If not the plan is
> to add things to it such that it does.
Thanks for the info!
-Jonathan
Boris Zbarsky
>> * The implementation is fully written in javascript (or other language)
>> rather than an unholy mixture of XML and javascript.
>
> I'm not sure quite what you mean here.
No more <method>, <field>, etc markup. The implementation is just a blob of
javascript that can define methods, constants, getters, setters, etc just like
JS normally does.
> Does this allow bindings to be active on an element that isn't currently
> in a document?
That's the plan, yes.
>> * XBL2 doesn't allow access to the shadow tree
>
> Is this for performance/optimization reasons?
Security, largely.
-Boris
Jonathan Watt
> Jonathan Watt wrote:
>>> * The implementation is fully written in javascript (or other language)
>>> rather than an unholy mixture of XML and javascript.
>>
>> I'm not sure quite what you mean here.
>
> No more <method>, <field>, etc markup. The implementation is just a
> blob of javascript that can define methods, constants, getters, setters,
> etc just like JS normally does.
Nice, that sounds better to me.
>> Does this allow bindings to be active on an element that isn't
>> currently in a document?
>
> That's the plan, yes.
Excellent! :-) I look forward to that working.
>>> * XBL2 doesn't allow access to the shadow tree
>>
>> Is this for performance/optimization reasons?
>
> Security, largely.
I can see that makes sense when the binding is chrome, but if both the binding
and the bound document are content, or if they're both chrome, it would be nice
to have access to the shadow tree.
-Jonathan
Boris Zbarsky
> I can see that makes sense when the binding is chrome, but if both the
> binding and the bound document are content, or if they're both chrome,
Or if they come from different sites, etc.
There was also an information-hiding concern -- the fact that you can reach into
a binding right now means people write fragile hacks instead of exposing things
on the binding as methods as necessary. For our own UI development we'd want to
enforce not reaching into the anon content anyway, just like we (or rather the
compiler) enforce not touching private members of C++ objects. So we wanted an
option to cut off access no matter what, at which point it was decided that
cutting it off always is both simpler to implement and gives a simpler mental
model of the setup.
There was a good bit of discussion in this group on the topic awhile back.
-Boris
Jonathan Watt
> Jonathan Watt wrote:
>> I can see that makes sense when the binding is chrome, but if both the
>> binding and the bound document are content, or if they're both chrome,
>
> Or if they come from different sites, etc.
>
> There was also an information-hiding concern -- the fact that you can
> reach into a binding right now means people write fragile hacks instead
> of exposing things on the binding as methods as necessary.
Good point.
> For our own
> UI development we'd want to enforce not reaching into the anon content
> anyway, just like we (or rather the compiler) enforce not touching
> private members of C++ objects. So we wanted an option to cut off
> access no matter what, at which point it was decided that cutting it off
> always is both simpler to implement and gives a simpler mental model of
> the setup.
Yeah, okay, I'm convinced. We could certainly do with reducing spec complexity
wherever we can! :-)
> There was a good bit of discussion in this group on the topic awhile back.
Okay, thanks.
-Jonathan
Jonas Sicking
>> * XBL2 doesn't allow access to the shadow tree
>
> Is this for performance/optimization reasons?
By default XBL2 doesn't give you access to the shadow tree, but if you
want it is very easy to for a given binding give anyone access to the
shadow tree. So a better description would be to say "XBL2 lets you hide
the shadow tree". And the reasons for that are the ones Boris raised.
/ Jonas