On Sat, Jul 9, 2011 at 1:42 PM, John J. Barton <[email protected]>wrote: [...]
> The Behavior Attachment Methods section is also super, but at the end I was > puzzled. I thought the Shadow DOM proposal only allowed one binding, and > thus it would exclude exactly the Decorator pattern we need to compose > multiple frameworks. I understand how you can solve the Dojo or Sencha or > jQuery problem better, but I don't see how you can solve the 'and' version. > IMHO there is a difference between altering the functionality of a component or decorating it. In the first case you need deep knowledge of the component's internas and thus cannot afford a random order in the inheritance chain. OTOH, in the decorator case you are explicitly not interested in internas, and have no control over order of application. I would therefore argue that inheritance (as, e.g., proposed by XBL2) is the wrong vehicle for decoration. For example, what if a decorator omits the <inherited> element in its tree? It seems to me it should be sufficient to only give a rough outline where the decoration should go, perhaps similar to CSS's ::before and ::after. Conversely, a decoration should _not_ be able to see, or even modify, anything inside the original component, nor use <inherited> or <content>. Cheers, - Roland
