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 <mjs@apple.com> wrote:
>
> 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.

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
>
>
>
>
>
>

Received on Thursday, 30 June 2011 21:46:29 UTC