Re: Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)
On Fri, Jul 1, 2011 at 7:01 AM, Dimitri Glazkov wrote: > On Thu, Jun 30, 2011 at 2:50 PM, Boris Zbarsky wrote: > > On 6/30/11 5:45 PM, Dimitri Glazkov wrote: > >> > >> There's a very interesting distinction here. You don't "attach" > >> components to DOM elements. DOM elements _are_ components. The only > >> way to make a component is by sub-classing it from an existing > >> element. In this case, there is no distinction between native and > >> non-native implementations. If I sub-class from HTMLTextareaElement, I > >> can either reuse or override its shadow DOM. > > > > Back up. > > > > In this particular case, there may well be behavior attached to the > textarea > > that makes assumptions about the shadow DOM's structure. This seems like > a > > general statement about components. > > > > So if you override a shadow DOM, you better override the behavior too, > > right? > > Ouch. This one is tricky. I now see it. We can't really expect the > author to design to this level of decoupling. I don't think that's insurmountable. Since we don't do "aspect oriented components", a component's tree is always the same - either at the root, or attached to some element of a sub-class component. So the behavior can work on that tree without having to know whether it's used vanilla, or within a sub-class. Now, if the sub-class doesn't in fact use , that means its component tree in effect overrides the original component's tree. The original tree and it's attached behavior are just ignored and go hide in a corner. However, (later on) we may need then to also allow sub-classing the behavior, i.e., handing off of the interface of the original component to its sub-class. That in turn may have security implications - you probably don't want a component to be able to sub-class a file-upload control and hijack events, etc. Cheers, - Roland
Re: Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)
On 6/30/11 6:04 PM, Dimitri Glazkov wrote: Perhaps the right solution is to require and disallow access to shadow DOM tree if the sub-class is not overriding the subtree? I don't know. First, I'm not sure what problem we're solving. Second, I'm not sure what does Third, who is being disallowed access? -Boris
Re: Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)
Perhaps the right solution is to require and disallow access to shadow DOM tree if the sub-class is not overriding the subtree? :DG<
Re: Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)
On Thu, Jun 30, 2011 at 2:50 PM, Boris Zbarsky wrote: > On 6/30/11 5:45 PM, Dimitri Glazkov wrote: >> >> There's a very interesting distinction here. You don't "attach" >> components to DOM elements. DOM elements _are_ components. The only >> way to make a component is by sub-classing it from an existing >> element. In this case, there is no distinction between native and >> non-native implementations. If I sub-class from HTMLTextareaElement, I >> can either reuse or override its shadow DOM. > > Back up. > > In this particular case, there may well be behavior attached to the textarea > that makes assumptions about the shadow DOM's structure. This seems like a > general statement about components. > > So if you override a shadow DOM, you better override the behavior too, > right? Ouch. This one is tricky. I now see it. We can't really expect the author to design to this level of decoupling. > > If you reuse the shadow DOM, you either don't get access to it from your > component, or the old behavior still needs to be unhooked (since you can now > violate its invariants). > > > Does that match your mental model? Or are we talking about totally > different things somehow? No, you've highlighted a real flaw in my reply there. > > -Boris >
Re: Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)
On Thu, Jun 30, 2011 at 2:50 PM, Boris Zbarsky wrote: > On 6/30/11 5:45 PM, Dimitri Glazkov wrote: >> >> There's a very interesting distinction here. You don't "attach" >> components to DOM elements. DOM elements _are_ components. The only >> way to make a component is by sub-classing it from an existing >> element. In this case, there is no distinction between native and >> non-native implementations. If I sub-class from HTMLTextareaElement, I >> can either reuse or override its shadow DOM. > > Back up. > > In this particular case, there may well be behavior attached to the textarea > that makes assumptions about the shadow DOM's structure. This seems like a > general statement about components. > > So if you override a shadow DOM, you better override the behavior too, > right? Ouch. This one is tricky. I now see it. We can't really expect the author to design to this level of decoupling. > > If you reuse the shadow DOM, you either don't get access to it from your > component, or the old behavior still needs to be unhooked (since you can now > violate its invariants). > > > Does that match your mental model? Or are we talking about totally > different things somehow? No, you've highlighted a real flaw in my reply there. > > -Boris > >
Re: Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)
On 6/30/11 5:45 PM, Dimitri Glazkov wrote: There's a very interesting distinction here. You don't "attach" components to DOM elements. DOM elements _are_ components. The only way to make a component is by sub-classing it from an existing element. In this case, there is no distinction between native and non-native implementations. If I sub-class from HTMLTextareaElement, I can either reuse or override its shadow DOM. Back up. In this particular case, there may well be behavior attached to the textarea that makes assumptions about the shadow DOM's structure. This seems like a general statement about components. So if you override a shadow DOM, you better override the behavior too, right? If you reuse the shadow DOM, you either don't get access to it from your component, or the old behavior still needs to be unhooked (since you can now violate its invariants). Does that match your mental model? Or are we talking about totally different things somehow? -Boris
Re: Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)
On Thu, Jun 30, 2011 at 2:21 PM, Maciej Stachowiak wrote: > > On Jun 30, 2011, at 2:07 PM, Dimitri Glazkov wrote: > > On Thu, Jun 30, 2011 at 1:32 PM, Maciej Stachowiak wrote: > > On Jun 30, 2011, at 1:03 PM, Dimitri Glazkov wrote: > > > In the case of extending elements with native shadow DOM, you have to > use composition or have something like , where you nest > native shadow tree in your own. > > Why should a Web developer need to know or care which HTML elements have a > "native shadow DOM" to be able to attach components to them? Is this > actually something we want to specify? Would we specify exactly what the > native shadow DOM is for each element to make it possible to inherit them? > This seems like it would lock in a lot of implementation details of form > controls and so strikes me as a bad direction. There's a very interesting distinction here. You don't "attach" components to DOM elements. DOM elements _are_ components. The only way to make a component is by sub-classing it from an existing element. In this case, there is no distinction between native and non-native implementations. If I sub-class from HTMLTextareaElement, I can either reuse or override its shadow DOM. If I subclass from ProfileInformationWidget (which in itself is a subclass of HTMLDivElement), I can do exactly the same two things. > > In the case case of attaching multiple bindings -- you just can't. > That's the difference between inheritance and mixins :) > > OK, so your proposal would be unable to address my microformat decorator > sample use case at all, no matter how it was modified. It would also not be > able to handle both a Web page and a browser extension attaching behavior to > the same element via components at the same time. Those seem like major > limitations. Yes, they are. I think it's worth considering whether component model should be aiming to address these cases, or a simple mutation-event-style spec is enough to address them. Just like we want the component model to be a useful functionality, covering a range of use cases, we don't want it to become the "and-the-kitchen-sink" spec that's XBL2. > > To make further progress, I would like to concentrate on resolving > > these two issues: > > 1) should we use object inheritance (one shadow subtree) or mixins > > (multiple shadow subtrees)? > > I think it's possible to partially table this issue. If mixing are required, > then raw access to the shadow tree is not viable. But using inheritance / > single binding is possible with either proposal. > > I think that changes a lot of nomenclature though, right? You don't > have "bindings" with inheritance. It's just you or your sub-class. > Also, element.bindComponent doesn't make much sense if you can only > inherit the relationship. > > You can call it attachComponent if you want. Or setComponent. I think we can > make the way of attaching to a native element different from the way you > inherit from another component. I don't really see how "element.shadow = > whatever" is a better fit for inheritance than > "element.bindComponent(whatever)". > Still, I think this is diving too far into the details where we are not even > clear on the use cases. > > > 2) do we need webkitShadow or similar accessor to shadow subtree(s)? > > This question is a helpful one. I haven't seen any reason articulated for > why such an accessor is required. The fact that it's not present in other > similar technologies seems like proof that it is not required. > > Yes, I will work on use cases. Though this concept is certainly > present in other technologies. Just take a look at Silverlight and its > LogicalTreeHelper > (http://msdn.microsoft.com/en-us/library/ms753391.aspx). > > Is there anything that Silverlight can do that Mozilla's XBL, sXBL, and HTC > can't, as a result of this choice? > > > > > I think these are all resolved by supplying use cases and rationale. Right? > > If so, I think we need a real list of use cases to be addressed. The one > provided seems to bear no relationship to your original proposal (though I > believe my rough sketch satisfies more of them as-is and is more obviously > extensible to satisfying more of them). > > Did you mean the hovercard? I bet I can write a pretty simple bit of > code that would usefully consume the API from my proposal. > > I meant the wiki list of use cases. > For concrete use cases, the most valuable kind would be examples from real > Web sites, including the URL of the original, a description of how it works, > and the code it uses to make that happen. Made-up examples can be > illustrative but won't help us sort out questions of "what are Web authors > really doing and what do they need?" which seem to come up a lot in this > discussion. Yep. That's a volume of work, so please be patient with me :) > Regards, > Maciej > > > > > >
Re: Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)
On Jun 30, 2011, at 2:07 PM, Dimitri Glazkov wrote: > On Thu, Jun 30, 2011 at 1:32 PM, Maciej Stachowiak wrote: >> >> On Jun 30, 2011, at 1:03 PM, Dimitri Glazkov wrote: >> > > In the case of extending elements with native shadow DOM, you have to > use composition or have something like , where you nest > native shadow tree in your own. Why should a Web developer need to know or care which HTML elements have a "native shadow DOM" to be able to attach components to them? Is this actually something we want to specify? Would we specify exactly what the native shadow DOM is for each element to make it possible to inherit them? This seems like it would lock in a lot of implementation details of form controls and so strikes me as a bad direction. > > In the case case of attaching multiple bindings -- you just can't. > That's the difference between inheritance and mixins :) OK, so your proposal would be unable to address my microformat decorator sample use case at all, no matter how it was modified. It would also not be able to handle both a Web page and a browser extension attaching behavior to the same element via components at the same time. Those seem like major limitations. >>> >>> To make further progress, I would like to concentrate on resolving >>> these two issues: >>> >>> 1) should we use object inheritance (one shadow subtree) or mixins >>> (multiple shadow subtrees)? >> >> I think it's possible to partially table this issue. If mixing are required, >> then raw access to the shadow tree is not viable. But using inheritance / >> single binding is possible with either proposal. > > I think that changes a lot of nomenclature though, right? You don't > have "bindings" with inheritance. It's just you or your sub-class. > Also, element.bindComponent doesn't make much sense if you can only > inherit the relationship. You can call it attachComponent if you want. Or setComponent. I think we can make the way of attaching to a native element different from the way you inherit from another component. I don't really see how "element.shadow = whatever" is a better fit for inheritance than "element.bindComponent(whatever)". Still, I think this is diving too far into the details where we are not even clear on the use cases. > >> >>> 2) do we need webkitShadow or similar accessor to shadow subtree(s)? >> >> This question is a helpful one. I haven't seen any reason articulated for >> why such an accessor is required. The fact that it's not present in other >> similar technologies seems like proof that it is not required. > > Yes, I will work on use cases. Though this concept is certainly > present in other technologies. Just take a look at Silverlight and its > LogicalTreeHelper > (http://msdn.microsoft.com/en-us/library/ms753391.aspx). Is there anything that Silverlight can do that Mozilla's XBL, sXBL, and HTC can't, as a result of this choice? > >> >> >>> >>> I think these are all resolved by supplying use cases and rationale. Right? >> >> If so, I think we need a real list of use cases to be addressed. The one >> provided seems to bear no relationship to your original proposal (though I >> believe my rough sketch satisfies more of them as-is and is more obviously >> extensible to satisfying more of them). > > Did you mean the hovercard? I bet I can write a pretty simple bit of > code that would usefully consume the API from my proposal. I meant the wiki list of use cases. For concrete use cases, the most valuable kind would be examples from real Web sites, including the URL of the original, a description of how it works, and the code it uses to make that happen. Made-up examples can be illustrative but won't help us sort out questions of "what are Web authors really doing and what do they need?" which seem to come up a lot in this discussion. Regards, Maciej
Re: Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)
On Thu, Jun 30, 2011 at 1:32 PM, Maciej Stachowiak wrote: > > On Jun 30, 2011, at 1:03 PM, Dimitri Glazkov wrote: > >> Maciej, as promised on #whatwg, here's a more thorough review of your >> proposal. I am in agreement in the first parts of your email, so I am >> going to skip those. >> >>> =3D=3D Are there other limitations created by the lack of encapsulation= ? =3D=3D >>> >>> My understanding is yes, there are some serious limitations: >>> >>> (1) It won't be possible (according to Dmitri) to attach a binding to a= n object that has a native shadow DOM in the implementation (e.g. form cont= rols). That's because there can only be one shadow root, and form controls = have already used it internally and made it private. This seems like a huge= limitation. The ability to attach bindings/components to form elements is = potentially a huge win - authors can use the correct semantic element inste= ad of div soup, but still have the total control over look and feel from a = custom script-based implementation. >>> >>> (2) Attaching more than one binding with this approach is a huge hazard= . You'll either inadvertently blow away the previous, or won't be able to a= ttach more than one, or if your coding is sloppy, may end up mangling both = of them. >>> >>> I think these two limitations are intrinsic to the approach, not incide= ntal. >> >> I would like to frame this problem as "multiple-vs-single shadow tree >> per element". >> >> Encapsulation is achievable with single shadow tree per element by >> removing access via webkitShadow. You can discover whether a tree >> exists (by the fact that an exception is thrown when you attempt to >> set webkitShadow), but that's hardly breaking encapsulation. >> >> The issues you've described above are indeed real -- if you view >> adding new behavior to elements a process of "binding", that is >> something added to existing elements, possibly more than once. If we >> decide that this the correct way to view attaching behavior, we >> definitely need to fix this. >> >> I attempted to articulate a different view here >> http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0941.html. >> Here, adding new behavior to elements means creating a sub-class of an >> element. This should be a very familiar programming concept, probably >> more understood than the decorator or mixin-like "binding" approach. > > How would your "subclass" idea resolve the two problems above? In the case of extending elements with native shadow DOM, you have to use composition or have something like , where you nest native shadow tree in your own. In the case case of attaching multiple bindings -- you just can't. That's the difference between inheritance and mixins :) > >> >> For the key use case of UI widgets, sub-classing is very natural. I >> take a div, and sub-class it into a hovercard >> (http://blog.twitter.com/2010/02/flying-around-with-hovercards.html). >> I rarely bind a hovercard behavior to some random element -- not just >> because I typically don't need to, but also because I expect a certain >> behavior from the base element from which to build on. Binding a >> hovercard to an element that doesn't display its children (like img or >> input) is useless, since I want to append child nodes to display that >> user info. >> >> I could then make superhovercard by extending the hovercard. The >> single shadow DOM tree works perfectly in this case, because you >> either: >> 1) inherit the tree of the subclass and add behavior; >> 2) override it. >> >> In cases where you truly need a decorator, use composition. Once we >> have the basics going, we may contemplate concepts like >> (http://dev.w3.org/2006/xbl2/#the-inherited-element) to make >> sub-classing more convenient. >> >> Sub-classing as a programming model is well-understood, and easy to gras= p. >> >> On the other hand, the decorators are less known and certainly carry >> hidden pains. How do you resolve API conflicts (two bindings have two >> properties/functions by the same name)? As a developer, how do you >> ensure a stable order of bindings (bindings competing for the z-index >> and depending on the order of they are initialized, for example)? > > I think decorators have valid use cases. For example, let's say I want to= make a component that extracts microformat or microdata marked up content = from an element and present hover UI to allow handy access to it. For examp= le, it could extract addresses and offer map links. I would want this to wo= rk on any element, even if the element already has an active behavior imple= mented by a component. I should not have to "subclass" every type of elemen= t I may want to apply this to. It's especially problematic if you have to "= subclass" even different kinds of built in elements. Do I need separate sub= classes for div, span, address, section p, and whatever other kind of eleme= nt I imagine this applying to? That doesn't seem so great. > > You are correct that figuring out
Re: Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)
On Jun 30, 2011, at 1:03 PM, Dimitri Glazkov wrote: > Maciej, as promised on #whatwg, here's a more thorough review of your > proposal. I am in agreement in the first parts of your email, so I am > going to skip those. > >> == Are there other limitations created by the lack of encapsulation? == >> >> My understanding is yes, there are some serious limitations: >> >> (1) It won't be possible (according to Dmitri) to attach a binding to an >> object that has a native shadow DOM in the implementation (e.g. form >> controls). That's because there can only be one shadow root, and form >> controls have already used it internally and made it private. This seems >> like a huge limitation. The ability to attach bindings/components to form >> elements is potentially a huge win - authors can use the correct semantic >> element instead of div soup, but still have the total control over look and >> feel from a custom script-based implementation. >> >> (2) Attaching more than one binding with this approach is a huge hazard. >> You'll either inadvertently blow away the previous, or won't be able to >> attach more than one, or if your coding is sloppy, may end up mangling both >> of them. >> >> I think these two limitations are intrinsic to the approach, not incidental. > > I would like to frame this problem as "multiple-vs-single shadow tree > per element". > > Encapsulation is achievable with single shadow tree per element by > removing access via webkitShadow. You can discover whether a tree > exists (by the fact that an exception is thrown when you attempt to > set webkitShadow), but that's hardly breaking encapsulation. > > The issues you've described above are indeed real -- if you view > adding new behavior to elements a process of "binding", that is > something added to existing elements, possibly more than once. If we > decide that this the correct way to view attaching behavior, we > definitely need to fix this. > > I attempted to articulate a different view here > http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0941.html. > Here, adding new behavior to elements means creating a sub-class of an > element. This should be a very familiar programming concept, probably > more understood than the decorator or mixin-like "binding" approach. How would your "subclass" idea resolve the two problems above? > > For the key use case of UI widgets, sub-classing is very natural. I > take a div, and sub-class it into a hovercard > (http://blog.twitter.com/2010/02/flying-around-with-hovercards.html). > I rarely bind a hovercard behavior to some random element -- not just > because I typically don't need to, but also because I expect a certain > behavior from the base element from which to build on. Binding a > hovercard to an element that doesn't display its children (like img or > input) is useless, since I want to append child nodes to display that > user info. > > I could then make superhovercard by extending the hovercard. The > single shadow DOM tree works perfectly in this case, because you > either: > 1) inherit the tree of the subclass and add behavior; > 2) override it. > > In cases where you truly need a decorator, use composition. Once we > have the basics going, we may contemplate concepts like > (http://dev.w3.org/2006/xbl2/#the-inherited-element) to make > sub-classing more convenient. > > Sub-classing as a programming model is well-understood, and easy to grasp. > > On the other hand, the decorators are less known and certainly carry > hidden pains. How do you resolve API conflicts (two bindings have two > properties/functions by the same name)? As a developer, how do you > ensure a stable order of bindings (bindings competing for the z-index > and depending on the order of they are initialized, for example)? I think decorators have valid use cases. For example, let's say I want to make a component that extracts microformat or microdata marked up content from an element and present hover UI to allow handy access to it. For example, it could extract addresses and offer map links. I would want this to work on any element, even if the element already has an active behavior implemented by a component. I should not have to "subclass" every type of element I may want to apply this to. It's especially problematic if you have to "subclass" even different kinds of built in elements. Do I need separate subclasses for div, span, address, section p, and whatever other kind of element I imagine this applying to? That doesn't seem so great. You are correct that figuring out how multiple bindings work is tricky. But even if we choose not to do it, making components truly encapsulated does not make it any harder to have a one-binding-only model with no inheritance. >> Notice that this scheme is not significantly more complex to use, spec or >> implement than the shadow/shadowHost proposal. And it provides a number of >> advantages: >> >> A) True encapsulation is possib
Re: Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)
Maciej, as promised on #whatwg, here's a more thorough review of your
proposal. I am in agreement in the first parts of your email, so I am
going to skip those.
> == Are there other limitations created by the lack of encapsulation? ==
>
> My understanding is yes, there are some serious limitations:
>
> (1) It won't be possible (according to Dmitri) to attach a binding to an
> object that has a native shadow DOM in the implementation (e.g. form
> controls). That's because there can only be one shadow root, and form
> controls have already used it internally and made it private. This seems like
> a huge limitation. The ability to attach bindings/components to form elements
> is potentially a huge win - authors can use the correct semantic element
> instead of div soup, but still have the total control over look and feel from
> a custom script-based implementation.
>
> (2) Attaching more than one binding with this approach is a huge hazard.
> You'll either inadvertently blow away the previous, or won't be able to
> attach more than one, or if your coding is sloppy, may end up mangling both
> of them.
>
> I think these two limitations are intrinsic to the approach, not incidental.
I would like to frame this problem as "multiple-vs-single shadow tree
per element".
Encapsulation is achievable with single shadow tree per element by
removing access via webkitShadow. You can discover whether a tree
exists (by the fact that an exception is thrown when you attempt to
set webkitShadow), but that's hardly breaking encapsulation.
The issues you've described above are indeed real -- if you view
adding new behavior to elements a process of "binding", that is
something added to existing elements, possibly more than once. If we
decide that this the correct way to view attaching behavior, we
definitely need to fix this.
I attempted to articulate a different view here
http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0941.html.
Here, adding new behavior to elements means creating a sub-class of an
element. This should be a very familiar programming concept, probably
more understood than the decorator or mixin-like "binding" approach.
For the key use case of UI widgets, sub-classing is very natural. I
take a div, and sub-class it into a hovercard
(http://blog.twitter.com/2010/02/flying-around-with-hovercards.html).
I rarely bind a hovercard behavior to some random element -- not just
because I typically don't need to, but also because I expect a certain
behavior from the base element from which to build on. Binding a
hovercard to an element that doesn't display its children (like img or
input) is useless, since I want to append child nodes to display that
user info.
I could then make superhovercard by extending the hovercard. The
single shadow DOM tree works perfectly in this case, because you
either:
1) inherit the tree of the subclass and add behavior;
2) override it.
In cases where you truly need a decorator, use composition. Once we
have the basics going, we may contemplate concepts like
(http://dev.w3.org/2006/xbl2/#the-inherited-element) to make
sub-classing more convenient.
Sub-classing as a programming model is well-understood, and easy to grasp.
On the other hand, the decorators are less known and certainly carry
hidden pains. How do you resolve API conflicts (two bindings have two
properties/functions by the same name)? As a developer, how do you
ensure a stable order of bindings (bindings competing for the z-index
and depending on the order of they are initialized, for example)?
>
>
> == OK Mr. Fancypants, do you have a better proposal? ==
>
> I haven't thought deeply about this, but here's a sketch of a component model
> that is just as trivial to use and implement as what is proposed, yet
> provides true encapsulation. It sticks with the idea that the only way to
> create a component DOM is programmatically. But it immediately provides some
> advantages that I'll expand on after throwing out the IDL:
>
> interface Component {
> // deliberately left blank
> }
>
> interface TreeScope : Node
> {
> readonly TreeScope parentTreeScope;
> Element getElementById (in DOMString elementId);
> }
>
> interface BindingRoot : TreeScope {
> attribute bool applyAuthorSheets;
> readonly attribute Element bindingHost;
> };
>
> [Callback]
> interface ComponentInitializer {
> void initialize(in BindingRoot binding);
> };
>
> partial interface Document {
> Component createComponent(in Node template, in ComponentInitializer
> initializer);
> };
>
> partial interface Element {
> bindComponent(in Component component);
> unbindComponent(in Component component);
> }
>
> The way this works is as follows:
>
> (1) The component provider creates a DOM tree that provides templates for
> bindings that instantiate that component.
> (2) The component provider also makes an init function (represented above as
> a callback interface) which is called whenever an instance of the comp
Re: Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)
On Jun 30, 2011, at 10:57 AM, Dimitri Glazkov wrote: > Hi Maciej! > > First off, I really appreciate your willingness to get into the mix of > things. It's a hard problem and I welcome any help we can get to solve > it. > > I also very much liked your outline of encapsulation and I would like > to start using the terminology you introduced. > > I am even flattered to see the proposal you outlined, because it's > similar to the one we originally considered as part of the first > iteration of the API > (https://raw.github.com/dglazkov/component-model/cbb28714ada37ddbaf49b3b2b24569b5b5e4ccb9/dom.html) > or even earlier versions > (https://github.com/dglazkov/component-model/blob/ed6011596a0213fc1eb9f4a12544bb7ddd4f4894/api-idl.txt) > > We did remove them however, and opted for the simplest possible API, > which effectively only exposes the shadow DOM part of the component > model (see my breakdown here > http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1345.html). > > One of the things to keep in mind is that the proposal outlined in > http://dglazkov.github.com/component-model/dom.html is by no means a > complete component model API. It's just the smallest subset that can > already be useful in addressing some of the use cases listed in > http://wiki.whatwg.org/wiki/Component_Model_Use_Cases. > > It seem obvious that it is better to have few small, closely related > useful bits that could be combined into a bigger picture rather than > one large monolithic feature that can't be teased apart. The problem is that some pervasive properties (encapsulation, security, etc) can't be added after the fact to a system that doesn't have them designed in. > > As for addressing encapsulation concerns, one of the simplest things > we could is to introduce a flag on the ShadowRoot (we can discuss the > default value), which if set, prohibits access to it with the > element.shadow property. Why is that better than my proposal? I believe all the benefits I listed for my proposal over yours still apply to this new proposal. Can you either rebut those stated benefits, or tell me what benefits this version has over mine? Regards, Maciej
Re: Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)
Hi Maciej! First off, I really appreciate your willingness to get into the mix of things. It's a hard problem and I welcome any help we can get to solve it. I also very much liked your outline of encapsulation and I would like to start using the terminology you introduced. I am even flattered to see the proposal you outlined, because it's similar to the one we originally considered as part of the first iteration of the API (https://raw.github.com/dglazkov/component-model/cbb28714ada37ddbaf49b3b2b24569b5b5e4ccb9/dom.html) or even earlier versions (https://github.com/dglazkov/component-model/blob/ed6011596a0213fc1eb9f4a12544bb7ddd4f4894/api-idl.txt) We did remove them however, and opted for the simplest possible API, which effectively only exposes the shadow DOM part of the component model (see my breakdown here http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1345.html). One of the things to keep in mind is that the proposal outlined in http://dglazkov.github.com/component-model/dom.html is by no means a complete component model API. It's just the smallest subset that can already be useful in addressing some of the use cases listed in http://wiki.whatwg.org/wiki/Component_Model_Use_Cases. It seem obvious that it is better to have few small, closely related useful bits that could be combined into a bigger picture rather than one large monolithic feature that can't be teased apart. As for addressing encapsulation concerns, one of the simplest things we could is to introduce a flag on the ShadowRoot (we can discuss the default value), which if set, prohibits access to it with the element.shadow property. :DG< On Wed, Jun 29, 2011 at 9:03 PM, Maciej Stachowiak wrote: > > > I am not a fan of this API because I don't think it provides sufficient > encapsulation. The words "encapsulation" and "isolation" have been used in > different ways in this discussion, so I will start with an outline of > different possible senses of "encapsulation" that could apply here. > > == Different kinds of "encapsulation" == > > 1) Encapsulation against accidental exposure - DOM Nodes from the shadow tree > are not leaked via pre-existing generic APIs - for example, events flowing > out of a shadow tree don't expose shadow nodes as the event target, > > 2) Encapsulation against deliberate access - no API is provided which lets > code outside the component poke at the shadow DOM. Only internals that the > component chooses to expose are exposed. > > 3) Inverse encapsulation - no API is provided which lets code inside the > component see content from the page embedding it (this would have the effect > of something like sandboxed iframes or Caja). > > 4) Isolation for security purposes - it is strongly guaranteed that there is > no way for code outside the component to violate its confidentiality or > integrity. > > 5) Inverse isolation for security purposes - it is strongly guaranteed that > there is no way for code inside the component to violate the confidentiality > or integrity of the embedding page. > > > I believe the proposed API has property 1, but not properties 2, 3 or 4. The > webkitShadow IDL attribute violates property #2, I assume it is obvious why > the others do not hold. > > I am not greatly interested in 3 or 4, but I believe #2 is important for a > component model. > > > == Why is encapsulation (type 2) important for components? == > > I believe type 2 encapsulation is important, because it allows components to > be more maintainable, reusable and robust. Type 1 encapsulation keeps > components from breaking the containing page accidentally, and can keep the > containing page from breaking the component. If the shadow DOM is exposed, > then you have the following risks: > > (1) A page using the component starts poking at the shadow DOM because it can > - perhaps in a rarely used code path. > (2) The component is updated, unaware that the page is poking at its guts. > (3) Page adopts new version of component. > (4) Page breaks. > (5) Page author blames component author or rolls back to old version. > > This is not good. Information hiding and hiding of implementation details are > key aspects of encapsulation, and are good software engineering practice. > Dmitri has argued that pages today do a version of components with no > encapsulation whatsoever, because many are written by monolithic teams that > control the whole stack. This does not strike me as a good argument. > Encapsulation can help teams maintain internal interfaces as they grow, and > can improve reusability of components to the point where maybe sites aren't > quite so monolithically developed. > > Furthermore, consider what has happened with JavaScript. While the DOM has no > good mechanism for encapsulation, JavaScript offers a choice. Object > properties are not very encapsulated at all, by default anyone can read or > write. But local variables in a closure are fully encapsulated. It's more and
Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)
I am not a fan of this API because I don't think it provides sufficient encapsulation. The words "encapsulation" and "isolation" have been used in different ways in this discussion, so I will start with an outline of different possible senses of "encapsulation" that could apply here. == Different kinds of "encapsulation" == 1) Encapsulation against accidental exposure - DOM Nodes from the shadow tree are not leaked via pre-existing generic APIs - for example, events flowing out of a shadow tree don't expose shadow nodes as the event target, 2) Encapsulation against deliberate access - no API is provided which lets code outside the component poke at the shadow DOM. Only internals that the component chooses to expose are exposed. 3) Inverse encapsulation - no API is provided which lets code inside the component see content from the page embedding it (this would have the effect of something like sandboxed iframes or Caja). 4) Isolation for security purposes - it is strongly guaranteed that there is no way for code outside the component to violate its confidentiality or integrity. 5) Inverse isolation for security purposes - it is strongly guaranteed that there is no way for code inside the component to violate the confidentiality or integrity of the embedding page. I believe the proposed API has property 1, but not properties 2, 3 or 4. The webkitShadow IDL attribute violates property #2, I assume it is obvious why the others do not hold. I am not greatly interested in 3 or 4, but I believe #2 is important for a component model. == Why is encapsulation (type 2) important for components? == I believe type 2 encapsulation is important, because it allows components to be more maintainable, reusable and robust. Type 1 encapsulation keeps components from breaking the containing page accidentally, and can keep the containing page from breaking the component. If the shadow DOM is exposed, then you have the following risks: (1) A page using the component starts poking at the shadow DOM because it can - perhaps in a rarely used code path. (2) The component is updated, unaware that the page is poking at its guts. (3) Page adopts new version of component. (4) Page breaks. (5) Page author blames component author or rolls back to old version. This is not good. Information hiding and hiding of implementation details are key aspects of encapsulation, and are good software engineering practice. Dmitri has argued that pages today do a version of components with no encapsulation whatsoever, because many are written by monolithic teams that control the whole stack. This does not strike me as a good argument. Encapsulation can help teams maintain internal interfaces as they grow, and can improve reusability of components to the point where maybe sites aren't quite so monolithically developed. Furthermore, consider what has happened with JavaScript. While the DOM has no good mechanism for encapsulation, JavaScript offers a choice. Object properties are not very encapsulated at all, by default anyone can read or write. But local variables in a closure are fully encapsulated. It's more and more consider a good practice in JavaScript to build objects based on closures to hide implementation details. This is the case even though the closure approach is more awkward to code, and may hurt performance. For ECMAScript Harmony, a form of object that provides true encapsulation is being considered. I don't want us to make the same mistake with DOM components that in retrospect I think was made with JavaScript objects. Let's provide good encapsulation out of the gate. And it's important to keep in mind here that this form of encapsulation is *not* meant as a security measure; it is meant as a technique for robustness and good software engineering. == Are there use cases for breaking type 2 encapsulation against the will of the component? == I'm not aware of any. I asked Dmitri to explain these uses cases on IRC and he didn't have any specific ones in mind, just said that exposing the shadow DOM directly is the simplest thing that could possibly work and so is easy to prototype and implement. I think there are other starter approaches that are easy to implement but provide stronger encapsulation. == Are there other limitations created by the lack of encapsulation? == My understanding is yes, there are some serious limitations: (1) It won't be possible (according to Dmitri) to attach a binding to an object that has a native shadow DOM in the implementation (e.g. form controls). That's because there can only be one shadow root, and form controls have already used it internally and made it private. This seems like a huge limitation. The ability to attach bindings/components to form elements is potentially a huge win - authors can use the correct semantic element instead of div soup, but still have the total control over look and feel from a custom script-based impleme
