| 00:24 | <Domenic> | Is it specced that adding a fetch event listener in the service worker after first run will do something weird? https://dom.spec.whatwg.org/#add-an-event-listener just says "might not have expected results" but I can't find any spec mechanism that could generate those wrong results. |
| 00:26 | <Domenic> | Ah I think I found it: https://w3c.github.io/ServiceWorker/#run-service-worker-algorithm step 17.1 |
| 06:22 | <annevk> | Domenic: yeah, service workers violates the don't look at events thingie :-/ |
| 06:28 | <Domenic> | I've come to peace with it, service workers are weird. |
| 08:50 | <annevk> | Domenic: did you have a chance to look at https://github.com/web-platform-tests/wpt/pull/38150 again? |
| 08:51 | <annevk> | Domenic: I also found that we have url-setters-stripping.any.js which might make some of these a bit redundant |
| 09:03 | <nicolo-ribaudo> | Hello! Could I get an invite for the HTML issue triage meeting (https://github.com/whatwg/html/issues/8723) at nribaudo@igalia.com? (or even just the link to join!) EDIT: got it, thanks! |
| 09:41 | <foolip> | Hey all. I built a toy a while ago: https://foolip.github.io/spec-reactions/ |
| 09:41 | <foolip> | Sorting by recent reactions and filtering to WHATWG gives this: |
| 09:42 | <Domenic> | Domenic: did you have a chance to look at https://github.com/web-platform-tests/wpt/pull/38150 again? |
| 09:42 | <foolip> | Does that seem like it could correspond with things that are worth extra attention? |
| 09:43 | <Domenic> | I like it, foolip! I've been rooting for observables in particular for some time :) |
| 09:44 | <foolip> | Ah yes, https://github.com/whatwg/dom/issues/544 wins the total reactions battle, but seems to have fallen quite lately. |
| 09:48 | <annevk> | Domenic: I'm going to merge to not block other implementers (and given the other existing tests); I can file an issue on jsdom if you want? |
| 09:49 | <Domenic> | Sounds good, and yeah a tracking issue would be quite lovely. |
| 12:08 | <hsivonen> | annevk: What is supposed to make the iframes not inherit UTF-8 from the same-origin parent harness in WebKit and Blink in https://wpt.fyi/results/encoding/unsupported-labels.window.html?label=experimental&label=master&aligned&view=subtest ? |
| 12:50 | <annevk> | hsivonen: I think Firefox might have a different default encoding maybe due to your work? |
| 12:51 | <annevk> | hsivonen: if that's not it I guess I need to take a longer look |
| 12:52 | <smaug> | annevk: but Chrome uses utf-8 in the parent document too, and I assume so does Safari |
| 12:53 | <hsivonen> | annevk: Without inheritance, if the content is ASCII, Firefox defaults to windows-1252. However, in the test case, the parent declares UTF-8, so that's inheritable within the same origin. |
| 12:53 | <annevk> | Interesting, so these always failed in Gecko? |
| 12:54 | <hsivonen> | annevk: Yes, it looks like this test has failed since it synced to m-c in October. It's unfortunate that we don't have automated notifications for new tests that fail. |
| 12:57 | <annevk> | hsivonen: you were the reviewer! 😀 |
| 12:57 | <annevk> | I can take a look later today most likely |
| 17:13 | <annevk> | smaug: hsivonen: it seems that once Content-Type charset is involved there's no more cross-document inheritance, regardless of whether that charset value is correct, in Chromium and WebKit |
| 17:14 | <annevk> | https://github.com/web-platform-tests/wpt/pull/38199 demonstrates this, though it could test more |
| 17:16 | <annevk> | smaug: hsivonen: I guess I clean those tests up, and also make the encoding/ tests use <meta> instead for now so we don't run into this particular issue. And then file bugs against Chromium/WebKit or open a spec issue to see if we want to collectively reconsider given that more sites might rely on Chromium/WebKit behavior at this point... |
| 17:17 | <smaug> | annevk: ok, thanks! |
| 20:33 | <jugglinmike> | Anybody here know much about Chrome's use-counter data? I'm looking for numbers on the CSS :has pseudoselector, but I can't find a use counter. That seems surprising for such a popular and difficult-to-implement feature, so I'm wondering if I'm looking in the wrong place. https://chromestatus.com/metrics/css/popularity |
| 20:41 | <zcorpan> | jugglinmike: search for "cssselectorpseudohas" in https://chromestatus.com/metrics/feature/popularity (not so appropriately named "JS/HTML" in the menu) |
| 20:41 | <zcorpan> | There are several and I don't know the difference between them |
| 20:41 | <zcorpan> | But you can look up how they're implemented in https://source.chromium.org/chromium |
| 20:43 | <jugglinmike> | Excellent; thanks, zcorpan ! |
| 20:44 | <zcorpan> | Maybe snapshot profile means querySelector{,All}() and live profile means CSS |
| 20:48 | <zcorpan> | Filed https://github.com/GoogleChrome/chromium-dashboard/issues/2694 |
| 22:11 | <Jeremy Roman> | Maybe snapshot profile means querySelector{,All}() and live profile means CSS |
| 23:04 | <jugglinmike> | Jeremy Roman: Thanks for clarifying. It seems like binning the data like that makes it difficult to answer the question, "how often is :has used?" since there's no telling how many pages use it in both contexts. Is that right? |
| 23:17 | <jugglinmike> | Ah, scratch that--"CSSSelectorPseudoHas" is a dedicated flag! |
| 23:19 | <jugglinmike> | Except, it looks like it has never been used. Hinky |
| 23:31 | <Jeremy Roman> | Yeah, unfortunately I think you're right. It's at least max(CSSSelectorPseudoHasInLiveProfile, CSSSelectorPseudoHasInSnapshotProfile) |
| 23:32 | <Jeremy Roman> | and at most CSSSelectorPseudoHasInLiveProfile+CSSSelectorPseudoHasInSnapshotProfile |
| 23:33 | <Jeremy Roman> | which puts it somewhere between 2.9% and 5.1% |
| 23:34 | <Jeremy Roman> | wouldn't be hard to add a usecounter for either or, but I don't see one currently |
| 23:52 | <aja> | fwiw, i use it extensively in local tests now. i'd hope you're not seeing a lot of use where it's not wrapped within a "@supports selector" group...at least for the next few years, |