W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Overview of behavior attachment as a general problem on the Web

From: Roland Steiner <rolandsteiner@chromium.org>
Date: Tue, 12 Jul 2011 13:55:19 +0900
Message-ID: <CACFPSpj8m9j1e37xAu2_EYTkV=r9577CpNQpXDDgfLTGhu464g@mail.gmail.com>
To: johnjbarton@johnjbarton.com
Cc: public-webapps@w3.org
On Sat, Jul 9, 2011 at 1:42 PM, John J. Barton
<johnjbarton@johnjbarton.com>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
Received on Tuesday, 12 July 2011 10:00:18 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:46 GMT