XBL2: First Thoughts and Use Cases

Hello, friendly elves that keep pushing the Web forward!

I spent a few days internalizing the XBL2 spec and here's my first set
of reactions.

First, the XBL2 spec is truly an amazing feat. While reading it, I
kept having visions of walking about an alien artifact, mesmerized by
its scale, with a nagging feeling that I won't be ever able to fully
comprehend its true purpose.

As a result, while I was impressed by the amount of sweat and tears
put into the missive, I often found myself questioning specific
decisions of the spec and not finding a reliable backing in a form of
a use case. To attempt solve this, I started this simple document
(work in progress) and began jotting down the use cases that seemed
important to me:

https://trac.webkit.org/wiki/XBL2UseCases

I invite you to partake in this writing adventure to collect and
inventory precisely what we are trying to accomplish by implementing
this spec. If you don't like the location or the format of the
document, please let me know -- all of this is open and informal.

As an example, one of the larger items that stood out for me was the
dynamic/reflective relationship of the templates toward instances: as
spec'd, any change to the template (even its order!) triggers
destruction/recreation of the instances of the bindings. Yikes! Why
would we want to build this into a browser? It's like mutation events
on crack!

Looking at the use cases, I couldn't think of anything that would
require this type of functionality -- at least not at the cost of its
complexity and performance implications.

Perhaps something simpler, forward-only would be a better solution?
Maybe a template is just a stencil that provides a declarative way to
describe how the shadow DOM is wired up. Once the instance is
stenciled, it has no knowledge of where or how it was created.

Then, we could relegate the role of templating to:
* creating chunks of DOM in the fastest way possible (eg. faster than
a similar JS framework could)
* using declarative syntax (templates) that describe precisely how
this creation should be accomplished.

Another interesting problem was addressing the use case of the
built-in HTML form elements. It seems that in its current form, the
spec doesn't offer a way to hook a bound element into the standard
assiociated form element lifecycle (access from form, value querying
and change, submission). Perhaps it's time to dust off the good old
Web Forms 2 spec and see if we could bring back the custom submission
cycle bits that were there at some point?

Happy Friday!

:DG<

Received on Saturday, 11 December 2010 11:12:48 UTC