| 02:58 | <weinig> | Domenic: question for you, would you expect window.EventListener to exist given the definition of EventListener https://dom.spec.whatwg.org/#callbackdef-eventlistener and https://heycam.github.io/webidl/#interface-object ? |
| 02:58 | <weinig> | Domenic: Firefox and Safari don' |
| 02:58 | <weinig> | don’t seem to have window.EventListener |
| 02:59 | <weinig> | Domenic: and I can’t figure out a great reason for it to exist, given that it doesn’t have any constants, like say NodeFilter (https://dom.spec.whatwg.org/#interface-nodefilter) |
| 03:47 | <Domenic> | weinig: no, a callback interface is not an interface |
| 03:47 | <Domenic> | Or, maybe that wasn't the intended distinction, but "The interface object for a given non-callback interface I" makes pretty clear. |
| 08:26 | <foolip> | annevk: are you OOO for a while? would like to get https://github.com/whatwg/fullscreen/pull/90 merged |
| 11:28 | <mkwst> | foolip: I think he said above that he's mostly on vacation through July. |
| 13:32 | <tobie> | So I'm struggling quite a bit with focus. Trying to stop sensors from running when a browsing context looses focus. Is there a way to spec that? |
| 13:33 | <tobie> | More specifically when a top-level browsing context looses focus. |
| 13:33 | <tobie> | I'm not even looking for something I could hook on as I was the last time I mentioned this here. |
| 13:34 | <tobie> | Just normative language to say: "when focus is on another top-level browsing context, stop the sensors." |
| 14:46 | <tobie> | Answering my own question for the sake of others: https://html.spec.whatwg.org/#has-focus-steps |
| 15:03 | <smaug> | does anyone know if it is possibly to disable support for custom elements in Chrome? |
| 15:59 | <tobie> | https://www.irccloud.com/pastebin/HnC4oguM/ |
| 15:59 | <tobie> | ^ 1, 2, or 3? |
| 16:38 | <GPHemsley> | so, uh... https://wiki.whatwg.org/wiki/Specs/style vs. https://wiki.whatwg.org/wiki/Style vs. https://infra.spec.whatwg.org/ |
| 17:40 | <TabAtkins> | tobie: #2 for simple things like that; #1 if the clause is more complicated and explicitly invoking an if/then/else structure helps with comprehensibility. |
| 17:40 | <TabAtkins> | Never ever #3, imo. |
| 17:50 | <jyasskin> | tobie: I think the "has focus steps" don't do what we want: what's "the" top-level browsing context? I think every tab has one, even non-focused tabs, and tabs in minimized windows. |
| 17:51 | <tobie> | TabAtkins: thanks |
| 17:52 | <jyasskin> | +1 for Tab's ", return" preference. |
| 17:52 | <TabAtkins> | Always make your grammar as simple as you can, but no simpler. ^_^ |
| 17:53 | <jyasskin> | "Check if |foo|. If |foo| was true, continue executing the following steps. Otherwise, return and do not continue executing the following steps." |
| 17:54 | <TabAtkins> | Perfect. |
| 17:56 | <TabAtkins> | fantasai and I go to pretty extensive lengths to make sure we're using grammar well and simply; in particular, we focus heavily on using parallel structure to help highlight similarities between branches of an algorithm, so the differences stand out more strongly. |
| 17:59 | <tobie> | jyasskin: not sure what you mean re has focus steps. Why isn't it a right fit? |
| 18:02 | <tobie> | jyasskin: oh shoot. How did I miss that? How is this algorithm even correct? Arg!!! |
| 18:03 | <jyasskin> | tobie: It *might* be correct for the ways it's used, but yeah, it's dubious. |
| 18:04 | <tobie> | So it's called from document.hasFocus() and that works as expected |
| 18:04 | <tobie> | Try running setTimeout(function() { console.log(document.hasFocus()) }, 5000) in your console |
| 18:04 | <tobie> | Both while keeping focus on your console and on the main browsing context. |
| 18:05 | <tobie> | jyasskin: |
| 18:05 | <tobie> | ^ |
| 18:06 | <tobie> | It should probably read: Let candidate be the Document of the *current* top-level browsing context. |
| 18:06 | <tobie> | Or something like that. |
| 18:09 | <jyasskin> | Yep, so the spec just doesn't match implementations? I think there should be some notion of a focused top-level browsing context. There might not be any, when a non-browser application is focused. I prefer "focused" instead of "current" because we could have more notions of "current". |
| 18:37 | <tobie> | jyasskin: no, I think the spec lacks clarity: if you read step 1 as: Let candidate be the Document of the CURRENTLY FOCUSED top-level browsing context, then in step 2, candidate is NOT target, and thus you end up at the last line: Otherwise, return false and abort these steps. |
| 18:43 | <jyasskin> | It's still wrong to assume that a currently focused top-level browsing context exists. ... I think https://html.spec.whatwg.org/multipage/interaction.html#focus needs to describe the concept. |
| 19:23 | <Domenic> | I am recovering from a week of hosting TC39 + a weekend-plus of being sick, so if there are things I've missed that should jump to the front of the queue, let me know. |
| 19:30 | <annevk> | foolip: if xidorn reviewed just merge |
| 19:30 | <annevk> | foolip: someone else reviewing is fine too, just at least one |
| 20:17 | <jugglinmike> | TabAtkins: What makes something an "attribute" in terms of the HTML spec? |
| 20:18 | <jugglinmike> | I'm wondering if https://html.spec.whatwg.org/multipage/workers.html#dom-workerglobalscope-closing actually is an attribute, or if the markup needs to be changed to make it a "dfn" (which seems imprecise, according to the Bikeshed documentation) |
| 20:21 | <tobie> | jugglinmike: that looks like an internal slot to me. |
| 20:22 | <tobie> | jyasskin: It's still wrong to assume that a currently focused top-level browsing context exists. ... I think <-- this is related: https://github.com/whatwg/html/issues/2716. |
| 20:23 | <jugglinmike> | tobie: in that case, I guess it's type ought to be "dfn" |
| 20:23 | <tobie> | jugglinmike: that's sort of spec-specific for now. |
| 20:24 | <tobie> | jugglinmike: afaik |
| 20:25 | <tobie> | jugglinmike: TabAtkins recommended I used <dfn attribute for=[INTERFACE]>\[[SLOT_NAME]]</dfn> |
| 20:25 | <tobie> | jugglinmike: but you should follow the conventions in the spec you're editing |
| 20:27 | <tobie> | jyasskin: I think HTML doesn't have a clear concept of one focused browsing-context per user agent (though has focus steps is close) and one focused app per operating system. |
| 20:27 | <tobie> | jyasskin: both need fixing. Along with the hooks of when this stuff happens |
| 20:35 | <jyasskin> | +1 |
| 21:40 | <TabAtkins> | Yeah, it's an internal slot, which is *typed* as an attribute, but with double-square-brackets around its name. |
| 21:40 | <TabAtkins> | Or it can be just be a dfn attached to the interface, in which case you just add an explicit data-dfn-type=dfn to it. |
| 21:41 | <TabAtkins> | Either works, match convention as tobie says. |
| 21:41 | <TabAtkins> | jugglinmike: ^^^ |
| 21:50 | <jugglinmike> | thanks TabAtkins. I've submitted a patch for the latter |
| 21:50 | <jugglinmike> | ah, but you know that by now :P |
| 21:50 | <TabAtkins> | Heh, yup. |
| 22:24 | <tobie> | How do you all specify initial values of internal slots? |
| 22:24 | <tobie> | Actually set it in the constructor? |
| 22:25 | <tobie> | Or just have a bit of text that says: the initial value of foo is bar? |
| 22:25 | <tobie> | Or: "foo is bar unless specified otherwise"? |
| 22:25 | <TabAtkins> | I set it in the constructor. |
| 22:25 | <TabAtkins> | I treat internal slots exactly as attributes that just happen to only be available in spec-ese. |
| 22:26 | <tobie> | TabAtkins: do you queue a task to set it? |
| 22:26 | <TabAtkins> | No? |
| 22:26 | <TabAtkins> | brb |
| 23:04 | <tobie> | Do we have examples of specs that go remove tasks from the task queue? |
| 23:05 | <tobie> | Context is a new sensor reading has been received and a task has been queued to update an internal slot and fire an event… |
| 23:06 | <tobie> | But then the browsing context looses focus (before the task has been completed) and we want to stop transmitting readings |
| 23:09 | <Domenic> | Didn't we decide the idea was the task should check if it still has focus, and if not, just return early? |
| 23:09 | <Domenic> | tobie: ^ |
| 23:12 | <tobie> | Domenic: Mmm. That's a good point. |
| 23:18 | <tobie> | Domenic: I've had a long day trying to convince people that it wasn't because the spec said to check for focus (and visibility status) before each reading that implementations weren't able to optimize this. |
| 23:18 | <Domenic> | Oh fun times |
| 23:19 | <tobie> | yeah :-/ |