Seeking implementation status of XBL2
Arthur Barstow
The W3C's XBL2 Candidate spec [1] was published almost two years ago.
Since then, there has been some implementation activity reported
(e.g. [2],[3]) but nothing recently.
Does anyone have XBL2 implementation status they can share with us?
-Regards, Art Barstow
[1] <http://www.w3.org/TR/2007/CR-xbl-20070316/>
[2] <http://lists.w3.org/Archives/Public/public-appformats/2007Dec/
0053.html>
[3] <http://lists.w3.org/Archives/Public/public-appformats/2007Nov/
0041.html>
Sean Hogan
xbl.googlecode.com, see http://code.google.com/p/xbl/wiki/Features
dojo.E has some support, see:
http://blog.nexaweb.com/post/xbl-support-for-all-browsers-via-dojoe/
XBLUI, see: http://meekostuff.net/projects/XBLUI/status.html
XBLUI (my project) doesn't implement templates / shadow-trees yet.
cheers,
Sean
> _______________________________________________
> dev-tech-xbl mailing list
> dev-te...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-xbl
>
Boris Zbarsky
> I don't know if there is precedent in counting JS-based implementations
> as valid implementation to get a spec out the door (maybe the Forms WG
> did it?) but I see no reason not to. In fact, I could make the argument
> that they should count *more* as they allow technology to be deployed
> faster than the browser churn.
Assuming the JS-based implementations actually implement the spec as
written, yes. But since the point of the implementation requirement is
to make sure that the spec is in fact implementable, implementations
that don't _quite_ implement it shouldn't count towards the "two
interoperable implementations" criterion.
In particular, I would be somewhat surprised if the JS-based
implementations actually implement the tree-mangling parts of XBL
correctly. I'd welcome being proved wrong, of course.
-Boris
Jonas Sicking
>
> Hi All,
>
> The W3C's XBL2 Candidate spec [1] was published almost two years ago.
> Since then, there has been some implementation activity reported (e.g.
> [2],[3]) but nothing recently.
>
> Does anyone have XBL2 implementation status they can share with us?
I don't yet have any status, however I expect to start working on an
implementation of XBL2 for firefox in a matter of weeks. It's my main
project once we have Firefox 3.1 out the door. However it will take a
while to implement of course, so not sure how rapidly feedback will come in.
/ Jonas
Robin Berjon
> There are a few active JS implementation projects:
I don't know if there is precedent in counting JS-based
implementations as valid implementation to get a spec out the door
(maybe the Forms WG did it?) but I see no reason not to. In fact, I
could make the argument that they should count *more* as they allow
technology to be deployed faster than the browser churn.
--
Robin Berjon - http://berjon.com/
Feel like hiring me? Go to http://robineko.com/
Robin Berjon
> Robin Berjon wrote:
>> I don't know if there is precedent in counting JS-based
>> implementations as valid implementation to get a spec out the door
>> (maybe the Forms WG did it?) but I see no reason not to. In fact, I
>> could make the argument that they should count *more* as they allow
>> technology to be deployed faster than the browser churn.
>
> written, yes. But since the point of the implementation requirement
> is to make sure that the spec is in fact implementable,
> implementations that don't _quite_ implement it shouldn't count
> towards the "two interoperable implementations" criterion.
Oh, I fully agree with that, the point is not to water down the
interoperability requirements. I simply want to make sure that JS-
based implementations are counted as "real" as there often is a
misperception that they are somehow just hacks.
> In particular, I would be somewhat surprised if the JS-based
> implementations actually implement the tree-mangling parts of XBL
> correctly. I'd welcome being proved wrong, of course.
As would I, on both counts. But my point isn't limited to XBL, though
it sure would be nice to be able to deploy with it right now.