On Tue, Nov 29, 2011 at 11:15, Roland Steiner rolandstei...@google.comwrote:
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,
On Wed, Nov 23, 2011 at 11:06 PM, Dominic Cooney domin...@google.com wrote:
On Wed, Nov 23, 2011 at 8:05 AM, Dimitri Glazkov dglaz...@chromium.org
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
On Thu, Nov 24, 2011 at 6:40 PM, Roland Steiner
rolandstei...@google.com wrote:
On Wed, Nov 23, 2011 at 08:05, Dimitri Glazkov dglaz...@chromium.org
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,
On Tue, Nov 29, 2011 at 02:18, Dimitri Glazkov dglaz...@chromium.orgwrote:
On Thu, Nov 24, 2011 at 6:40 PM, Roland Steiner
rolandstei...@google.com 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
On Wed, Nov 23, 2011 at 08:05, Dimitri Glazkov dglaz...@chromium.orgwrote:
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
On Tue, Nov 22, 2011 at 3:05 PM, Dimitri Glazkov dglaz...@chromium.org 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
On Wed, Nov 23, 2011 at 8:05 AM, Dimitri Glazkov dglaz...@chromium.orgwrote:
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
