| 01:37 | <MikeSmith> | TabAtkins: Any current estimate of when you might be able to do the thing of extracting the syntax-highlighting stuff from Bikeshed so that we can use it for the HTML spec? |
| 02:58 | <TabAtkins> | MikeSmith: Ah dang, that's like 80% finished, I just dropped it. I'll get it done next week for you. |
| 03:32 | <MikeSmith> | TabAtkins: \o/ |
| 03:32 | <MikeSmith> | thanks! |
| 07:10 | <mkwst> | annevk: re:https://github.com/w3c/web-platform-tests/pull/10594#issuecomment-390116038, it would be nice if we could write down what folks think `from-origin` means. The github thread is confusing, and seems to be moving in a direction that doesn't match what's in WebKit at the moment. |
| 07:11 | <mkwst> | Is that on your plate? Or Apple's? Or do we need to find a volunteer? :) |
| 07:11 | <annevk> | mkwst: so WebKit folks would get back to my suggestion I think |
| 07:11 | <annevk> | mkwst: I think making From-Origin the CORB opt-in makes the most sense and would be the easiest to adopt |
| 07:13 | <annevk> | mkwst: so I guess it's on Apple's plate and perhaps also on Google and Microsoft's plate to evaluate my input and give their perspective |
| 07:13 | <mkwst> | I worry a bit that further narrowing `from-origin`'s impact makes it even less likely that folks would serve it. |
| 07:13 | <mkwst> | I also worry about some Google security folks' feedback regarding deployability. |
| 07:14 | <annevk> | mkwst: this makes it much easier to deploy as it only affects cross-origin no-cors fetches |
| 07:14 | <annevk> | mkwst: it also helps as a long term defense when everyone has site isolation |
| 07:15 | <mkwst> | annevk: Less risky, certainly. *shrug* I'm happy for folks to ship implementations of this to see if developers pick it up. My suspicion is that we'll end up seeing more value in approaches with broader scope, but this is small enough that shipping it doesn't cost much. |
| 07:16 | <annevk> | Whenever we tightly couple stuff it seems it's less likely to be adopted because it requires changing all the things |
| 07:17 | <mkwst> | annevk: When you say that it should be part of CORB, do you mean it would be another way of triggering the blocking behavior? Or that it would influence the heuristics, similarly to `x-content-type-options`? |
| 07:17 | <annevk> | mkwst: another way of triggering a block |
| 07:18 | <mkwst> | Ok. So, the idea is that you'd compare the resource's origin to the requesting origin (without consideration of embedding contexts, etc), and block if there's no match? |
| 07:18 | <mkwst> | (for cross-origin, no-cors requests) |
| 07:18 | <annevk> | Yes |
| 07:19 | <mkwst> | Ok. I'll try to summarize my understanding of the thing on the thread. |
| 07:20 | <annevk> | And now we landed CORB in Fetch this would be a fairly trivial PR. I volunteered doing the work on it |
| 07:21 | Ms2ger | read "CORB in French" and was very confused |
| 07:23 | <annevk> | Ms2ger: "Blocage de lecture inter-origine" |
| 08:16 | <michael2> | hi all, does whatwg.org have a CSS spec? |
| 08:17 | <annevk> | michael2: there's two CSS-related ideas we host, but they're not living standards: https://idea.whatwg.org/ |
| 08:18 | <annevk> | michael2: they're also not really maintained as far as I'm aware |
| 08:19 | <michael2> | so would I need to browse w3c.org to find the CSS spec's? (1,2,3+) |
| 08:20 | <annevk> | michael2: I'd use https://drafts.csswg.org/ |
| 08:21 | <annevk> | michael2: those are also the documents the WHATWG links to |
| 08:21 | <annevk> | michael2: they're probably mostly identical to what ends up on w3.org, but might be a bit more recently updated |
| 08:22 | <michael2> | annevk: thats really helpful (alot of reading there) thank you :) |
| 08:53 | <JakeA> | annevk: is something in particular blocking [Cached] in idl? If so we could instead add something to infra like "Return the cached result of these steps" |
| 08:54 | <annevk> | JakeA: IDL is lacking resources |
| 08:54 | <annevk> | JakeA: I don't think anything is blocking that work |
| 08:56 | <annevk> | JakeA: it could maybe work in Infra; I guess it could create a unique slot on this and store the result of running the steps there if it's empty and otherwise return the value of the unique slot |
| 08:56 | <annevk> | JakeA: though I guess creating the unique slot is the problem, but we could hand-wave it perhaps |
| 08:57 | <JakeA> | annevk: The context object could have a map, where the key is the steps and the value is the cached value. But I'm not sure how to decide if it'd be better as an idl thing or a prose thing |
| 09:01 | <annevk> | JakeA: IDL is somewhat better as just like it can generate the spec code for us, it can generate the impl code too |
| 09:01 | <annevk> | JakeA: e.g., Firefox supports a variant of Cached already iirc |
| 09:01 | <JakeA> | Gotcha. Yeah that makes sense |
| 09:32 | <domfarolino> | annevk: It seems like subresource requests from an <iframe referrerpolicy=xxx></iframe> don't inherit the frame's referrer policy in Chrome/FF. Want to confirm with you that the rp should be inherited, due to steps in Main Fetch that use a request's client's referrer, right? |
| 09:34 | <annevk> | domfarolino: looking at it now, I'm not sure there's actually anything that takes that referrerpolicy attribute value and installs it on the loaded document or its global |
| 09:35 | <annevk> | domfarolino: it seems to be just used for the load triggered by src="" |
| 09:36 | <domfarolino> | annevk: Hmm, but don't we set request's client to a node doc's Window's environment settings object when fetching things like <img> etc? |
| 09:36 | <domfarolino> | And since environ settings obj has a referrer policy, Main Fetch should "inherit" it? |
| 09:37 | <annevk> | domfarolino: yes |
| 09:37 | <annevk> | domfarolino: but the referrer policy of the environment settings object of a thing loaded in an <iframe> is just the default value |
| 09:38 | <annevk> | domfarolino: as things stand today (well, unless you set a referrer-policy via a header) |
| 09:38 | <annevk> | (or <meta name=referrer>) |
| 09:38 | <domfarolino> | annevk: but that's not the case if <iframe referrerpolicy=origin> etc right? |
| 09:39 | <annevk> | domfarolino: it is the case is what I'm saying |
| 09:39 | <annevk> | domfarolino: again, there's nothing that transfers that value to the environment settings object's referrer policy of the loaded thing |
| 09:44 | <domfarolino> | annevk: Ah. So an <img>'s node document's Window's environment settings object's referrer policy is the default, regardless of the surrounding iframe |
| 09:47 | <annevk> | domfarolino: let me put it differently |
| 09:47 | <annevk> | domfarolino: the referrer policy of the environment settings object can be only be set through <meta name=referrer> or the Referrer-Policy header |
| 09:48 | <annevk> | domfarolino: there's on inheritance from ancestors and there's no controlling it with <iframe referrerpolicy> either; again, afaict from the algorithms in the HTML Standard |
| 09:54 | <domfarolino> | annevk: Ok that makes sense now, I appreciate it. |
| 09:55 | <annevk> | domfarolino: it might make sense to do that though, but it'd be a bit of work and we'd have to figure out various details |
| 09:57 | <domfarolino> | I guess when reading https://github.com/whatwg/html/issues/3670#issuecomment-387307670, I was assuming that the "global state" was the environment settings object...and the creation of an <iframe referrerpolicy=xxx> set the "iframe's environment settings object's referrer policy", and this settings object was used as subresource request clients |
| 09:58 | <domfarolino> | Bad assumption :( But yes, I kind of like that idea of somehow sharing that around more easily w/ subresources |
| 10:00 | <annevk> | domfarolino: well, I was wrong there as I assumed that <iframe referrerpolicy> did the thing you were looking for |
| 10:00 | <annevk> | domfarolino: global definitely is 1:1 with settings objects |
| 10:01 | <annevk> | domfarolino: so, sorry for causing confusion and not checking how referrerpolicy operated first |
| 10:06 | <domfarolino> | annevk: no worries, I made some heavy inferences |
| 10:08 | <domfarolino> | annevk: So the client that is a request's client for requests made within an <iframe> will be the <iframe>'s environment settings object though, we just don't set that object's referrer policy with anything but the header and the meta tag |
| 10:15 | <yoav> | Hey! I'm looking at nested browsing contexts with iframe srcdoc documents, and where it is defined that they inherit the SW from the parent browsing context |
| 10:16 | <yoav> | basically, I want to align Chromium's behavior with https://bugzilla.mozilla.org/show_bug.cgi?id=1426979 |
| 10:16 | <yoav> | (and testing shows that Safari is the same as Firefox) |
| 10:18 | <annevk> | domfarolino: it's the <iframe>'s child browsing context's active document's relevant settings object, or some such |
| 10:19 | <annevk> | yoav: I think part of the reason the bug you pinged is still open is because it's not defined |
| 10:19 | <annevk> | yoav: the issue you pinged* |
| 10:20 | <yoav> | annevk: yeah, it wasn't clear to me if it was defined elsewhere in the meantime |
| 10:24 | <yoav> | annevk: so IIUC, in order to define that, I'd need to say that a nested browsing context which has an active document which is an iframe srcdoc document has the same active service worker as the settings object of its parent browsing context? |
| 10:24 | <yoav> | (many concepts that I never dove into before, so bare with me if I'm totally off) |
| 10:28 | <annevk> | yoav: yeah, though I'm not sure that's good enough for the spec (since you also need to say something about time, unless it always inherits somehow) |
| 10:29 | <yoav> | annevk: can you expand on "something about time"? When it inherits it? |
| 10:29 | <annevk> | yoav: a big problem here is that part of the HTML spec is full of technical debt; document/global creation is really poorly done, which makes these kind of things hard to define (and probably why they're always causing problems) |
| 10:30 | <annevk> | yoav: yeah; e.g. if the parent gained a service worker later on, would that be used? |
| 10:30 | <yoav> | ok, got it |
| 10:30 | <yoav> | fwiw, I think it should |
| 10:31 | <annevk> | yoav: yeah, seems like that's what you'd want |
| 10:31 | <annevk> | yoav: this should apply to about:blank too btw; they should be identical imo |
| 10:32 | <yoav> | are people embedding about:blank? Or is that a theoretical case? |
| 10:32 | <annevk> | yoav: whenever you create an <iframe> you are, so yes |
| 10:33 | <annevk> | (and no) |
| 10:33 | <yoav> | oh... |
| 10:33 | <yoav> | got it |
| 10:57 | <annevk> | JakeA: FWIW, I suspect a longer form explanation of why non-HTTPS is a problem and the diff between long and safe would help a lot of people |
| 10:57 | <JakeA> | annevk: hah, just in the middle of writing a tweet about that. Yeah, I wish the article had made that clear. |
| 10:58 | <annevk> | secure/safe, not long |
| 11:03 | <JakeA> | https://twitter.com/jaffathecake/status/997431630011752449 |
| 13:02 | <annevk> | foolip: I think I found a better way to insert a newline with sed |
| 14:17 | <JakeA> | annevk: https://dom.spec.whatwg.org/#context-object - when could the context object be omitted? Trying to think of an example |
| 14:17 | <JakeA> | If an object has an associated 'thing', can I just say "Get the associated thing" in a getter? |
| 14:18 | <JakeA> | I usually write "Let whatever be the context object's thing" |
| 14:20 | <annevk> | JakeA: I prefer always including it these days |
| 14:20 | <JakeA> | annevk: Context: I'm looking at https://notifications.spec.whatwg.org/#dom-notification-actions step 2, where it comes up with "in the notification's" |
| 14:20 | <JakeA> | Same. Gotcha. |
| 14:20 | <annevk> | JakeA: also, this is another thing where IDL needs updating so we can all start using "this" instead |
| 14:22 | <JakeA> | Ta |
| 14:23 | <annevk> | JakeA: https://github.com/whatwg/dom/pull/647 |
| 14:26 | <JakeA> | LGTM |