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 <mjs@apple.com> 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 <inherited>, 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