W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: [webcomponents]: What callbacks do custom elements need?

From: Daniel Buchner <danieljb2@gmail.com>
Date: Mon, 11 Mar 2013 14:27:09 -0700
Message-ID: <CAHZ6zJFGDdK+wzvZCNu_iUDHG1-q+t_L04fx_1Q+8SV-qG5XTw@mail.gmail.com>
To: public-webapps@w3.org
> Just to be clear, these are callbacks (right?), meaning synchronous
> executions on one specific node. That is a far cry from the old issues
> with mutation events and nightmarish bubbling scenarios.

Where does bubbling come in?

- I thought the concern was over the same issues that plagued mutation
*events*, namely perf-crushing event bubbling sparked by frequent DOM

But the issues with synchronous callbacks are not about performance,
last I checked, so I'm not sure why you're setting up this strawman.  Or
are people arguing something here based on performance considerations
that I missed?

- I wasn't aware of setting up such a strawman, I honestly thought the
issue was perf. I thought this because Jonas said this: "This will
have many of the same problems that mutation events had. I believe we
want to really stay away from synchronous. So yes, this looks
dangerous and crazy"


> as long as when they do fire, they fire once and the value/changes aren't stale.

Not sure what you mean here.

- I mean, that it doesn't matter if you make all the callbacks fire at
the end of a micro task, as long as you're not reporting old,
irrelevant changes to the developer - for instance: if an attribute
foo changes 3 times before the micro task is finished, the browser
should resolve the mutation record set to only fire one callback for
the last "fresh" occurrence of the mutation/action in question.

> Honestly, ready/created, inserted, and removed wouldn't be an issue if
> they map to micro tasks, right?

Running script at end of microtask is generally fine by me, since it
doesn't have the issues that running script sync does.

- Great, so what's the problem here? Are we officially in violent agreement? :)


> If attribute change callbacks are your worry, Brian Kardell
> mentioned something sensible, give people a way to whitelist just the
> ones that they want to watch for - assuming that is faster than simply
> telling devs to use basic if/switch logic inside the callback.

It's almost certainly faster but may not be worth the machinery,
depending on how much this is actually going to be used in practice.

- these four basic callbacks/mutations are essential to custom
element/component development - they will be used frequently, in our
experience thus far.


> There are many options here, let's not have an API-degrading, whopper
> freakout over a nascent concern of a fringe perf issue that is, to a
> large extent, self-mitigating/healing. (devs generally don't want to
> have slow crappy apps - built-in incentives to not suck are usually the
> best kind)

You and I seem to have different opinions on whether people care about
their code being a resource hog... Note that the typical culprits for
not caring are not "apps", though.

- The target and actual audience is probably not going to be
noobs/beginners, this is a pretty complex API - it appears you agree:
"the typical culprits for not caring are not apps".

- Daniel
Received on Monday, 11 March 2013 21:28:06 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:52 UTC