Re: XBL2 is dead.
spec. Declarative >> syntax really needs to live in HTML. Also... >> >> c) some parts are too small to be their own spec. >> Constructible/extensible DOM objects bit does not even have an API >> surface. >> >> d) And finally, every bit has potential of solving problems that are >> more general than just about components. We shouldn't require making a >> component if all developer wants is some shadow DOM. Similarly, lack >> of needing a component shouldn't preclude the use of confinement >> primitives. >> >> Just to recap: XBL2 is dead, exploding into a pretty rainbow. I am a >> pop tart cat in front of the rainbow. > > :-) > > > -- > Anne van Kesteren > http://annevankesteren.nl/ > >
Re: XBL2 is dead.
On Mon, Sep 26, 2011 at 12:28 AM, Anne van Kesteren wrote: > On Thu, 22 Sep 2011 20:30:24 +0200, Dimitri Glazkov > wrote: >> >> Further, instead of packaging Web Components into one omnibus >> offering, we will likely end up with several free-standing specs or >> spec addendums: >> >> 1) Shadow DOM, the largest bag of with XBL2's donated organs -- >> probably its own spec; >> 2) Constructible and extensible DOM objects which should probably >> just be part of DOM Core and HTML; >> 3) Declarative syntax for gluing the first 2 parts together -- HTML >> spec seems like a good fit; and >> 4) Confinement primitives, which is platformization of the lessons >> learned from Caja (http://code.google.com/p/google-caja/), integrated >> with element registration. > > It's still not very clear to me what any of this means and how it will fit > together. Having either a specification or examples to shoot at would be > helpful. Once it is more clear what each of these parts is going to look > like, it might be easier for me to comment on how you suggest we split them. Yessir! Working on it! :) > > >> Why split it like this? Several reasons: >> >> a) they are independently moving parts. For example, just shadow DOM, >> all by itself, is already a useful tool in the hands of Web >> developers. It's our job as spec developers to ensure that these bits >> comprise a coherent whole, but from implementation perspective, they >> don't need to block one another. > > How do you construct a shadow DOM though declaratively without a component? For consistency's sake, it seems like a pretty cool thing to do. However, the use cases we've been working with haven't shown a need for this. At this point, I've made peace with only being able to construct shadow DOM imperatively without the components. > > >> b) each belongs in the right place. For example, making DOM objects >> extensible is a concern inside of the DOM Core spec. Declarative >> syntax really needs to live in HTML. Also... >> >> c) some parts are too small to be their own spec. >> Constructible/extensible DOM objects bit does not even have an API >> surface. >> >> d) And finally, every bit has potential of solving problems that are >> more general than just about components. We shouldn't require making a >> component if all developer wants is some shadow DOM. Similarly, lack >> of needing a component shouldn't preclude the use of confinement >> primitives. >> >> Just to recap: XBL2 is dead, exploding into a pretty rainbow. I am a >> pop tart cat in front of the rainbow. > > :-) I am glad you liked it :) :DG<
Re: XBL2 is dead.
On Thu, 22 Sep 2011 20:30:24 +0200, Dimitri Glazkov wrote: Further, instead of packaging Web Components into one omnibus offering, we will likely end up with several free-standing specs or spec addendums: 1) Shadow DOM, the largest bag of with XBL2's donated organs -- probably its own spec; 2) Constructible and extensible DOM objects which should probably just be part of DOM Core and HTML; 3) Declarative syntax for gluing the first 2 parts together -- HTML spec seems like a good fit; and 4) Confinement primitives, which is platformization of the lessons learned from Caja (http://code.google.com/p/google-caja/), integrated with element registration. It's still not very clear to me what any of this means and how it will fit together. Having either a specification or examples to shoot at would be helpful. Once it is more clear what each of these parts is going to look like, it might be easier for me to comment on how you suggest we split them. Why split it like this? Several reasons: a) they are independently moving parts. For example, just shadow DOM, all by itself, is already a useful tool in the hands of Web developers. It's our job as spec developers to ensure that these bits comprise a coherent whole, but from implementation perspective, they don't need to block one another. How do you construct a shadow DOM though declaratively without a component? b) each belongs in the right place. For example, making DOM objects extensible is a concern inside of the DOM Core spec. Declarative syntax really needs to live in HTML. Also... c) some parts are too small to be their own spec. Constructible/extensible DOM objects bit does not even have an API surface. d) And finally, every bit has potential of solving problems that are more general than just about components. We shouldn't require making a component if all developer wants is some shadow DOM. Similarly, lack of needing a component shouldn't preclude the use of confinement primitives. Just to recap: XBL2 is dead, exploding into a pretty rainbow. I am a pop tart cat in front of the rainbow. :-) -- Anne van Kesteren http://annevankesteren.nl/
XBL2 is dead.
I just read Anne's update (http://blog.whatwg.org/weekly-xbl-intents) and realized that while Dominic shared the notes (http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1513.html), there wasn't a nice short summary of the discussion published alongside. I should totally correct that. But first things first: XBL2 is dead. To paraphrase http://www.imdb.com/title/tt0093936/quotes?qt=qt0311047, there was a funeral and we buried it. There are chunks of it that are still viable and immensely useful. However, there are large chunks that will have to be cut, some running deep into the viable chunks. At the meeting, there was some discussion on whether to keep the remaining living organs under the auspice (hospice?) of XBL2, but it is fairly clear to anyone attempting this exercise that the surgery will not produce a spec that can stand on its own. Further, instead of packaging Web Components into one omnibus offering, we will likely end up with several free-standing specs or spec addendums: 1) Shadow DOM, the largest bag of with XBL2's donated organs -- probably its own spec; 2) Constructible and extensible DOM objects which should probably just be part of DOM Core and HTML; 3) Declarative syntax for gluing the first 2 parts together -- HTML spec seems like a good fit; and 4) Confinement primitives, which is platformization of the lessons learned from Caja (http://code.google.com/p/google-caja/), integrated with element registration. Why split it like this? Several reasons: a) they are independently moving parts. For example, just shadow DOM, all by itself, is already a useful tool in the hands of Web developers. It's our job as spec developers to ensure that these bits comprise a coherent whole, but from implementation perspective, they don't need to block one another. b) each belongs in the right place. For example, making DOM objects extensible is a concern inside of the DOM Core spec. Declarative syntax really needs to live in HTML. Also... c) some parts are too small to be their own spec. Constructible/extensible DOM objects bit does not even have an API surface. d) And finally, every bit has potential of solving problems that are more general than just about components. We shouldn't require making a component if all developer wants is some shadow DOM. Similarly, lack of needing a component shouldn't preclude the use of confinement primitives. Just to recap: XBL2 is dead, exploding into a pretty rainbow. I am a pop tart cat in front of the rainbow. :DG<
