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-fo...@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
