| 08:31 | <Ms2ger 💉💉> | "of a glacier (hist.)" |
| 10:02 | <sideshowbarker> | looking at https://github.com/mdn/content/issues/12370 |
| 10:02 | <sideshowbarker> | calling
|
| 10:02 | <sideshowbarker> | …but where, in which spec, is that requirement defined? |
| 10:03 | <sideshowbarker> | it seems like it’s probably because it requires a secure context, but I don’t see anywhere in https://wicg.github.io/background-fetch/ that actually states it needs to be a secure context |
| 10:03 | <sideshowbarker> | and I don’t see the SecureContext WebIDL attribute anywhere |
| 10:18 | <Andreu Botella (he/they)> | I don't know about whether BackgroundFetch adds further requirements, but regular fetch only supports a few schemes: https://fetch.spec.whatwg.org/#scheme-fetch |
| 11:20 | <annevk> | Luca Casonato: I assume https://github.com/whatwg/spec-factory/pull/35#issuecomment-1019990419 looks okay? |
| 11:26 | <sideshowbarker> | I don't know about whether |
| 11:28 | <sideshowbarker> | …but that because only the https: scheme is allowed, or http: for loopback IPs message seems to make clear that BackgroundFetch is even disallowing http — so it’s enforcing some requirement beyond regular fetch |
| 11:28 | <sideshowbarker> | the problem is that the Background Fetch spec itself doesn’t seem to state any such requirement |
| 11:29 | <sideshowbarker> | I guess it’s possible that Chrome is imposing some additional requirement beyond what’s in the spec |
| 11:49 | <annevk> | sideshowbarker: did you try data: URLs? If that doesn't work it is, but otherwise it would follow from Mixed Content |
| 11:50 | <sideshowbarker> | haven’t tried that yet but will |
| 11:53 | <sideshowbarker> | but now I wonder, does Mixed Content say anything about fetches for unknown URL schemes from secure contexts? |
| 11:54 | <sideshowbarker> | I mean, I don’t expect it says anything about the chrome-extension scheme specifically, but maybe something more general |
| 11:54 | <sideshowbarker> | I guess I should just look myself and see |
| 11:56 | <sideshowbarker> | hmm I guess it comes down to chrome-extension not being explicitly defined as “potentially trustworthy” https://w3c.github.io/webappsec-secure-contexts/#potentially-trustworthy-origin |
| 13:31 | <annevk> | sideshowbarker: well Fetch only allows https://fetch.spec.whatwg.org/#fetch-scheme |
| 13:33 | <sideshowbarker> | yeah but if that’s the restriction the browser were enforcing in this case, it seems like the browser would be logging an error message which says that, rather than the different error message it is actually logging in this case |
| 13:34 | <Luca Casonato> | Luca Casonato: I assume https://github.com/whatwg/spec-factory/pull/35#issuecomment-1019990419 looks okay? |
| 13:34 | <Luca Casonato> | Thanks for getting this landed :-) |
| 14:26 | <annevk> | Ms2ger 💉💉: maybe file a bug against Deno/Node.js for Exposed=* changes too? https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests |
| 14:27 | <Ms2ger 💉💉> | Oh, that's new, is it? Will do |
| 14:27 | <Andreu Botella (he/they)> | For Deno, link to https://github.com/denoland/deno/issues/13239, since it's gonna take a while to sort that out |
| 14:28 | <annevk> | Thanks! (And yeah, today-ish new.) |
| 14:28 | <Andreu Botella (he/they)> | (cue Ms2ger 💉💉 insisting on me switching to the compilers team at Igalia 🤣) |
| 14:29 | <Ms2ger 💉💉> | :) |
| 17:24 | <mgaudet> | 👋 Trying to reason a bit about the expectation around globals and WebIDL interfaces. I've been looking at some of the JS engine tests we wrote for or streams. One of which tries to assert that if you invoke another global's ReadableStream.prototype.getReader with a stream in your current realm, you get a reader back that is in the other global, not your current one (tested using Right now, Safari and Chrome disagree: Safari has the reader in a different global, Chrome has it in the current global. Firefox disagrees with itself depending on which streams implementation I test: JS-implemented streams agrees with Safari, DOM+WebIDL implemented streams agrees with Chrome. |
| 17:25 | <mgaudet> | So, in this exact case, the question is one of: Which realm is implied by Step 1 of AcquireReadableStreamDefaultReader, "let reader be a new ReadableStreamDefaultReader" ? new links to the WebIDL spec which asks a specification to specify a realm... |
| 17:38 | <Schalk Neethling> | Hey All! Hope this is the appropriate place to ask questions like this. I am reading through the HTML specifications and I was wondering whether a FAQ page would be considered a valid use case for the details and summary elements? For example https://codepen.io/schalkneethling/pen/524ed00bc39a135f0d76de3c1519eaeb?editors=1100 - Thank you in advance. |
| 17:52 | <Domenic> | So, in this exact case, the question is one of: Which realm is implied by Step 1 of AcquireReadableStreamDefaultReader, "let reader be a new ReadableStreamDefaultReader" ? new links to the WebIDL spec which asks a specification to specify a realm... ReadableStream.prototype.getReader.call(x), it comes from x's global. |
| 17:59 | <mgaudet> | Ok. That works for me. Is this the kind of thing that I should (maybe eventually no promises) submit WPT tests for, or better to let things lie (given Safari currently does it by realm) |
| 17:59 | <Domenic> | WPTs would be super-lovely if possible. I will try to work on the spec side soon-ish. |
| 18:00 | <Schalk Neethling> | Hey All! Hope this is the appropriate place to ask questions like this. I am reading through the HTML specifications and I was wondering whether a FAQ page would be considered a valid use case for the details and summary elements? For example https://codepen.io/schalkneethling/pen/524ed00bc39a135f0d76de3c1519eaeb?editors=1100 - Thank you in advance. |
| 18:24 | <TabAtkins> | Schalk Neethling: It's fine semantically, but practically I think it's only really usable in current Chrome, which now has the ability for find-in-page, url hashes, etc to automatically open details when appropriate. When other browsers support that as well, it'll be more broadly usable. |
| 18:27 | <Schalk Neethling> | Schalk Neethling: It's fine semantically, but practically I think it's only really usable in current Chrome, which now has the ability for find-in-page, url hashes, etc to automatically open |
| 18:27 | <Schalk Neethling> | I have also heard that the dialog element is not accessible ☹️ Is this true? |
| 18:31 | <TabAtkins> | https://twitter.com/JosephArhar/status/1479525286211248128 |