Re: What is happening with XBL?

We've discussed this on Forms WG and are preparing a reply, but in the 
interest of time I'll give a summary:

The Forms WG members are pleased with the progress toward real-world XBL 
and shadow-DOM injection facilities in popular desktop browsers, and 
want to encourage that work.

Additionally, a number of our members are using a cut-down version of 
XBL2 as a macro language for composing XForms and HTML components, 
usually in a transformation step that takes place before markup is 
delivered to popular desktop browsers.

The use cases which public-webapps is currently studying for XBL also 
include component definitions, so we feel that is harmony between the 
goals, and *hope that we can work together to a common specification*, 
though perhaps with optional features.

While there are non-browser implementations of XForms, most XForms 
implementations for popular desktop browsers are using JavaScipt and 
other in-browser facilities to provide a markup-based, declarative 
interface to the native facilities available in the browser, and we see 
progress in the shadow-DOM front as a great benefit.  Our hope is that 
as HTML5 moves forward that it gets easier, rather than harder, to 
provide XForms declarative markup-based access to browser facilities, 
and we hope to leverage the eventual XBL-like shadow-DOM injection 
facility as part of this delivery, /as well as/ retain the ability to 
define and use components containing a mix of HTML and XForms markup.

A number of XForms implementations make use of XBL or cut-down versions 
of XBL2 to develop widgets and composite controls:
1A: In Mozilla XForms the XForms markup is bound with full-blown XBL 
with shadow DOM, CSS bindings, JavaScript etc.
1B: In all others, a cut-down XBL2 is used as a simple macro-language 
for composing compound form controls out of HTML and XForms markup, 
without any participation in the underlying HTML4 browser shadow DOM.  
In these cases, XSLT is also used to provide a transformation step, 
providing the ability to use attribute-value templates to perform 
substitutions instead of simply copying of attribute values.
*
Being able to unify these two uses of XBL is our goal, and obviously if 
a better version of XBL is widely deployed in popular desktop browsers, 
that task becomes easier. *

However, there is one area of concern, and that is that it the ability 
to bind to markup in the XForms namespace, or to produce output markup 
in the XForms namespace may be removed from XBL.   Ian Hixson's proposal 
to eliminate namespaces and event support from XBL2 is the most 
troubling issue for us.

To expand on this point, for case 1A, we feel that it's necessary to 
provide an ability to match markup with namespaced elements, and also to 
produced namespaced-elements (mostly XForms in both cases) as output.   
A clear idea of when XSLT PIs are processed and when XBL definitions are 
processed might go far toward helping resolve this issue.    However, 
for case 1B, where the XBL implementation is not within the browser, 
optional namespace support in the Recommendation may be sufficient.

It may be that if XSLT PI support is retained, in-browser 
implementations will be able to continue to use that to provide the 
namespace matching necessary to disambiguate XForms from underlying 
HTML4 or HTML5 elements, and then the shadow-DOM facility can operate at 
a separate level.  Some implementations have had success in using 
in-browser XSLT or in-browser JavaScript re-parsing of the live DOM to 
bridge between the XForms markup and HTML+JavaScript implementation.  
However, a clear ability to do one of these two things from within XBL 
(interpose XSLT transformations, with namespace binding, or to use 
JavaScript to read the incoming DOM with un-munged namespaced elements) 
would be necessary to sure a path to success with an XForms+XHTML+XBL -> 
HTML5+XBL in-browser conversion (i.e., to allow XBL to operate both to 
expand into XForms markup and to participate in the in-browser behavior).

Additionally, some of our WG members feel that XPath selectors would be 
more useful for case 1B.  However, I believe we are approaching a 
consensus that CSS selectors are OK for case 1A, so my personal belief 
is that we will most likely not be asking for XPath selectors.

Leigh.


On 01/24/2011 05:24 AM, Arthur Barstow wrote:
> [ Bcc: set to: public-forms@w3.org ; please set Reply-To: to just 
> public-webapps@w3.org ]
>
> XBL Fans,
>
> In case you missed it, about a week ago, Anne van Kesteren wrote a 
> nice blog about some of the recent activities with XBL including 
> pointers to some related work by Dimitri Glazkov (e.g. Use Cases). 
> Given AvK's blog is short-ish, I'll quote it here:
>
> [[
> http://annevankesteren.nl/2011/01/xbl
>
> What is happening with XBL?
> 15th January 2011
>
>
>     What is happening with XBL?
>
> Despite quite a bit of interest when XBL 2.0 
> <http://www.w3.org/TR/2007/CR-xbl-20070316/> was developed it has not 
> made it into browsers thus far. Perhaps because Jonas Sicking is too 
> occupied, or perhaps it simply is too complex. The drive for XBL 
> started moving again late last year when Ian Hickson simplified 
> <http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0675.html> 
> the specification. Instead of a new language XBL would become a set of 
> extensions to HTML.
>
> In parallel, Dimitry Glazkov started drafting Component Model Use 
> Cases <http://wiki.whatwg.org/wiki/Component_Model_Use_Cases>, a 
> WHATWG Wiki document anyone can contribute to. Effectively taking a 
> fresh look at what we want nowadays from XBL. He also wrote a great 
> post for anyone not familiar with the types of scenarios XBL will 
> tackle: What the Heck is Shadow DOM? 
> <http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/> It is a 
> complex subject, but the way he conveys it makes it look easy.
>
> Now I have been hopeful for XBL happening pretty much since we started 
> working on HTML5 in 2004 so I am not too excited yet. But for the 
> first time in almost four years we are making progress again.
>
> ]]
>
> I think there are at least four different versions of XBL specs with 
> various levels of implementations:
>
> 1. Mozilla XBL: original, Mozilla-specific; Blue Griffon. Perhaps some 
> XForms implementations also implement Mozilla XBL?
>
> 2. sXBL: first attempt at a standard XBL, aimed mainly at SVG. Lots of 
> interest at SVG Open three or four years ago but apparently interest 
> has died?
>
> 3. XBL2 CR: - some XForms implementations reported; Jonas announced 
> some work (last report May 2010)
>
> http://www.w3.org/TR/2007/CR-xbl-20070316/
> http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/1008.html   
> [from Leigh]
> http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0485.html [from 
> Jonas]
>
> 4. XBL2-cutdown: Hixie's September 2010 version. Not clear if there is 
> any implementers support for this enough or if any 
> prototyping/implementing has been done.
>
> http://dev.w3.org/2006/xbl2/
> http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0675.html
>
> It would be useful to get updated implementation plans/data, 
> especially for #3 and #4 above.
>
> As Anne implies, Dimitri's work raises questions about whether XBL2 CR 
> or XBL2-cutdown are the right approach or is a different approach is 
> needed?
>
> Additionally, given the broad set of constituencies here, and the 
> requirement to preserve implementation investment, is it realistic to 
> expect one spec to satisfy all of the use cases and requirements?
>
> -Art Barstow
>
>
>
>
>
>
>
>