| 02:22 | <sideshowbarker> | Domenic: I don’t disagree. But as far as the MDN side goes, a specific problem we chronically run into is that historically (and still) we have only had Deprecated and Obsolete flags. The current policy is to completely stop using Obsolete flag and only use the Deprecated flag. But if we mark a feature as Deprecated when the relevant spec doesn’t actually indicate that feature is deprecated, then we get reports from (sometimes angry) developers who somewhat-rightly take issue with MDN saying that something’s deprecated when it’s actually not. |
| 02:23 | <sideshowbarker> | The solution I support for that is:
…for reasons outlined in https://github.com/mdn/content/discussions/5549#discussioncomment-814689 |
| 02:38 | <sideshowbarker> | I like Legacy but also be happy to see some accompanying “discouraged” language where appropriate. Commented to say as much over at https://github.com/tc39/ecma262/pull/2441/files#r704904382 |
| 02:45 | <sideshowbarker> | Historically HTML in particular has given a lot of attention to what authors ought to do seperate to what works (the entire concept of a "valid" document). So it's very understandable that people would expect it to continue doing so, and that they take lack of negative indicators as implicit endorsement. |
| 02:48 | <sideshowbarker> | But given the reasons Domenic mentioned at https://matrixlogs.bakkot.com/WHATWG/2021-09-08#L40, it seems it might be more difficult to articulate some consistent rationale than it is for the markup case. |
| 06:29 | <annevk> | miketayl_r: I think a web developer should be able to read a spec directly if they want and I also think that information in a specification addressed to them should be focused if possible (i.e., not introduce multiple ways of doing the same thing when one suffices), but I realize that is somewhat idealized |
| 06:48 | <Ms2ger 💉💉> | sent an image. |
| 08:54 | <annevk> | I think at the time that note was added the other properties were not uniformly supported. Perhaps at this point it doesn't matter, but it still seems preferable for everyone to align on one of them. |
| 08:58 | <Ms2ger 💉💉> | "This one is more widely supported" seems like a useful note. I guess I just don't see the value in practice of the alignment |
| 08:58 | Ms2ger 💉💉 | returns to work |
| 10:36 | <Jake Archibald> | annevk: I'm planning on adding 'origin' to history entries, so when a document is brought back to life it'll use the same origin as it did before, unless something happens which changes the origin along the way, such as a redirect to another origin. This should cater for things like |
| 10:36 | <Jake Archibald> | Does that make sense? |
| 10:43 | <annevk> | I wonder if we should only do that for cases where we cannot derive it from elsewhere to avoid accidental dependencies. Do we have many other cases besides about:blank? smaug ^^ |
| 10:48 | <Jake Archibald> | I can't remember exactly what data/blob URLs do here. I know they're an 'opaque' origin, but does that mean all storage is blocked, or is a temporary origin created? |
| 10:53 | <Luca Casonato> | storage is blocked |
| 10:53 | <Luca Casonato> | data:text/html,<script>try { localStorage.setItem("foo", "foo") } catch(err) { alert(err) }</script> |
| 11:01 | <Jake Archibald> | There's srcdoc, but I guess you could always get the origin from the parent in that case |
| 11:10 | <annevk> | Jake Archibald: blob URLs get their origin from the blob URL store (definitely not always opaque) |
| 11:20 | <Jake Archibald> | If it's just about:blank then I agree it should be special-cased |
| 11:25 | Jake Archibald | starts thinking about document.domain |
| 11:58 | <annevk> | Jake Archibald: I think in the case where you navigate to something again that isn't in bfcache, you wouldn't want things like a document.domain set to be restored, although maybe you do for about:blank? Not sure there is a correct answer here. History is hard. |
| 11:59 | <Jake Archibald> | It doesn't seem like document.domain is restored |
| 11:59 | <Jake Archibald> | But, I think apphistory needs history entries to have an origin to it knows which entries are same-origin. |
| 11:59 | <annevk> | Though note that the origin about:blank inherits could be a document.domain-type origin. |
| 12:01 | <Jake Archibald> | That didn't seem to be the case in a quick test I did in Chrome. Although it could be different in other browsers |
| 12:01 | <Jake Archibald> | haha this stuff is all so messy |
| 12:02 | <annevk> | Jake Archibald: if the parent sets document.domain and then you create the about:blank child, how could it not inherit it? |
| 12:02 | <Jake Archibald> | hmm, I see what you mean |
| 12:02 | <annevk> | The child ends up being cross-origin? Or after navigating the child and then going back it's cross-origin? |
| 12:03 | <Jake Archibald> | testing again… |
| 12:03 | <Ms2ger 💉💉> | * starts thinking about |
| 12:05 | <annevk> | As for your question, it seems you could mainly use URLs for determining same-origin-ness, except for sandboxing cases and document.domain. Ignoring document.domain for this seems fine, sandboxing is unclear. But sandboxing is also something that could change if the entries are not bfcache-backed. |
| 12:06 | <Jake Archibald> | There's an open question on whether the sandbox stuff should be in the history entry |
| 12:06 | <Jake Archibald> | I still think we should cycle the iframe browsing context when sandboxing changes |
| 12:06 | <Jake Archibald> | (or, the navigation after sandboxing changes) |
| 12:07 | <Jake Archibald> | Is there an API that gives me the origin of a document? |
| 12:07 | <annevk> | I suspect we don't want to take sandboxing into account for same-origin-ness though. |
| 12:07 | <annevk> | Jake Archibald: self.origin |
| 12:08 | <Jake Archibald> | self.origin doesn't update with document.domain |
| 12:08 | <annevk> | Jake Archibald: document.domain things you can only reveal through script access and such |
| 12:08 | <Jake Archibald> | gotcha |
| 12:10 | <annevk> | Because if you go from /a to /b to /c initially, we'd consider those all same-origin. If /b happens to be sandboxed, it'd be weird if the navigation to /c and going back to /a would suddenly be seen as cross-origin I think. |
| 12:11 | <Jake Archibald> | /c to /a wouldn't be cross-origin, but /a to /b would be, right? |
| 12:13 | <annevk> | Jake Archibald: sorry, I meant if you navigate to /b (which you then discover to be sandboxed) and then go to /c or back to /a. |
| 12:15 | <Jake Archibald> | annevk: navigating from an opaque origin would always be a cross origin navigation, no? |
| 12:17 | <annevk> | Jake Archibald: yeah, true, I'm not sure what to make of this. Is app history even available on opaque origins? |
| 12:20 | <Jake Archibald> | annevk: Good question. I assumed yes, but it'd have no visibility of other entries since they're other-origin both forwards and back. I think history entries need an origin with app history because: /a to (same origin blob url) to /c - the final page should have visibility into the two history entries before it because they're contiguously same origin, even if the blob url is revoked. Domenic does that make sense? |
| 12:22 | <annevk> | A same-origin blob URL always has the origin in the URL itself, so even if it's revoked you get it. See also https://url.spec.whatwg.org/#origin. |
| 12:23 | <Jake Archibald> | ah, fair enough |
| 12:23 | <annevk> | Ah, except in the case where an opaque origin minted the blob URL. You could then get a blob URL that's same-origin with the opaque origin. But at that point I guess the question that's important is whether we want to support opaque origins at all. |
| 12:24 | <Jake Archibald> | I forgot that blob urls have an origin in them |
| 12:25 | <annevk> | (One oddity here is that while (same origin blob url) can have the same origin as /a, if it's revoked traversing to it will result in a document with an opaque origin (network error).) |
| 12:26 | <Jake Archibald> | Yeah, but redirects can happen too |
| 12:26 | <Jake Archibald> | there's no guarantee that a history entry will be the same origin when you traverse to it |
| 12:27 | <Jake Archibald> | hm, wait, I see what you mean |
| 12:27 | <Jake Archibald> | is it now an opaque origin history entry |
| 12:27 | <Jake Archibald> | that's an interesting question for app history in general |
| 12:35 | <Jake Archibald> | Ah ok, now I think it through, I don't think network error pages would change the origin of the history entry, in the same way it wouldn't change the referrer or form state |
| 12:39 | <annevk> | Yeah, didn't mean to send you astray |
| 13:04 | <annevk> | Jake Archibald: I realized just now that SVGOMG doesn't remove the version attribute |
| 13:07 | <Jake Archibald> | annevk: huh, it does on the demo image |
| 13:08 | <annevk> | Jake Archibald: view-source:https://resources.whatwg.org/logo-testutils.svg is my test |
| 13:09 | <annevk> | I've used your tool to optimize some of the new logos I created, but looking at the new SVGOMG today I realized it still had the version attribute |
| 13:15 | <Jake Archibald> | @annevk aha, so SVGO removes attributes that are set to their 'default', and it has the default as '1.1' |
| 13:15 | <Jake Archibald> | I'll file an issue with them |
| 13:16 | <annevk> | Jake Archibald: ah I see, I'm pretty sure browsers ignore this attribute completely |
| 13:18 | <miketayl_r> | miketayl_r: I think a web developer should be able to read a spec directly if they want and I also think that information in a specification addressed to them should be focused if possible (i.e., not introduce multiple ways of doing the same thing when one suffices), but I realize that is somewhat idealized |
| 14:48 | <annevk> | Domenic: what prevents a CSS module script from working in a worker? It seems the standard doesn't branch anywhere at the moment. |
| 14:48 | <annevk> | Domenic: this was one of the things I raised in https://github.com/tc39/proposal-import-assertions/pull/111. |
| 14:48 | <annevk> | dandclark: ^^ |
| 14:49 | <annevk> | Never mind, I see now:
|
| 14:51 | <annevk> | Which I guess means things are being fetched still. |
| 15:10 | <Domenic> | Which I guess means things are being fetched still. |
| 15:12 | <annevk> | Yeah, I think it makes more sense that we claim it's not supported when we do the type check, similar to how you are proposing the new method to work. I'll file. |
| 15:45 | <annevk> | Jake Archibald: so if opaque origins cannot access app history, we could maybe not take sandboxing into account for the same origin check; sandbox + allow-same-origin could then participate fully, and sandbox without that would create a same origin entry, but wouldn't be able to look at entries itself |
| 15:46 | <annevk> | Jake Archibald: I think that also covers the error pages. The error pages do not get access (and cannot modify presumably), but they continue to be in the session history of the respective origin. |
| 15:51 | <Jake Archibald> | annevk: I don't think sandboxed pages can be same-origin for apphistory. Eg, if an opaque origin page does a replaceState type thing, isn't it a cross-origin leak to expose that new URL and state object to the other pages? |
| 15:52 | <annevk> | Jake Archibald: I meant sandbox + allow-same-origin |
| 15:53 | <Jake Archibald> | annevk: "sandbox without that would create a same origin entry" that's the bit I don't think works |
| 15:53 | <annevk> | Jake Archibald: ah, there's the legacy history APIs too |
| 15:54 | <Jake Archibald> | annevk: I think the issue is with the new APIs, but maybe I'm missing something |
| 15:54 | <annevk> | Jake Archibald: I was thinking that opaque origins wouldn't have access to session history |
| 15:55 | <annevk> | Jake Archibald: in such a setup, it would be okay if they were same origin for the purposes of session history, I think |
| 15:55 | <annevk> | Jake Archibald: but history.friends breaks it |
| 15:55 | <Jake Archibald> | annevk: or just a hash navigation |
| 15:56 | <Jake Archibald> | If an opaque origin page navigates to #super-secret, the non-opaque pages shouldn't be able to see that |
| 15:57 | <annevk> | Yeah, I don't really want to special case error pages and such though. Ideally they'd follow the same model. |
| 16:02 | <annevk> | I guess I'd be okay with network errors being somewhat weird as they are also somewhat unusual (and you could use a service worker if you worry about them). |
| 16:03 | <Jake Archibald> | annevk: yeah, there are other special cases that I don't think the current spec handles. Eg, error documents must always be discarded when traversing away. |
| 16:04 | <annevk> | Jake Archibald: ah, so that means we don't have to store an origin for them as they go away |
| 16:05 | <annevk> | Jake Archibald: but we'd have to store an origin for sandbox without allow-same-origin |
| 16:05 | <Jake Archibald> | annevk: agreed |
| 16:06 | <Domenic> | annevk: to confirm, you are OK with Firefox following Chrome's behavior for redirects to data:/etc., of an error page for both top-level and iframes? Instead of Firefox's behavior of staying on the current page sometimes? |
| 16:09 | <annevk> | Domenic: yeah |
| 16:41 | <GPHemsley> | annevk: We're finally getting somewhere https://wpt.fyi/results/mimesniff/mime-type-sniffing?pr=30403 |
| 17:14 | <annevk> | Oh wow, that's so cool. Thanks for working on that! |
| 17:53 | <GPHemsley> | (turns out there are lot of places where nobody's following the spec...) |
| 19:34 | <GPHemsley> | annevk: Do we know if there's a comprehensive list of MIME types that UAs must support? |
| 19:44 | <GPHemsley> | (where "support" is loosely defined as "not prompt for download or otherwise redirect to another external app") |
| 21:11 | <miketayl_r> | [text/jscript] |
