On Sat, Mar 23, 2013 at 3:25 AM, Dimitri Glazkov wrote:
> On Fri, Mar 22, 2013 at 9:35 AM, Scott Miles wrote:
> > In our work, we adopt a composition rule that a node knows about it's own
> > children and can have expectations of them, but can make no assumptions
> > about it's parent or siblings
On Fri, Mar 22, 2013 at 9:35 AM, Scott Miles wrote:
> In our work, we adopt a composition rule that a node knows about it's own
> children and can have expectations of them, but can make no assumptions
> about it's parent or siblings. As a coding model we've found it to be
> deterministic enough t
In our work, we adopt a composition rule that a node knows about it's own
children and can have expectations of them, but can make no assumptions
about it's parent or siblings. As a coding model we've found it to be
deterministic enough to build sane constructions. For example, you can use
methods/
On Fri, Mar 22, 2013 at 8:42 AM, Anne van Kesteren wrote:
> On Fri, Mar 22, 2013 at 6:27 AM, Hajime Morrita wrote:
>> So what about (B): Call first and second? This solves
>> the "unreadified " problem.
>
> And you will have a parent that is not ready.
>
> Or if you have
>
>
>
> you'll either
On Fri, Mar 22, 2013 at 6:27 AM, Hajime Morrita wrote:
> So what about (B): Call first and second? This solves
> the "unreadified " problem.
And you will have a parent that is not ready.
Or if you have
you'll either have a previousSibling or nextSibling, depending on
invocation order, that'
Hi folks,
I'm implementing "readyCallback" of custom elements in WeKit.
I'm following what MutationObserver is doing, with small modification. That
is to make such calls as lazily as possible, and do it in batch. After some
trial, I started wondering what is the most desirable "invocation order" o
