[Bug 16491] Add simpler and better event registration system

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16491

--- Comment #17 from Glenn Maynard <glenn@zewt.org> ---
It means that delegated events would fire as if they were actually dynamically
registered on the real target.  For example, if you have a block like this:

<div onclick="console.log('outer'); event.stopPropagation();">
    <div onclick="console.log('inner'); event.stopPropagation();"</div>
</div>

and you want to use delegates for both click events, you could say this:

<div class=delegate>
    <div class=outer>
        <div class=inner></div>
    </div>
</div>

<script>
querySelector(".delegate").addEventListener("click", function(e) {
    console.log("outer");
    e.stopPropagation();
}, { delegate: ".outer" });

querySelector(".delegate").addEventListener("click", function(e) {
    console.log("inner");
    e.stopPropagation();
}, { delegate: ".inner" });
</script>

and you'd always get the same event order as the first one, without having to
carefully match up the registration order with the nesting order of the DOM
nodes.  

Aside: I like the idea of making this a simple extension to addEventListener,
as I tried out above, but the options block really wants to come before the
function, not after it.  I'm not sure if an addEventListener(type, options,
function) overload is as natural as addEventListener(type, function, options),
unfortunately.

> and I'm wondering how to not regress event dispatching performance too badly

I assume it would be bad to have to check the filters of each node's parents as
you walk the tree, since that becomes n^2.  Precalculating the list of matching
delegates would avoid this, but precalculation doesn't really match the model,
and it would still require walking up the tree an extra time.  Hmm.  Combined
with the difficulty of polyfilling, it might not be worth it.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Saturday, 16 February 2013 19:51:03 UTC