On 12/16/10 1:46 PM, Tab Atkins Jr. wrote:
On Thu, Dec 16, 2010 at 1:33 PM, Boris Zbarskybzbar...@mit.edu wrote:
On 12/16/10 1:00 PM, Dimitri Glazkov wrote:
I agree that it's going to be difficult to get this right, but
semi-live templates (if you change it here, it will reflect on all
Boris, Tab, thank you for clarification.
I was confusing template and non-template (content) part of the shadow tree..
For template, it makes sense to let them dead and freeze the structure.
--
morrita
On Sat, Dec 18, 2010 at 2:35 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Thu, Dec 16,
On 12/15/10 11:29 AM, Dimitri Glazkov wrote:
That seems like an implementation detail. Metadata can be shared and
cloned as needed, just like styles in CSS.
Sort of. It would need to be cloned as soon as the shadow tree is
mutated, right? That seems like very fragile behavior from a web
On Thu, Dec 16, 2010 at 10:40 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/15/10 11:29 AM, Dimitri Glazkov wrote:
That seems like an implementation detail. Metadata can be shared and
cloned as needed, just like styles in CSS.
Sort of. It would need to be cloned as soon as the shadow tree
On 12/16/2010 11:52 AM, Tab Atkins Jr. wrote:
On Thu, Dec 16, 2010 at 10:40 AM, Boris Zbarskybzbar...@mit.edu wrote:
On 12/15/10 11:29 AM, Dimitri Glazkov wrote:
That seems like an implementation detail. Metadata can be shared and
cloned as needed, just like styles in CSS.
Sort of. It
On Thu, Dec 16, 2010 at 10:40 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/15/10 11:29 AM, Dimitri Glazkov wrote:
That seems like an implementation detail. Metadata can be shared and
cloned as needed, just like styles in CSS.
Sort of. It would need to be cloned as soon as the shadow tree
On Thu, Dec 16, 2010 at 12:23 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 12/16/2010 11:52 AM, Tab Atkins Jr. wrote:
On Thu, Dec 16, 2010 at 10:40 AM, Boris Zbarskybzbar...@mit.edu wrote:
On 12/15/10 11:29 AM, Dimitri Glazkov wrote:
That seems like an implementation detail. Metadata
On 12/16/10 1:00 PM, Dimitri Glazkov wrote:
I agree that it's going to be difficult to get this right, but
semi-live templates (if you change it here, it will reflect on all
instances, but it you change it here, it won't) seem even more
fragile.
Sure. I'm proposing that templates be
On Thu, Dec 16, 2010 at 1:33 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/16/10 1:00 PM, Dimitri Glazkov wrote:
I agree that it's going to be difficult to get this right, but
semi-live templates (if you change it here, it will reflect on all
instances, but it you change it here, it won't)
On Tue, Dec 14, 2010 at 10:32 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/14/10 10:08 PM, Tab Atkins Jr. wrote:
Hm, good point. So then, no, there has to be an element in the shadow
DOM that represents an output port, which is then *replaced* with the
appropriate normal-DOM children in
On 12/15/10 7:51 AM, Tab Atkins Jr. wrote:
Yes to the first two. Maybe to the last - the final flattened tree is
just what's handed to CSS as the element-tree. There aren't really
DOM nodes there, or at least it doesn't matter whether or not there
is.
OK.
(Events and such don't work on the
On Wed, Dec 15, 2010 at 10:19 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/15/10 7:51 AM, Tab Atkins Jr. wrote:
(Events and such don't work on the final flattened tree
Sort of. Hit testing clearly needs to work on the layout structure
generated from the final flattened tree, so event
On Wed, Dec 15, 2010 at 10:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Dec 15, 2010 at 10:19 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/15/10 7:51 AM, Tab Atkins Jr. wrote:
(Events and such don't work on the final flattened tree
Sort of. Hit testing clearly needs to work
On Wed, Dec 15, 2010 at 11:10 AM, Dimitri Glazkov dglaz...@google.com wrote:
On Wed, Dec 15, 2010 at 10:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Dec 15, 2010 at 10:19 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/15/10 7:51 AM, Tab Atkins Jr. wrote:
(Events and such don't
On 12/15/10 10:51 AM, Tab Atkins Jr. wrote:
Yes, output ports can be moved. I don't have any particular use-case
for it, but under the current conceptual model for how output ports
work, it's simpler to allow it than to disallow it, because output
ports are just elements.
It significantly
On Wed, Dec 15, 2010 at 11:14 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/15/10 10:51 AM, Tab Atkins Jr. wrote:
Yes, output ports can be moved. I don't have any particular use-case
for it, but under the current conceptual model for how output ports
work, it's simpler to allow it than to
On Wed, Dec 15, 2010 at 11:14 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/15/10 10:51 AM, Tab Atkins Jr. wrote:
Yes, output ports can be moved. I don't have any particular use-case
for it, but under the current conceptual model for how output ports
work, it's simpler to allow it than to
On 12/15/10 11:40 AM, Tab Atkins Jr. wrote:
If all you're doing is moving the output port, why wouldn't all the
associated normal-DOM elements end up in the same place?
Because the new parent of the output port can have a binding attached
itself, which puts them in different output ports
18 matches
Mail list logo
