| 03:48 | <annevk> | rniwa: https://github.com/whatwg/dom/issues/685#issuecomment-419551665 is untrue |
| 03:49 | <annevk> | rniwa: the proposed behavior flips the listener invocation order for my example |
| 03:50 | <annevk> | rniwa: the capture listener would be invoked first; smaug____ was indicating Gecko already has this behavior sometimes |
| 03:51 | <annevk> | rniwa: i.e., even without shadow trees there would be a subtle change, but we need to make it as otherwise we expose shadow trees |
| 05:07 | <rniwa> | annevk: which example? |
| 06:01 | <annevk> | rniwa: https://github.com/whatwg/dom/issues/685#issuecomment-419355034 |
| 06:02 | <rniwa> | annevk: yeah don't have a different behavior between Gecko vs WebKit/Blink, right? |
| 06:02 | <rniwa> | that* don't |
| 06:02 | <rniwa> | ugh... that* doesn't* |
| 06:02 | <annevk> | rniwa: per smaug____ for <input> there would be a difference |
| 06:03 | <rniwa> | annevk: I don't think so |
| 06:03 | <annevk> | rniwa: and with the PR there would be a difference |
| 06:03 | <rniwa> | annevk: how? |
| 06:03 | <annevk> | rniwa: capture listeners run first |
| 06:03 | <rniwa> | annevk: yeah but that has always been the case |
| 06:04 | <annevk> | No, for target the listeners would run in register order |
| 06:04 | <rniwa> | annevk: the only difference here is that capturing event listeners on the target that exists within a shadow tree gets invoked AFTER all capturing event listeners on ancestors of a shadow host were invoked |
| 06:04 | <annevk> | So bubble if registered first would run first |
| 06:04 | <rniwa> | annevk: right but only within shadow trees |
| 06:05 | <annevk> | rniwa: the PR affects the normal case too, no? |
| 06:05 | <rniwa> | annevk: i don't think so |
| 06:05 | <rniwa> | annevk: i'm pretty certain it wouldn't |
| 06:05 | <rniwa> | annevk: what happens is that in the world without a shadow tree |
| 06:06 | <rniwa> | annevk: the target's capturing event listener is the last thing we invoke in the capturing phase |
| 06:06 | <rniwa> | annevk: what breaks down in shadow DOM is that there could be multiple even targets on which event listeners are invoked with AT_TARGET |
| 06:06 | <rniwa> | annevk: as long as there is a single target, this odd capturing event listener ordering won't be happening |
| 06:07 | <rniwa> | annevk: it's true that capturing event listeners within UA shadow trees are happening after capturing event listeners of ancestors of those UA shadow hosts but I doubt any UA is exposing that kind of detail to the user land |
| 06:07 | <rniwa> | annevk: since most of events fired within a shadow tree aren't even exposed to the user land |
| 06:08 | <annevk> | I think we are still talking past each other |
| 06:08 | <rniwa> | ya |
| 06:09 | <annevk> | If a target has first a non-capture listener added and then a capture listener |
| 06:09 | <rniwa> | annevk: could you post an example in which event listeners will be invoked in different orders before/after your change / on Gecko vs. WebKit/Blink |
| 06:09 | <annevk> | The invocation order today is non-capture, then capture |
| 06:09 | <annevk> | Per PR it is capture, then non-capture |
| 06:10 | <rniwa> | annevk: oh I see. |
| 06:10 | <annevk> | In Gecko it depends on the target element type |
| 06:10 | <rniwa> | annevk: you're saying that on the target element, we'd invoke event listeners in the order they were registered |
| 06:10 | <annevk> | Today, yes |
| 06:10 | <rniwa> | annevk: as opposed to in the capturing then bubbling |
| 06:10 | <annevk> | Yes |
| 06:11 | <rniwa> | annevk: yeah, i'm a lot less concerned about that. |
| 06:11 | <annevk> | Ok |
| 06:11 | <annevk> | Good |
| 06:11 | <rniwa> | annevk: what's concerning is the event listeners on different elements getting invoked in different orders |
| 06:11 | <rniwa> | annevk: that's a lot likely to cause havocs in scripts that rely on particular ordering for stopping propagation, etc... |
| 06:12 | <annevk> | Yeah, I agree there is real risk for WebKit/Chromium here |
| 06:12 | <annevk> | I hope the experiment works out |
| 06:14 | <rniwa> | annevk: ya, i hope so too because what we have today is nuts |
| 06:17 | <rniwa> | annevk: so apparently ea.com and a bunch of other EA properties are using Polymer & web components in real |
| 06:18 | <rniwa> | smaug____: ^ |
| 15:31 | <GPHemsley> | oh my word, what is this?? https://tools.ietf.org/html/rfc2396.html#section-3.3 |
| 15:31 | <GPHemsley> | allowing parameters within each segment of a URL path?? |
| 15:33 | <GPHemsley> | wait, what ever are parameters |
| 15:33 | <GPHemsley> | *even |
| 17:18 | <TabAtkins> | The "newer" URI syntax still allows those, but only references them obliquely; they're not reified in the grammar itself. |
| 17:18 | <TabAtkins> | https://tools.ietf.org/html/rfc3986#section-3.3 |
| 19:34 | <zcorpan> | this <p> doesn't get a foster parent http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6210 |