| 01:27 | <domfarolino> | I really need to attend one of these times... |
| 04:26 | <domfarolino> | TabAtkins: you around at all? |
| 04:27 | <TabAtkins> | I'm in NYC right now where it's past midnight, so: not really |
| 04:30 | <domfarolino> | No worries, question about some bikeshed syntax but very non-important, enjoy NYC |
| 06:49 | <annevk> | Domenic: I might |
| 09:55 | <annevk> | mathiasbynens: happy b-day! |
| 12:13 | <zcorpan> | Having RescueTime extension is annoying when trying to debug in devtools... |
| 13:55 | <lgrahl> | o/ |
| 13:56 | <zcorpan_> | \o |
| 13:58 | <lgrahl> | Some weird behaviour I found: I have attached an event handler via addEventListener. The event is being fired and inside of the event handler callback, I'm attaching another event handler, this time assigning it directly (channel.onmessage = handler2). What happens is that handler2 is being called with the same event that has already been handled inside of the event handler. Is that normal behaviour? |
| 14:00 | <zcorpan_> | lgrahl: do you have a jsfiddle or something? |
| 14:02 | <lgrahl> | In Firefox, I can work around this with setTimeout(..., 0) (but not with Promise.resolve().then(...)). In Safari, I have been unsuccessful to avoid this unless using a timeout of > 1 second. |
| 14:02 | <lgrahl> | zcorpan_: Not yet, let me see if I can reproduce this in a short script |
| 14:17 | <Ms2ger> | lgrahl, not sure that would necessarily be against the spec |
| 14:18 | <gsnedders> | I have a suspicion that adding a new handler for an event while it's being fired is undefined |
| 14:18 | <gsnedders> | which is probably bad, given I can easily imagine things relying on it |
| 14:18 | <lgrahl> | zcorpan_: Mh, unsuccessful so far. Will continue to investigate this. |
| 14:18 | <lgrahl> | As a side question: I assume removeEventListener will also remove handlers that have been added with the { once: true } option? |
| 14:19 | <zcorpan_> | gsnedders: i *think* it's well-defined, but haven't checked |
| 14:19 | <zcorpan_> | annevk might know |
| 14:20 | <jgraham> | I think it is too, but of course it might not work the way you expect |
| 14:23 | <gsnedders> | I mean I'm in a pub drinking coffee and working on non-web stuff at the moment, so… :) |
| 14:32 | <Ms2ger> | You'd need to look at the weird setup with the singleton event handler for onfoo attributes |
| 14:40 | <annevk> | lgrahl: yes (to side question) |
| 14:41 | <annevk> | gsnedders: it's well-defined |
| 14:42 | <annevk> | lgrahl: sounds like a bug |
| 14:42 | <lgrahl> | annevk: I'm currently trying to rule out a bug on my side since I couldn't reproduce it outside of a fairly complex setup so far. |
| 14:42 | <annevk> | lgrahl: gsnedders: in particular see step 6 of https://dom.spec.whatwg.org/#concept-event-listener-invoke whereby a clone of current listeners is made |
| 14:43 | <annevk> | lgrahl: gsnedders: any added listeners would not be able to participate for the current object |
| 14:43 | <zcorpan_> | gsnedders: disconnect and enjoy your coffee. then, when you get back, tell me what's wrong in https://github.com/w3c/web-platform-tests/pull/11092 :-) |
| 14:44 | <jgraham> | Alternate plan: disconnect and feel existential dread that ruins your coffee |
| 14:49 | <gsnedders> | zcorpan_: but then what do I do to procrastinate from what I'm working on! |
| 14:49 | <Ms2ger> | I suspected http://software.hixie.ch/utilities/js/live-dom-viewer/saved/5966 could do it, but it seems not |
| 14:56 | <Ms2ger> | I'm starting to think the spec disagrees with browsers here |
| 14:58 | <Ms2ger> | Oh, no |
| 14:58 | <gsnedders> | zcorpan_: will look in a few mins |
| 14:59 | <Ms2ger> | Spec is right: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/5967 |
| 14:59 | <Ms2ger> | lgrahl, ^ |
| 14:59 | <Ms2ger> | Safari seems to get it wrong, though |
| 14:59 | <Ms2ger> | Or epiphany; can someone check actual safari? |
| 15:36 | <zcorpan_> | log: 2 in safari tp |
| 16:41 | <lgrahl> | Ms2ger: So, what I described is supposed to happen? |
| 16:42 | <Ms2ger_> | lgrahl, that is my understanding, yes |
| 16:48 | <annevk> | lgrahl: does your code also attach an event handler earlier on, like Ms2ger_'s examples? |
| 16:49 | <annevk> | lgrahl: event handlers are rather magical; they only add an event listener the first time; afterwards they just swap out the "body" of the listener they added |
| 16:53 | <lgrahl> | annevk: Just changed it to this http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5968 which somewhat resembles what my code does. In that case, the event is not fired. Even though this puzzles me... I'm fine with it. I guess it's a bug in my code (or in the data channel implementation) then. I will try to investigate this further. |
| 16:54 | <lgrahl> | *event is not fired in both handlers |
| 16:57 | <annevk> | lgrahl: with that code you should see 2, not 3 |
| 16:58 | <lgrahl> | annevk: Yes, that's what Firefox does, too. Is there a way to list the event handlers? I have a slight feeling what the problem might be and that would help me. |
| 17:01 | <jgraham> | Not except via dev tools |
| 17:09 | <gsnedders> | zcorpan: FWIW, on 11092 I still get way more than two failures |
| 17:09 | <gsnedders> | zcorpan: plz check you've actually pushed everything ;P |
| 17:09 | <zcorpan> | ;_; |
| 17:14 | <zcorpan_> | gsnedders: ok now |
| 17:28 | <zcorpan> | mathiasbynens: gefeliciteerd 🎉 |
| 17:45 | <jugglinmike> | zcorpan: gesundheit |
| 17:47 | <jugglinmike> | TabAtkins: If you have the time, I could use your input on a patch for a WPT test on font loading? https://github.com/w3c/web-platform-tests/pull/11082 |
| 18:49 | smaug____ | wonders if anyone knows any major website using shadow DOM |
| 18:49 | <smaug____> | (v1) |
| 19:00 | <zcorpan> | smaug____: doesn't youtube use it? |
| 19:01 | <smaug____> | last time I checked, it was still on v0 |
| 19:01 | <smaug____> | perhaps I should re-check |
| 19:08 | <mathiasbynens> | zcorpan: thanks :) |
| 20:09 | smaug____ | wonders what to do with https://github.com/whatwg/html/issues/3699 |
| 20:10 | <smaug____> | perhaps I should propose an algorithm which propagates directionality state through shadow DOM |
| 20:21 | <TabAtkins> | MikeSmith: Okay, https://github.com/tabatkins/highlighter should be complete and usable now. Calling instructions are included in the README; the repo is self-contained and requires nothing but Python 2.7 to be run. |
| 21:00 | <lgrahl> | What on earth... |
| 21:02 | <lgrahl> | What does setting an event handler directly really do? Is ".onsomeevent = ..." equal to "addEventListener('someevent', ...)"? |
| 21:30 | <jyasskin> | lgrahl: Nope: Under https://html.spec.whatwg.org/multipage/webappapis.html#event-handler-attributes see "When an event handler H of an EventTarget object T is first set to a non-null value," |
| 21:30 | <jyasskin> | Some neat ComeFrom stuff there, since the setter isn't defined to do that. Be an easy patch to fix that... |
| 21:32 | <jugglinmike> | annevk: Do you know why ""Abort a document" reads "Cancel any instances of the fetch algorithm" rather than referencing fetch's "terminated"? |
| 21:40 | <lgrahl> | jyasskin: Umm, that's a bit heavy to digest for me right now. But I think I found my bug. If there are code examples on how .onsomeevent and .addEventListener('someevent', ...) interact and possible quirks of using both, I'd be grateful. |
| 21:42 | <jyasskin> | lgrahl: The "This example demonstrates the order in which event listeners are invoked." example under there has that kind of code example. I don't know of others. |
| 21:42 | <jyasskin> | And there are probably other quirks it doesn't cover. |
| 21:44 | <lgrahl> | I'm not worried about the order, I would more be interested in how they differ. For example, IIRC .onsomeevent replaces the former event handler (if any) but how does it interact with event handlers added via .addEventListener? Can .removeEventListener remove an existing handler registered via .onsomeevent = ...? These kinds of questions. :) |
| 21:45 | <jyasskin> | I believe the thing wrapping the .onsomeevent value is exactly the same as a listener added by .addEventListener(), except that user code doesn't have its value, so can't pass it to .removeEventListener(). |
| 21:56 | <MikeSmith> | TabAtkins: w00t |
| 21:57 | <MikeSmith> | thanks thanks thanks |
| 21:57 | <MikeSmith> | I’ll work today on plugging it into the HTML build |
| 21:59 | <TabAtkins> | Cool, let me know if any problems or questions. |
| 22:14 | <MikeSmith> | TabAtkins: will do |
| 22:14 | <MikeSmith> | you still on US/East today/tomorrow? |
| 22:38 | <rniwa> | MikeSmith: yt? |
| 22:41 | <rniwa> | smaug____: yt? |
| 22:41 | <smaug____> | rniwa: pong |
| 22:41 | <rniwa> | smaug____: hi |
| 22:42 | <rniwa> | smaug____: do you recall the discussion about the support for detecting the supported values of link rel |
| 22:43 | <smaug____> | related to tokenlist? |
| 22:47 | <smaug____> | https://github.com/whatwg/dom/pull/123 and such |
| 22:47 | <smaug____> | uh, discussion happening in prs, not in issues |
| 22:47 | <rniwa> | smaug____: oh interesting |
| 22:47 | <rniwa> | smaug____: yeah, i hate that :( |
| 22:48 | <rniwa> | smaug____: it's one of the worst thing about Github |
| 22:48 | <rniwa> | smaug____: anyway, thanks for the pointer! |
| 22:48 | <rniwa> | (should have asked cdumez about this LOL) |
| 22:49 | <smaug____> | yeah, it is somewhere there, in couple of issues and prs |
| 22:53 | <rniwa> | smaug____: by the way, about your question about lifecycle thing in blink-dev |
| 22:54 | <smaug____> | yeah, just wondered if webkit folks have looked at the proposal |
| 22:54 | <rniwa> | smaug____: i've already given the feedback that "freeze" event won't work for us because we don't wanna run scripts at that point |
| 22:56 | <rniwa> | smaug____: maybe my feedback wasn't communicated well :( |
| 22:57 | <MikeSmith> | rniwa: here now |
| 22:58 | <rniwa> | MikeSmith: smaug____ answered my question. thanks for the reply! |
| 22:58 | <MikeSmith> | hai~ |
| 22:58 | <smaug____> | I was surprised to see that blink is about to ship the lifecycle thing |
| 23:00 | <smaug____> | I mean, it feels like something to go through still couple of design iterations. But perhaps I'm wrong. |
| 23:03 | <rniwa> | smaug____: yeah, it doesn't seem ready at all |
| 23:03 | <rniwa> | smaug____: but then blink ships a lot of things that i think aren't ready so... there's that |