Re: XBL2, Component Model and WebApps' Rechartering [Was: Re: Consolidating charter changes]
On Sat, 17 Dec 2011 16:24:47 +0100, Olli Pettay olli.pet...@helsinki.fi wrote: On 12/17/2011 04:30 PM, Anne van Kesteren wrote: On Thu, 24 Nov 2011 14:08:55 +0100, Arthur Barstow art.bars...@nokia.com wrote: All - What are the opinions on what, if anything, to do with XBL2 vis-a-vis the charter update? Leave it on the REC track, stop work and publish it as a WG Note, something else? I would leave it as, but add a note we might abandon it at some point in favor of Components. No need to make an early call on that. That sounds good to me. Yeah, in drafting the new charter I think that is the approach I took. I'll check again when we have figured out what teh story is with things people wanted but needed to provide more info for... cheers Chaals -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan litt norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: XBL2, Component Model and WebApps' Rechartering [Was: Re: Consolidating charter changes]
On Thu, 24 Nov 2011 14:08:55 +0100, Arthur Barstow art.bars...@nokia.com wrote: All - What are the opinions on what, if anything, to do with XBL2 vis-a-vis the charter update? Leave it on the REC track, stop work and publish it as a WG Note, something else? I would leave it as, but add a note we might abandon it at some point in favor of Components. No need to make an early call on that. [1] http://www.w3.org/2008/webapps/wiki/CharterChanges#Additions_Agreed -- Anne van Kesteren http://annevankesteren.nl/
Re: XBL2, Component Model and WebApps' Rechartering [Was: Re: Consolidating charter changes]
On 12/17/2011 04:30 PM, Anne van Kesteren wrote: On Thu, 24 Nov 2011 14:08:55 +0100, Arthur Barstow art.bars...@nokia.com wrote: All - What are the opinions on what, if anything, to do with XBL2 vis-a-vis the charter update? Leave it on the REC track, stop work and publish it as a WG Note, something else? I would leave it as, but add a note we might abandon it at some point in favor of Components. No need to make an early call on that. That sounds good to me. -Olli [1] http://www.w3.org/2008/webapps/wiki/CharterChanges#Additions_Agreed
Re: XBL2, Component Model and WebApps' Rechartering [Was: Re: Consolidating charter changes]
On 11/23/11 1:10 PM, ext Dimitri Glazkov wrote: Let's iterate and get it to the digestible point :) Thanks for the list. Given we consider Web Components already in scope, I added it to the Additions Agreed section as a reminder it should be an explicit deliverable [1]. I expect that Web Components will completely supersed the XBL2 work and address all of the use cases that originally motivated development of XBL2. All - What are the opinions on what, if anything, to do with XBL2 vis-a-vis the charter update? Leave it on the REC track, stop work and publish it as a WG Note, something else? -AB [1] http://www.w3.org/2008/webapps/wiki/CharterChanges#Additions_Agreed
Re: XBL2, Component Model and WebApps' Rechartering [Was: Re: Consolidating charter changes]
Hi Arthur! I am a procedural n00b and apologize in advance if this is not exactly what you're looking for. Let's iterate and get it to the digestible point :) In the next few months, I'll be working on and refining (with the help of folks who are interested in the subject): 1) a detailed spec (I think it's called a working draft) for Web Components; 2) a Web Components explainer document, aimed at Web developers, outlining how the component model works in conversational prose and examples; 3) a comprehensive overview of goals, use cases, properties, reasoning, and methodology behind the component model. I expect that Web Components will completely supersed the XBL2 work and address all of the use cases that originally motivated development of XBL2. All work is currently happening at http://dglazkov.github.com/component-model/ and http://wiki.whatwg.org/index.php?title=Component_Model. As long as it doesn't slow me down, I am happy to adopt any procedural conventions or places to work in -- if it's helpful in making WebApps WG more coherent and beautiful. :DG On Wed, Nov 23, 2011 at 5:28 AM, Arthur Barstow art.bars...@nokia.com wrote: Hi All, In the context of WebApps' rechartering, what are our plans and expectations for XBL2 and Component modeling? For example, what do we want to stop (e.g. move to WG Note); are there any new deliverable(s) we want to add? (I just noticed we are coming up on five years since the XBL2 CR was published.) -AB On 11/8/11 12:37 PM, ext Arthur Barstow wrote: During the October 31 meeting, we discussed [1] various additions, changes and deletions for WebApps' current charter [2]. To consolidate the various proposals, I created the following doc: http://www.w3.org/2008/webapps/wiki/CharterChanges My expectation is that Doug will this information when he drafts our updated charter. Comments on this doc and our future charter welcome. However, if we are going to add any new deliverables, I think there should be broad agreement on the spec, including prior commitment to drive the spec through all of the phases of the process including testing and implementations. Chaals, IanF - I included some actions/questions for you (mostly recorded at the f2f meeting). -AB [1] http://www.w3.org/2011/10/31-webapps-minutes.html [2] http://www.w3.org/2010/webapps/charter/
Re: XBL2 is dead.
On Mon, Sep 26, 2011 at 8:28 AM, Anne van Kesteren ann...@opera.com wrote:
On Thu, 22 Sep 2011 20:30:24 +0200, Dimitri Glazkov dglaz...@chromium.org
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.
While Dimitri works on the wiki version (pending his vacation), let me
lay them out in a slightly different order (2, 3, 1, 4):
- Today's DOM is actively hostile to idiomatic use in JavaScript. The
current WebIDL draft fixes some of this (yay for real prototypes!) but
not all. What we're suggesting is that, at least for HTML, we should
close the circuit on this as a matter of hygiene if nothing else.
Practically speaking, that means: giving HTML element types *real*
constructors (e.g. today's new Image(), not just create* factories),
allowing them to be subclassed in the same idiomatic way everything
else in JS can, and giving them meaningful prototypes (handled by
WebIDL). Combined, these give us a way to think about building new
elements but without any connection to markup. They're just new JS
types that just happen to be DOM nodes. The fact that we think of them
differently today is *A BUG*, and one that we can fix. Best of all,
this is exactly the sort of thing that UI libraries like JQuery UI,
Dojo, Closure, YUI, etc, etc. do all day long but without
infrastructure to *really* participate in DOM.
- Declarative syntax is sugar that makes all this programmatic stuff
amenable to tooling and web developers who are more comfortable with
HTML than JS
- Once we've got custom element types, it sure would be handy to be
able to hide away your UI implementation. Shadow DOM, a concept
cribbed from XBL and friends, can provide this. Once you can have a
scriptable shadow which hides its elements away from regular
traversal, your element's API becomes more useful since your guts
aren't spilling out for the world to view. We've already refactored
many WebKit internal element implementations to use Shadow DOM to
great effect, so the value is clear. Exposing it to content authors is
the next obvious step.
- Describing all of what happens above in terms of the fewest number
of primitive APIs keeps us honest. Small, orthogonal APIs instead of
one monolithic thing help us drive consistency through the platform.
The less that's described as spec magic, the more we have to lean on
the generative composition of things web developers already know. For
instance, being able to subclass plain old JS types from DOM makes
it possible to define all of this stuff as though you'd just written
out something like:
function MyElementType(attrs) {
HTMLElement.call(this); // superclass ctor call, needed for
mixin properties
this.shadow = new ShadowRoot(this); // not magic, just new-ing
up this element's shadow root
// custom ctor behavior here
}
// delegate to the plain-old prototype chain.
MyElementType.prototype = Object.create(HTMLElement.prototype, { ... });
This might not look right to a spec author's eyes, but trust me, this
is how idiomatic JS subclassing of DOM *should* look. A version of
this component model built out of small primitives allows us to make
DOM work with it's environment, not against it, a principle that I
think should be a primary goal in all of our designs.
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
Re: XBL2 is dead.
On Thu, 22 Sep 2011 20:30:24 +0200, Dimitri Glazkov dglaz...@chromium.org 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/
Re: XBL2 is dead.
On Mon, Sep 26, 2011 at 12:28 AM, Anne van Kesteren ann...@opera.com wrote: On Thu, 22 Sep 2011 20:30:24 +0200, Dimitri Glazkov dglaz...@chromium.org 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: First Thoughts and Use Cases
On 12/15/10 10:53 PM, Maciej Stachowiak wrote: Are they really contradictory? Good question. ;) If they aren't, great. Personally, I think it would be a huge win if XBL2-based components could be more scalable than ones written in pure JavaScript using vanilla DOM calls. That way, XBL2 could enable new kinds of applications and reduce memory use of existing applications, rather than just providing convenience and bridging, as Tab seems to envision. Right; I think we're on the same page there. -Boris
Re: XBL2: First Thoughts and Use Cases
On Wed, Dec 15, 2010 at 10:53 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 15, 2010, at 11:14 AM, Boris Zbarsky wrote: At least in Gecko's case, we still use XBL1 in this way, and those design goals would apply to XBL2 from our point of view. It sounds like you have entirely different design goals, right? Sounds like it. OK, so given contradictory design goals, where do we go from here? Are they really contradictory? It sounds like Tab doesn't care about the use case where you want hundreds or thousands of instances without undue memory use, since he's looking to replace technologies that already don't support this. But it doesn't seem like these use cases are fundamentally incompatible. Personally, I think it would be a huge win if XBL2-based components could be more scalable than ones written in pure JavaScript using vanilla DOM calls. That way, XBL2 could enable new kinds of applications and reduce memory use of existing applications, rather than just providing convenience and bridging, as Tab seems to envision. FWIW, I think Tab agrees with you here (right, Tab? :). If you want to introduce new capabilities, might as well make them lean and mean. :DG Regards, Maciej
Re: XBL2: First Thoughts and Use Cases
On Tue, 14 Dec 2010, Boris Zbarsky wrote: So that in this case there would be a span element in the shadow DOM and a different span element in the flattened tree? As XBL2 is specced currently, the nodes in the explicit DOM and in the shadow DOM are the same nodes as in the final flattened tree, except that certain elements in the shadow tree don't appear in the final flattened tree (the root template and the insertion point content elements, in particular; also the element used for inheritance insertion). The example in this section, while initially rather perplexing, is probably the quickest way of visualising this: http://dev.w3.org/cvsweb/~checkout~/2006/xbl2/Overview.html?content-type=text/html;%20charset=utf-8#the-final-flattened-tree The key is just that each element in the final flattened tree is _also_ in a DOM somewhere. It's the same elements, they just have two sets of tree pointers (parent, children, siblings, etc). Selectors and events work in XBL2 as specified work on a carefully chosen hybrid of these trees. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XBL2: First Thoughts and Use Cases
On Wed, Dec 15, 2010 at 1:18 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 14 Dec 2010, Boris Zbarsky wrote: So that in this case there would be a span element in the shadow DOM and a different span element in the flattened tree? As XBL2 is specced currently, the nodes in the explicit DOM and in the shadow DOM are the same nodes as in the final flattened tree, except that certain elements in the shadow tree don't appear in the final flattened tree (the root template and the insertion point content elements, in particular; also the element used for inheritance insertion). The example in this section, while initially rather perplexing, is probably the quickest way of visualising this: http://dev.w3.org/cvsweb/~checkout~/2006/xbl2/Overview.html?content-type=text/html;%20charset=utf-8#the-final-flattened-tree The key is just that each element in the final flattened tree is _also_ in a DOM somewhere. It's the same elements, they just have two sets of tree pointers (parent, children, siblings, etc). Selectors and events work in XBL2 as specified work on a carefully chosen hybrid of these trees. As far as I know (and I've been in the center of the discussions over here, so hopefully I know pretty far), we agree with this design in XBL2. We have some nits to pick with precisely how shadows are constructed and flattened, but otherwise, yeah, basically the same deal. ~TJ
Re: XBL2: First Thoughts and Use Cases
On Dec 15, 2010, at 11:14 AM, Boris Zbarsky wrote: At least in Gecko's case, we still use XBL1 in this way, and those design goals would apply to XBL2 from our point of view. It sounds like you have entirely different design goals, right? Sounds like it. OK, so given contradictory design goals, where do we go from here? Are they really contradictory? It sounds like Tab doesn't care about the use case where you want hundreds or thousands of instances without undue memory use, since he's looking to replace technologies that already don't support this. But it doesn't seem like these use cases are fundamentally incompatible. Personally, I think it would be a huge win if XBL2-based components could be more scalable than ones written in pure JavaScript using vanilla DOM calls. That way, XBL2 could enable new kinds of applications and reduce memory use of existing applications, rather than just providing convenience and bridging, as Tab seems to envision. Regards, Maciej
Re: XBL2: First Thoughts and Use Cases
On Mon, Dec 13, 2010 at 10:33 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Dec 14, 2010 at 2:46 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Then there's no problem. You don't need the templates to be live to make child changes work. You just need to maintain some record that any normal-DOM elements which match * should appear as children of the shadow node #three in the final flattened tree. appendChild()'ing new elements to the x-fancycontainer will appropriately wire the elements into the shadow tree. This sort of selector-node map can be divined from the template and copied into a separate data structure, just like the actual shadow nodes can just be cloned out of the template into separate live DOM. No linkage back to the original template is required. Sure, but you also have to handle the includes attribute and the attributes attribute, so in fact you need to know a fair bit about the template to handle dynamic changes to the bound document. You might decide it's easier to just hold a reference to the template itself. If you indeed keep using includes/locked, attributes, and pseudo from the template, you end up with a semi-live template, where modifications to those values could affect the instances. I think you'd be better off with something like this: * Each bound instance holds data on how information (attribute values, nodes, CSS pseudo-elements matching, etc.) is forwarded from the bound element down to the the shadow subtree. * During the binding phase, this information is populated by reading corresponding attributes on the template. This approach allows: * Having a clean break between templates and instances. * Allowing bound behaviors manipulate their forwarding at will, without affecting the template. Here's a mental model I would present to Web developers: * The ability to influence a shadow DOM subtree from the outside is provided by the Shadow DOM Forwarding. * It's a list (array) of rules you associate with to the shadow DOM. * Each rule specifies how a node, an attribute, a text node, current language (and possibly direction), or a CSS pseudo selector is forwarded from the bound element to the elements in the shadow subtree. * You can create this set of rules imperatively during the binding phase, or * You can use templates to wire this up declaratively. * You can modify the rules at any time while the shadow subtree exists, but changes to rules are not retroactive. * In other words, what's been forwarded is not re-forwarded or affected in any way once the forwarding rule is changed or removed. WDYT? But yeah, we're agreeing. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: XBL2: First Thoughts and Use Cases
On Mon, Dec 13, 2010 at 10:33 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Dec 14, 2010 at 2:46 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Then there's no problem. You don't need the templates to be live to make child changes work. You just need to maintain some record that any normal-DOM elements which match * should appear as children of the shadow node #three in the final flattened tree. appendChild()'ing new elements to the x-fancycontainer will appropriately wire the elements into the shadow tree. This sort of selector-node map can be divined from the template and copied into a separate data structure, just like the actual shadow nodes can just be cloned out of the template into separate live DOM. No linkage back to the original template is required. Sure, but you also have to handle the includes attribute and the attributes attribute, so in fact you need to know a fair bit about the template to handle dynamic changes to the bound document. You might decide it's easier to just hold a reference to the template itself. But yeah, we're agreeing. Begging the question. ^_^ All of the information from the template can be duplicated in appropriate data structures on the element itself, like Dimitri explains. This allows us to treat the template solely as a stamp, used only at initialization and then thrown away. This gains us a few things. For one, you now have a simpler, more static model of how things work. There's no action-at-a-distance where changes to the template late in the page lifecycle can affect elements created during the original page parse; once an element is created with the appropriate information, it stays that way forever, unless the author explicitly monkeys around with it. For two, it naturally exposes all the magical template abilities to plain javascript, allowing everything to be manipulated by script after-the-fact, or even done entirely through script if that is, for whatever reason, easier than writing a template into a page. I think this is A Good Thing(tm). In general, I don't think we shouldn't be adding new magical features to the platform without ensuring they can be handled in script as well. Looking just at the problem itself, it's an open question as to whether it would be simpler to hold a reference to the template or just create the appropriate data structures out of the template. Likely, you'll be doing the latter in C++ anyway, so pushing them out into js as well feels pretty natural. But with the other added benefits that you get from making everything happen out in the open, I think the decision is a lot clearer. ~TJ
Re: XBL2: First Thoughts and Use Cases
On 12/14/10 10:25 AM, Tab Atkins Jr. wrote: Looking just at the problem itself, it's an open question as to whether it would be simpler to hold a reference to the template or just create the appropriate data structures out of the template. Likely, you'll be doing the latter in C++ anyway, so pushing them out into js as well feels pretty natural. Wait. Are we talking about exposing details about the template to JS somewhere? Where? And why? -Boris
Re: XBL2: First Thoughts and Use Cases
On 12/14/10 11:03 AM, Tab Atkins Jr. wrote: Script should be able to walk and mutate the shadow DOM for an element I'm not sure I agree, in fact. Why should script be able to do this? Sorta supporting this has been a constant source of problems in Mozilla' XBL1 implementation, and significantly increases the complexity of correct implementations (which Mozilla's XBL1 is not). Why is this needed? -Boris
Re: XBL2: First Thoughts and Use Cases
On Tue, Dec 14, 2010 at 11:14 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/14/10 11:03 AM, Tab Atkins Jr. wrote: Script should be able to walk and mutate the shadow DOM for an element I'm not sure I agree, in fact. Why should script be able to do this? Sorta supporting this has been a constant source of problems in Mozilla' XBL1 implementation, and significantly increases the complexity of correct implementations (which Mozilla's XBL1 is not). Why is this needed? This is interesting. Can you give an example? I am wondering if you and Tab are talking about the same thing. What sorts of problems? -Boris
Re: XBL2: First Thoughts and Use Cases
On Tue, Dec 14, 2010 at 11:23 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/14/10 11:16 AM, Dimitri Glazkov wrote: This is interesting. Can you give an example? I am wondering if you and Tab are talking about the same thing. What sorts of problems? The issues we've run into is that the shadow DOM tree can get mutated, which makes the actual DOM get out of sync with the data structures that represent insertion points (what I think XBL2 calls output ports) and the like). After this, adding normal DOM children to the bound element at best puts them in the wrong place in the shadow DOM; at worst we've had exploitable crash issues we had to fix. Hmm. I'm not well-versed enough in XBL1 to understand what all the difficulties are, but what we're envisioning is pretty simple and shouldn't lead to many problems. Given a template with some output ports, it's instantiated by cloning the shadow DOM and then setting up a map of selectors-shadow-nodes to represent the output ports. If you mutate the shadow DOM without paying attention to the outputPorts map, there are three possibilities for each port: 1. It points to a shadow node that wasn't mutated. No change. 2. It points to a shadow node that was moved. Everything currently attached to that shadow node, and any new elements added to the component which match the selector, will show up wherever the shadow node was moved to. 3. It points to a shadow node that was removed. Existing normal nodes which were pointing to that shadow node now don't show up at all in the final flattened tree (they lose their attachment, unless you ask for them to be reattached). New elements that get added and which match the selector can either ignore the selector (because we know that port is invalid) or just explicitly get put nowhere in the final flattened tree. Either option would be fine with me. Now if the shadow DOM can only be mutated by the binding itself, then it's possible to just avoid those problems in the binding script or restrict the things that script can do. But if the shadow DOM is exposed to the page the bound element is in, then the implementation needs to handle arbitrary mutations _somehow_, since you can't rely on things outside the binding playing nice with the binding. Or, of course, restrict what _that_ script can do with the shadow DOM, but that has more potential for weird breakage if the binding changes out from under the scripts that are trying to poke at it. All of the cases I outlined above can be run into when you're mutating a live template as well. Are there additional cases I'm missing that you have problems with? Are they perhaps a result of having both a mutable shadow and a live template? ~TJ
Re: XBL2: First Thoughts and Use Cases
On Mon, Dec 13, 2010 at 5:12 AM, Dimitri Glazkov dglaz...@google.comwrote: We definitely have use-cases that require the shadow DOM to be dynamically updated when an element that expands to a template instance has its subtree changed. Almost every application that combines dynamic DOM modification (e.g. editing) with templates needs this. So you do need to record how instances were created. Can you give a more specific example? Suppose I use XBL2 to define fancycontainer, a container with elaborate styling that I can't do with CSS alone. Changes to the children of a fancycontainer need to be reflected in the shadow DOM tree built for fancycontainer, otherwise dynamic changes in the presence of fancycontainer are just broken. For example, adding a child to container would need to find the associated template instance and insert the child into the right place in the instance. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: XBL2: First Thoughts and Use Cases
On Mon, Dec 13, 2010 at 5:16 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Mon, Dec 13, 2010 at 5:12 AM, Dimitri Glazkov dglaz...@google.com wrote: We definitely have use-cases that require the shadow DOM to be dynamically updated when an element that expands to a template instance has its subtree changed. Almost every application that combines dynamic DOM modification (e.g. editing) with templates needs this. So you do need to record how instances were created. Can you give a more specific example? Suppose I use XBL2 to define fancycontainer, a container with elaborate styling that I can't do with CSS alone. Changes to the children of a fancycontainer need to be reflected in the shadow DOM tree built for fancycontainer, otherwise dynamic changes in the presence of fancycontainer are just broken. For example, adding a child to container would need to find the associated template instance and insert the child into the right place in the instance. Ah, you're thinking about changes to the normal DOM. We're afraid of changes to the template. Different story. To be more specific, if we assume something like the following (handwavey syntax): element name=x-fancycontainer template div id=one div id=two div id=three content selector=* /div /div /div /template /element x-fancycontainer spanfoo/span /x-fancycontainer Then there's no problem. You don't need the templates to be live to make child changes work. You just need to maintain some record that any normal-DOM elements which match * should appear as children of the shadow node #three in the final flattened tree. appendChild()'ing new elements to the x-fancycontainer will appropriately wire the elements into the shadow tree. This sort of selector-node map can be divined from the template and copied into a separate data structure, just like the actual shadow nodes can just be cloned out of the template into separate live DOM. No linkage back to the original template is required. We're just afraid of, say, attaching event handlers or data-* attributes or whatever to shadow nodes, and then having the nodes get destroyed and recreated underneath us when the template changes. An element shouldn't destroy itself unless the author explicitly tells it to. XBL does try to be careful to destroy as little as possible, but it shouldn't destroy *anything* unless explicitly requested. ~TJ
Re: XBL2: First Thoughts and Use Cases
On 12/13/10 5:46 PM, Tab Atkins Jr. wrote: Ah, you're thinking about changes to the normal DOM. We're afraid of changes to the template. I think roc explicitly said that he thinks the XBL2 spec's section on this seems ... dispensable. I agree with him, for what it's worth. -Boris
Re: XBL2: First Thoughts and Use Cases
On Mon, Dec 13, 2010 at 9:11 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/13/10 5:46 PM, Tab Atkins Jr. wrote: Ah, you're thinking about changes to the normal DOM. We're afraid of changes to the template. I think roc explicitly said that he thinks the XBL2 spec's section on this seems ... dispensable. I agree with him, for what it's worth. Then we're all in agreement. ^_^ The rules that templates set up for assigning normal DOM nodes to places in the final flattened tree should stick around somehow even if we don't retain a reference to the template itself, so that adding children to the element afterwards has the same effect as parsing them in the original HTML. ~TJ
Re: XBL2: First Thoughts and Use Cases
On Tue, Dec 14, 2010 at 2:46 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: Then there's no problem. You don't need the templates to be live to make child changes work. You just need to maintain some record that any normal-DOM elements which match * should appear as children of the shadow node #three in the final flattened tree. appendChild()'ing new elements to the x-fancycontainer will appropriately wire the elements into the shadow tree. This sort of selector-node map can be divined from the template and copied into a separate data structure, just like the actual shadow nodes can just be cloned out of the template into separate live DOM. No linkage back to the original template is required. Sure, but you also have to handle the includes attribute and the attributes attribute, so in fact you need to know a fair bit about the template to handle dynamic changes to the bound document. You might decide it's easier to just hold a reference to the template itself. But yeah, we're agreeing. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: XBL2: First Thoughts and Use Cases
On Sat, Dec 11, 2010 at 1:04 PM, Dimitri Glazkov dglaz...@google.comwrote: 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. We definitely have use-cases that require the shadow DOM to be dynamically updated when an element that expands to a template instance has its subtree changed. Almost every application that combines dynamic DOM modification (e.g. editing) with templates needs this. So you do need to record how instances were created. I agree that handling dynamic updates to the bindings document is less well-motivated. It might be useful for a template editor. But a template editor could probably just unapply the entire bindings document, modify it, and reapply it. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: XBL2: First Thoughts and Use Cases
On Sun, Dec 12, 2010 at 12:52 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Dec 11, 2010 at 1:04 PM, Dimitri Glazkov dglaz...@google.com wrote: 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. We definitely have use-cases that require the shadow DOM to be dynamically updated when an element that expands to a template instance has its subtree changed. Almost every application that combines dynamic DOM modification (e.g. editing) with templates needs this. So you do need to record how instances were created. Can you give a more specific example? I agree that handling dynamic updates to the bindings document is less well-motivated. It might be useful for a template editor. But a template editor could probably just unapply the entire bindings document, modify it, and reapply it. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: XBL2
Do we have a sense yet regarding who supports XBL2 as in the 2007 Candidate version [CR] versus who supports the version Hixie recently published in [Draft]? Feedback from all (potential) implementers would be especially useful. Thinking aloud here, perhaps [Draft] could be positioned more like XBL1++ e.g. the XBL Note [Note] + bug fixes? (BTW, wow, didn't realize it's been almost 10 years since that Note was published.) -Art Barstow [CR] http://www.w3.org/TR/2007/CR-xbl-20070316/ [Draft] http://dev.w3.org/2006/xbl2/Overview.html [Note] http://www.w3.org/TR/2001/NOTE-xbl-20010223/ On 9/9/10 3:19 PM, ext Ian Hickson wrote: On Thu, 9 Sep 2010, Doug Schepers wrote: Arthur Barstow wrote (on 9/8/10 1:55 PM): On 9/4/10 6:36 AM, ext Doug Schepers wrote: To that end, could you provide a link to the requirements document, or if there isn't one, could you start one? FYI: when the Web Application Formats WG transitioned XBL2 from Last Call WD to CR (March 2007), the transition request included the following re requirements: [[ 5. Evidence that the document satisfies group requirements: The spec satisfies more requirements than those defined in the group's 10 February 2006 XBL Use Cases and Requirements document: http://lists.w3.org/Archives/Public/public-appformats/2006Feb/att-/XBL-UCs-and-Reqs-2006-02-10-DRAFT.html ]] Thanks for the pointer. But it seems that the requirements have changed, according to Hixie, so I'd like to understand better the motivation for the changes he made. I didn't examine the above list in depth, but apologies if I made it sound like the requirements had changed; they haven't. What changed is the context in which the spec is viewed -- one in which HTML has seen a resurgence as the recognised core platform, in which our understanding of latency and synchronicity implications in API designs is far improved, and in which we (or at least I) have a far more appreciation of the importance of incremental design in specifications, to lower the initial cost of implementations without closing doors on the features the language can support over the long term relative to the full vision of the spec. Some record of the implementer feedback he's received would probably suffice. People pointed out the above (in particular the possibilities that would be afforded by a closer integration with with HTML and XHTML, rather than having a separate vocabulary, and the benefits of the incremental approach). Hyatt and I then discussed how to apply these lessons to the XBL2 spec for an initial proposal, which is what I then edited. HTH,
Re: XBL2
On Fri, Sep 17, 2010 at 6:06 AM, Arthur Barstow art.bars...@nokia.com wrote: Do we have a sense yet regarding who supports XBL2 as in the 2007 Candidate version [CR] versus who supports the version Hixie recently published in [Draft]? Feedback from all (potential) implementers would be especially useful. Thinking aloud here, perhaps [Draft] could be positioned more like XBL1++ e.g. the XBL Note [Note] + bug fixes? (BTW, wow, didn't realize it's been almost 10 years since that Note was published.) I can't answer the question you asked directly, but I can shed some light on the reasoning behind this. A group of us engineers at Chrome have been brainstorming on ways to make the web platform easier to develop apps in. One of the ideas we came up with was conceptually very similar to what XBL2 does. We tried to avoid actually using XBL2, though, because we weren't happy with several of the design decisions in the spec. We then had some quick sanity/strategy meetings with other browser devs, particularly those who were involved or interested in XBL2. From that, we eventually decided that we probably shouldn't throw away the useful work that's already been done in XBL2, and instead see what we can do to work with it. The rest then unfolded as Ian described - with several people actually dusting the spec off and looking at in the light of modern practice, we realized that, while the core is basically sound, there's a lot of edge detail that doesn't make as much sense today as it did back when the spec was originally written. Thus, Ian cleaned it up and pushed the current revision out for comment. I still don't know if we (Chrome) are completely happy with the design, but it's much closer to our ideal, and we're experimenting with it so we can provide good feedback. ~TJ
Re: XBL2
On 9/4/10 6:36 AM, ext Doug Schepers wrote: To that end, could you provide a link to the requirements document, or if there isn't one, could you start one? FYI: when the Web Application Formats WG transitioned XBL2 from Last Call WD to CR (March 2007), the transition request included the following re requirements: [[ 5. Evidence that the document satisfies group requirements: The spec satisfies more requirements than those defined in the group's 10 February 2006 XBL Use Cases and Requirements document: http://lists.w3.org/Archives/Public/public-appformats/2006Feb/att-/XBL-UCs-and-Reqs-2006-02-10-DRAFT.html ]] -Art Barstow
Re: XBL2
Hi, Ian- Jonas Sicking wrote (on 9/3/10 7:24 PM): In general I would have appreciated at least being pinged about our requirements before these changes had been made. In the current state its unlikely that we'll be following the specification without modifications. On Thu, Sep 2, 2010 at 6:23 PM, Ian Hicksoni...@hixie.ch wrote: Since XBL2 wasn't getting much traction, I've taken an axe to the spec and made a number of changes to the spec based on some discussions with some browser vendors: Since Jonas (surprisingly) wasn't among the browser vendors you discussed this with, I'd be interested to know who you discussed it with, what precisely their feedback was, and the justifications and use cases they explained. I want XBL2 to succeed, so I think we should all get on the same page about it. To that end, could you provide a link to the requirements document, or if there isn't one, could you start one? Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: XBL2
Ian, It's good news that you have re-opened the XBL2 effort. We still don't have a reasonable component model for HTML, and XBL1 has proven its value for 10 + years in the Mozilla world. My first question is how to deal with the chicken-and-egg problem where developers won't touch it until 95% of deployed browser support this feature, and browser teams won't touch it until developers show strong interest. Is the idea that if the features goes into the HTML5 spec and one or two browsers implement it right away, then maybe the other browsers will follow? One other option for dealing with the chicken-and-egg problem is to make sure that the XBL2 spec is implementable in JavaScript. If a good JavaScript library existed and the browser teams agreed that native support for XBL2 will be offered as a native feature for HTML5 in the future, then developers could use XBL2 right away in current browsers and then find improved performance in future browsers. Jon PS - I still have a nervous tick from our efforts on sXBL From: Ian Hickson i...@hixie.ch To: public-webapps@w3.org Cc: hy...@apple.com Date: 09/02/2010 06:24 PM Subject:XBL2 Sent by:public-webapps-requ...@w3.org Since XBL2 wasn't getting much traction, I've taken an axe to the spec and made a number of changes to the spec based on some discussions with some browser vendors: http://dev.w3.org/2006/xbl2/Overview.html The main changes are simplification: I've dropped namespace support, made it part of HTML rather than its own language, dropped style and script in favour of HTML equivalents, dropped all the handler syntactic sugar (and redirected event forwarding to internal object instead), dropped preload, dropped mentions of XForms and XML Events, and so on. I've updated all the examples to use the new syntax, so if you're curious about the differences, comparing the examples in the spec above to those in the TR version is probably a good way to get an idea of what I did. If this ends up being more successful than the previous work on this specification, I'll have to merge it with the HTML spec to more properly define how it works. Right now it leaves a lot of the detail a bit vague (e.g. integration with the event loop, the parser, authoring conformance definitions, etc). If this happens, I don't yet know how much this will lend itself to being extracted back out into a separate module (for publication by this working group), versus being just published as a core part of the HTML spec, but I will be happy to update the group on this matter as it becomes clearer. I don't think the draft above would be suitable for publication as a TR/ draft, because of the aforementioned rough edges. I mostly just wanted to provide this for discussion, to see whether people considered this a move in a good direction or a significant step backwards. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' inline: graycol.gifinline: ecblank.gif
Re: XBL2
For what it's worth, it's a requirement for us to be able to use namespaces of some sorts since we're planning on implementing XUL using XBL2. There are however multiple ways we can do this and I'll need to look into which approach XUL developers prefer. I'm also not sure that we can do without style and script, but we can always add those as an extension to our implementation. In general I would have appreciated at least being pinged about our requirements before these changes had been made. In the current state its unlikely that we'll be following the specification without modifications. / Jonas On Thu, Sep 2, 2010 at 6:23 PM, Ian Hickson i...@hixie.ch wrote: Since XBL2 wasn't getting much traction, I've taken an axe to the spec and made a number of changes to the spec based on some discussions with some browser vendors: http://dev.w3.org/2006/xbl2/Overview.html The main changes are simplification: I've dropped namespace support, made it part of HTML rather than its own language, dropped style and script in favour of HTML equivalents, dropped all the handler syntactic sugar (and redirected event forwarding to internal object instead), dropped preload, dropped mentions of XForms and XML Events, and so on. I've updated all the examples to use the new syntax, so if you're curious about the differences, comparing the examples in the spec above to those in the TR version is probably a good way to get an idea of what I did. If this ends up being more successful than the previous work on this specification, I'll have to merge it with the HTML spec to more properly define how it works. Right now it leaves a lot of the detail a bit vague (e.g. integration with the event loop, the parser, authoring conformance definitions, etc). If this happens, I don't yet know how much this will lend itself to being extracted back out into a separate module (for publication by this working group), versus being just published as a core part of the HTML spec, but I will be happy to update the group on this matter as it becomes clearer. I don't think the draft above would be suitable for publication as a TR/ draft, because of the aforementioned rough edges. I mostly just wanted to provide this for discussion, to see whether people considered this a move in a good direction or a significant step backwards. -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XBL2
On Fri, 03 Sep 2010 19:24:03 +0200, Jonas Sicking jo...@sicking.cc wrote: For what it's worth, it's a requirement for us to be able to use namespaces of some sorts since we're planning on implementing XUL using XBL2. There are however multiple ways we can do this and I'll need to look into which approach XUL developers prefer. Why do you need namespaces for XUL? Isn't it all in the same namespace? I'm also not sure that we can do without style and script, but we can always add those as an extension to our implementation. They are simply no longer in the specification because HTML already has them. And since XBL is now an extension of HTML they did not need to be defined anymore. In general I would have appreciated at least being pinged about our requirements before these changes had been made. In the current state its unlikely that we'll be following the specification without modifications. That does seem like it would have been good. On the other hand, it's just a sketch and easily reverted/changed. -- Anne van Kesteren http://annevankesteren.nl/
Re: XBL2
On 9/3/10 1:37 PM, Anne van Kesteren wrote: On Fri, 03 Sep 2010 19:24:03 +0200, Jonas Sicking jo...@sicking.cc wrote: For what it's worth, it's a requirement for us to be able to use namespaces of some sorts since we're planning on implementing XUL using XBL2. There are however multiple ways we can do this and I'll need to look into which approach XUL developers prefer. Why do you need namespaces for XUL? Isn't it all in the same namespace? The relevant stylesheets are applied to all documents, because XUL can be used in any XML document, obviously. As a simple example, the binding used for xul:iframe shouldn't be used for html:iframe. -Boris
Re: XBL2
On Fri, 03 Sep 2010 19:45:00 +0200, Boris Zbarsky bzbar...@mit.edu wrote: The relevant stylesheets are applied to all documents, because XUL can be used in any XML document, obviously. As a simple example, the binding used for xul:iframe shouldn't be used for html:iframe. I see. Though XUL is not exposed to web content (anymore) so it seems this could be a private extension. E.g. moz--namespacemap or some such. -- Anne van Kesteren http://annevankesteren.nl/
Re: XBL2
On Fri, Sep 3, 2010 at 10:37 AM, Anne van Kesteren ann...@opera.com wrote: On Fri, 03 Sep 2010 19:24:03 +0200, Jonas Sicking jo...@sicking.cc wrote: For what it's worth, it's a requirement for us to be able to use namespaces of some sorts since we're planning on implementing XUL using XBL2. There are however multiple ways we can do this and I'll need to look into which approach XUL developers prefer. Why do you need namespaces for XUL? Isn't it all in the same namespace? There's often at least two namespaces involved, XUL and (X)HTML. Often times the HTML elements involved are form controls, but there might be other instances too. Here are a couple of examples: http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/textbox.xml#14 http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/textbox.xml#434 / Jonas
Re: XBL2
On 9/3/10 1:48 PM, Anne van Kesteren wrote: On Fri, 03 Sep 2010 19:45:00 +0200, Boris Zbarsky bzbar...@mit.edu wrote: The relevant stylesheets are applied to all documents, because XUL can be used in any XML document, obviously. As a simple example, the binding used for xul:iframe shouldn't be used for html:iframe. I see. Though XUL is not exposed to web content (anymore) so it seems this could be a private extension. E.g. moz--namespacemap or some such. XUL still appears in web content in various anonymous content (scrollbars, resizers, audio/video controls, etc, etc). Not exposed doesn't mean can't appear in that document. -Boris
Re: XBL2
On Fri, 3 Sep 2010, Jonas Sicking wrote: For what it's worth, it's a requirement for us to be able to use namespaces of some sorts since we're planning on implementing XUL using XBL2. There are however multiple ways we can do this and I'll need to look into which approach XUL developers prefer. The main idea behind the simplification is to lower the initial implementation cost, so that we can get some traction, and then we can add the features back in afterwards to get it back to where we were before. Namespace support can trivially be added back by just doing it the way the TR/ draft does it. The new spec is just a subset as far as that goes, to make it more likely to get implemented at all. I'm also not sure that we can do without style and script, but we can always add those as an extension to our implementation. With XBL in the HTML namespace, the HTML script and style serve the same purpose -- there's no net loss of features here (actually there's a net gain, because scoped stylesheets are slightly more powerful than the binding-specific sheets we had before). In general I would have appreciated at least being pinged about our requirements before these changes had been made. My e-mail was the ping. :-) There's nothing final about any of this, it's just a proposal, and anything in it can be easily reverted -- the new draft is literally just a few hours of going down the old one and axing some features that we can add later (i.e. slimming the spec down to the core of interdependent features). Sorry for not making that clearer in my earlier mail. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XBL2
Perhaps the spec should reference focusin/focusout instead of DOMFocusIn/DOMFocusOut ? http://dev.w3.org/2006/xbl2/Overview.html#the-focus-domfocusin-blur-and-domfocusou
Re: XBL2
I chatted with Ian on IRC. I misunderstood the layer at which XBL operates. XBL operates on already-parsed DOM trees, not on unparsed characters. Adam On Fri, Sep 3, 2010 at 2:17 PM, Adam Barth w...@adambarth.com wrote: From skimming the document, it wasn't immediately clear to me how to instantiate one of these object. From a security point of view, it would be desirable if the content that gets filled into the template where syntactically separate from the template itself. That would help mitigate cross-site scripting in much the same way that prepared SQL statements help mitigate SQL injection. Adam On Thu, Sep 2, 2010 at 6:23 PM, Ian Hickson i...@hixie.ch wrote: Since XBL2 wasn't getting much traction, I've taken an axe to the spec and made a number of changes to the spec based on some discussions with some browser vendors: http://dev.w3.org/2006/xbl2/Overview.html The main changes are simplification: I've dropped namespace support, made it part of HTML rather than its own language, dropped style and script in favour of HTML equivalents, dropped all the handler syntactic sugar (and redirected event forwarding to internal object instead), dropped preload, dropped mentions of XForms and XML Events, and so on. I've updated all the examples to use the new syntax, so if you're curious about the differences, comparing the examples in the spec above to those in the TR version is probably a good way to get an idea of what I did. If this ends up being more successful than the previous work on this specification, I'll have to merge it with the HTML spec to more properly define how it works. Right now it leaves a lot of the detail a bit vague (e.g. integration with the event loop, the parser, authoring conformance definitions, etc). If this happens, I don't yet know how much this will lend itself to being extracted back out into a separate module (for publication by this working group), versus being just published as a core part of the HTML spec, but I will be happy to update the group on this matter as it becomes clearer. I don't think the draft above would be suitable for publication as a TR/ draft, because of the aforementioned rough edges. I mostly just wanted to provide this for discussion, to see whether people considered this a move in a good direction or a significant step backwards. -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XBL2 Status?
Hi Art, Planning is in full speed for our XBL2 implementation. Development will start shortly. First design docs are available here: https://wiki.mozilla.org/XBL2 (not sure if the docs will be very understandable for non-gecko-developers. The target audience is XBL2 gecko implementors) / Jonas On Tue, Jun 2, 2009 at 8:57 AM, Arthur Barstowart.bars...@nokia.com wrote: On Jun 2, 2009, at 10:04 AM, ext StefanoC wrote: Hello! I'm wondering what's the roadmap for XBL2 support in FF - and any other browser, should you know. in this post: http://groups.google.com/group/mozilla.dev.tech.xbl/browse_thread/thread/961d8439d828dba1 Jonas Sicking mentioned he should start working on a XBL2 implementation after getting FF 3.1 out. Now, 3.1 became 3.5 (right?) and should be out soon, is XBL2 still next project to come for Jonas or somebody else? XBL2 specs are really nice and making XBL development so much nicer that with XBL1; we are currently playing with the http://code.google.com/p/xbl/ JS library, but a not-native implementation cannot provide the same performance (thinking about DOM changes and rebindings), nor a real shadow tree. Stefano - since my February 9 call for implementation status regarding XBL2: http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0361.html I have not received any new implementation information. All - if you have some new information re XBL2 implementations, please do share it with us. -Regards, Art Barstow thanks a lot for your feedback - and your work! Stefano Crosta Slice Factory ___ dev-tech-xbl mailing list dev-tech-...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-xbl
Re: XBL2 Status?
On Jun 2, 2009, at 10:04 AM, ext StefanoC wrote: Hello! I'm wondering what's the roadmap for XBL2 support in FF - and any other browser, should you know. in this post: http://groups.google.com/group/mozilla.dev.tech.xbl/browse_thread/ thread/961d8439d828dba1 Jonas Sicking mentioned he should start working on a XBL2 implementation after getting FF 3.1 out. Now, 3.1 became 3.5 (right?) and should be out soon, is XBL2 still next project to come for Jonas or somebody else? XBL2 specs are really nice and making XBL development so much nicer that with XBL1; we are currently playing with the http:// code.google.com/p/xbl/ JS library, but a not-native implementation cannot provide the same performance (thinking about DOM changes and rebindings), nor a real shadow tree. Stefano - since my February 9 call for implementation status regarding XBL2: http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ 0361.html I have not received any new implementation information. All - if you have some new information re XBL2 implementations, please do share it with us. -Regards, Art Barstow thanks a lot for your feedback - and your work! Stefano Crosta Slice Factory ___ dev-tech-xbl mailing list dev-tech-...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-xbl
