Re: [Component Model] Decorator Challenges
On Tue, Nov 29, 2011 at 11:15, Roland Steiner wrote: > If we are considering worker-like decorators, then AFAICT it doesn't have > to be an actual worker - it's enough if it's a separate object that can be > attached and detached. As long as we define the interfaces nicely, FWIW > this object could even hold internal state, etc. > I should point out that we already have exactly such an interface in the form of the host element <-> ShadowRoot boundary! Essentially, one could view Decorators as shadow DOM where scripts are only allowed in the shadow side. - Roland
Re: [Component Model] Decorator Challenges
On Tue, Nov 29, 2011 at 02:18, Dimitri Glazkov wrote: > On Thu, Nov 24, 2011 at 6:40 PM, Roland Steiner > wrote:> (FWIW, I'm also not convinced that > it'd have to have high performance > > overhead - in the best case it could be as little as just one more level > of > > indirection.) > > The startup time of a worker is non-trivial. Similarly, the shutdown > won't be trivial. And the memory footprint of a worker isn't trivial > either. If we're aiming for decorators to be fast and lean, we'll have > to think of ways around those costs If we are considering worker-like decorators, then AFAICT it doesn't have to be an actual worker - it's enough if it's a separate object that can be attached and detached. As long as we define the interfaces nicely, FWIW this object could even hold internal state, etc. And in the isolation case this interface serves as a convenient boundary. Now the drawback with this is that the decorator is a separate object - i.e., in its code, event handlers, etc., you can't access the decorated element directly, 'this' is not the element, etc. etc. However, I argue that is actually a feature - and even a requirement if we want to have non-trivial decorators, to address the very problems you stated. In this model, consider the decorator as the glittering glass ornament that is being hung on the christmas DOM tree - it decorates the tree, but it isn't the tree, nor an actual part of it. It can be detached (and potentially even hung somewhere else) without affecting the tree proper. ^_- Roland
Re: [Component Model] Decorator Challenges
On Thu, Nov 24, 2011 at 6:40 PM, Roland Steiner wrote: > On Wed, Nov 23, 2011 at 08:05, Dimitri Glazkov > wrote: >> >> Even if we attempt to separate the state of a decorator from the >> element and its document using an iframe- or worker-like machinery, >> we’ll still have similar issues of managing decorator instances that >> are no longer relevant, but don’t know that yet -- in addition to the >> performance costs of such high-isolation approach. > > I don't quite follow what you mean with the above - could you go into more > detail on this point? E.g., why would it be a problem if a worker-like > decorator that got detached sits around for a little while longer, doing > last timeouts and other stuff that no longer really matters? In case of total isolation, we totally could spec a clean shutdown process where the timers are cancelled and messages are dropped accordingly. > (FWIW, I'm also not convinced that it'd have to have high performance > overhead - in the best case it could be as little as just one more level of > indirection.) The startup time of a worker is non-trivial. Similarly, the shutdown won't be trivial. And the memory footprint of a worker isn't trivial either. If we're aiming for decorators to be fast and lean, we'll have to think of ways around those costs. :DG< > > Cheers, > - Roland >
Re: [Component Model] Decorator Challenges
On Wed, Nov 23, 2011 at 11:06 PM, Dominic Cooney wrote: > > > On Wed, Nov 23, 2011 at 8:05 AM, Dimitri Glazkov > wrote: >> >> We could explicitly prevent the decorator from ever having a state or >> being able to change it. This places a set of unorthodox (at least >> from author’s perspective) constraints on the DOM tree, created by the >> decorator. All of these constraints stem from the need to halt DOM >> changes in a decorator shadow subtree and include not allowing: >> *
Re: [Component Model] Decorator Challenges
On Wed, Nov 23, 2011 at 08:05, Dimitri Glazkov wrote: > Even if we attempt to separate the state of a decorator from the > element and its document using an iframe- or worker-like machinery, > we’ll still have similar issues of managing decorator instances that > are no longer relevant, but don’t know that yet -- in addition to the > performance costs of such high-isolation approach. > I don't quite follow what you mean with the above - could you go into more detail on this point? E.g., why would it be a problem if a worker-like decorator that got detached sits around for a little while longer, doing last timeouts and other stuff that no longer really matters? (FWIW, I'm also not convinced that it'd have to have high performance overhead - in the best case it could be as little as just one more level of indirection.) Cheers, - Roland
Re: [Component Model] Decorator Challenges
On Wed, Nov 23, 2011 at 8:05 AM, Dimitri Glazkov wrote: > We could explicitly prevent the decorator from ever having a state or > being able to change it. This places a set of unorthodox (at least > from author’s perspective) constraints on the DOM tree, created by the > decorator. All of these constraints stem from the need to halt DOM > changes in a decorator shadow subtree and include not allowing: > *
Re: [Component Model] Decorator Challenges
On Wed, Nov 23, 2011 at 2:18 PM, Tab Atkins Jr. wrote: > On Tue, Nov 22, 2011 at 3:05 PM, Dimitri Glazkov > wrote: >> We could explicitly prevent the decorator from ever having a state or >> being able to change it. This places a set of unorthodox (at least >> from author’s perspective) constraints on the DOM tree, created by the >> decorator. All of these constraints stem from the need to halt DOM >> changes in a decorator shadow subtree and include not allowing: >> *
Re: [Component Model] Decorator Challenges
On Tue, Nov 22, 2011 at 3:05 PM, Dimitri Glazkov wrote: > We could explicitly prevent the decorator from ever having a state or > being able to change it. This places a set of unorthodox (at least > from author’s perspective) constraints on the DOM tree, created by the > decorator. All of these constraints stem from the need to halt DOM > changes in a decorator shadow subtree and include not allowing: > *
[Component Model] Decorator Challenges
This is a continuation of the Component Model discussion at TPAC, focusing on decorators (see definition here: http://wiki.whatwg.org/wiki/Behavior_Attachment). The design goal for decorators can summarized as follows: allow runtime (dynamic) application and unapplication of presentation (and possibly behavior, associated with the presentation) to a DOM element, regardless of the current state of the element, in a way that’s performant (both in memory and time space), and intuitive for today’s Web developers. The problem with decorators is not their application, but the unapplication. If the decorator maintains state, this requirement of unapplication creates a difficulty of understanding when the state matters, when it no longer does, and even whether it’s the same state/instance as the one you left just a moment ago. For example, running script inside of the decorator forces the decorator’s author to follow rules of engagement that differ from those in typical script development -- in non-obvious ways: * registering an event listener with any DOM node outside of the decorator produces undesirable effect of a listener sticking around even after the decorator is unapplied. * using setInterval/setTimeout/XHR, or anything that exits event loop produces an expectation of code running after the decorator is unapplied. * even just storing state inside of a decorator is challenging; in situations where decorator is unapplied/reapplied quickly (like matching a hover pseudoclass), the state is lost without any warning. Even if we attempt to separate the state of a decorator from the element and its document using an iframe- or worker-like machinery, we’ll still have similar issues of managing decorator instances that are no longer relevant, but don’t know that yet -- in addition to the performance costs of such high-isolation approach. One way to remove some state uncertainty could be to pool all decorators instances and reuse them on reapplication, rather than creating new instances. Unfortunately, this means that the decorators may never be reclaimed, which also impacts performance characteristics. We could explicitly prevent the decorator from ever having a state or being able to change it. This places a set of unorthodox (at least from author’s perspective) constraints on the DOM tree, created by the decorator. All of these constraints stem from the need to halt DOM changes in a decorator shadow subtree and include not allowing: *
