W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 11 Oct 2011 18:21:45 +0000 (UTC)
To: "Tab Atkins Jr." <jackalmage@gmail.com>
cc: Dimitri Glazkov <dglazkov@chromium.org>, Erik Arvidsson <arv@chromium.org>, Roland Steiner <rolandsteiner@google.com>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org, Dominic Cooney <dominicc@google.com>, Brian Kardell <bkardell@gmail.com>, Edward O'Connor <eoconnor@apple.com>
Message-ID: <Pine.LNX.4.64.1110111819290.27449@ps20323.dreamhostps.com>
On Tue, 11 Oct 2011, Tab Atkins Jr. wrote:
> On Tue, Oct 11, 2011 at 10:01 AM, Dimitri Glazkov <dglazkov@chromium.org> wrote:
> > On Mon, Oct 10, 2011 at 4:55 PM, Erik Arvidsson <arv@chromium.org> wrote:
> >> Splitting this up into two different things is great.
> >
> > The specific meaning of "splitting up" is where the things get
> > interesting. As far as I understand Hixie's idea, the component (which
> > exposes API) and the binding (which supplies shadow tree) aren't
> > coupled, which means they can share no internal state. For example,
> > you can't close over a set of event listeners that interact with
> > shadow DOM in a component method, because the listeners are applied
> > separately. I don't think that's workable.
> >
> > It seems to me that  we should have a way to create a shadow DOM
> > subtree inside of the component -- component's own tree (aka element
> > behavior attachment).
> >
> > Then, there could be a separate method to decorate a component with
> > one additional shadow tree using CSS (aka decorator behavior
> > attachment).
> >
> > The component model is explicitly interested in the former, not the latter.
> 
> Agreed.  Having the shadow tree entirely separate from the component
> is explicitly bad in many cases.  It prevents you from doing native
> implementation of many of the shadow-using HTML elements, like <video
> controls>, which need to hook the controls markup together with the
> scripting.

Indeed. I think it is important that we be able to style <video> with 
different types of interactive controls straight from CSS. That requires 
scripting, event handlers, scoped styles, and a shadow tree, and doesn't 
require defining a new API.

That's a different use case than e.g. being able to create an entirely new 
widget that happens to hook into form submission by piggy-backing on 
<input>, though. That might well want to expose a new API, while in 
addition wanting all the other things mentioned above. You wouldn't want 
to hook the new API from CSS, given the desire for stable APIs.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 11 October 2011 18:25:34 GMT

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