On Feb 12, 2014, at 11:23 AM, Rafael Weinstein wrote:
> I pushed the Web Components folks about exactly this issue (why aren't these
> callbacks just MutationObservers?) early last year. They convinced me (and I
> remain convinced) that these signals should be Custom Element callbacks and
> n
On Feb 12, 2014, at 2:33 PM, Jonas Sicking wrote:
> On Wed, Feb 12, 2014 at 2:08 PM, Ryosuke Niwa wrote:
>> On Feb 12, 2014, at 11:23 AM, Rafael Weinstein wrote:
>>> In a certain sense, you can extend the argument that CE callbacks should be
>>> MO records, and you arrive at the conclusion th
On Wed, Feb 12, 2014 at 2:08 PM, Ryosuke Niwa wrote:
> On Feb 12, 2014, at 11:23 AM, Rafael Weinstein wrote:
>> In a certain sense, you can extend the argument that CE callbacks should be
>> MO records, and you arrive at the conclusion that you don't need Custom
>> Elements at all -- that every
On Feb 12, 2014, at 11:23 AM, Rafael Weinstein wrote:
> I pushed the Web Components folks about exactly this issue (why aren't these
> callbacks just MutationObservers?) early last year. They convinced me (and I
> remain convinced) that these signals should be Custom Element callbacks and
> no
I pushed the Web Components folks about exactly this issue (why aren't
these callbacks just MutationObservers?) early last year. They convinced me
(and I remain convinced) that these signals should be Custom Element
callbacks and not Mutation Observer records
Here's the logic that convinced me: Cu
On 02/12/2014 04:27 AM, Ryosuke Niwa wrote:
On Feb 11, 2014, at 6:06 PM, Bjoern Hoehrmann wrote:
* Olli Pettay wrote:
We could add some scheduling thing to mutation observers. By default we'd use
microtask, since that tends to be good for various performance
reasons, but normal tasks or nan
On Feb 11, 2014, at 8:41 PM, Joshua Peek wrote:
> Are you proposing new mutation record type? I think that could handle
> most of the enter/leave requirements.
Not really. I’m mostly talking about new timing at which mutation records are
delivered.
Apparently we need to deliver records more “e
Are you proposing new mutation record type? I think that could handle
most of the enter/leave requirements.
observer.observe(target, { element: 'x-foo' });
If MutationObservers are an open topic for extension, I'd love to see
generic css selector support.
observer.observe(target, { selector:
On Feb 11, 2014, at 6:27 PM, Ryosuke Niwa wrote:
>
>> On Feb 11, 2014, at 6:06 PM, Bjoern Hoehrmann wrote:
>>
>> * Olli Pettay wrote:
>>> We could add some scheduling thing to mutation observers. By default
>>> we'd use microtask, since that tends to be good for various performance
>>> reaso
> On Feb 11, 2014, at 6:06 PM, Bjoern Hoehrmann wrote:
>
> * Olli Pettay wrote:
>> We could add some scheduling thing to mutation observers. By default
>> we'd use microtask, since that tends to be good for various performance
>> reasons, but normal tasks or nanotasks could be possible too.
R
* Olli Pettay wrote:
>We could add some scheduling thing to mutation observers. By default
>we'd use microtask, since that tends to be good for various performance
>reasons, but normal tasks or nanotasks could be possible too.
This sounds like adding a switch that would dynamically invalidate
as
On 02/12/2014 03:41 AM, Ryosuke Niwa wrote:
Hi,
I’m bringing this up out of:
[Custom]: enteredView and leftView callbacks are still confusing
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24314
Could someone clarify exactly why mutation observers can’t satisfy use cases
for custom elements?
Hi,
I’m bringing this up out of:
[Custom]: enteredView and leftView callbacks are still confusing
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24314
Could someone clarify exactly why mutation observers can’t satisfy use cases
for custom elements?
I strongly believe that we should extend muta
13 matches
Mail list logo
