| 05:00 | <annevk> | Zegnat: haven’t seen anyone run into that yet |
| 05:00 | <annevk> | espadrine wants sandboxing |
| 08:09 | <annevk> | mkwst: FWIW, I think we discussed expanding Origin some years ago too and concluded it wasn't feasible |
| 08:10 | <annevk> | mkwst: but as with From-Origin, we can repeat it a few times I suppose 😃 |
| 08:10 | <annevk> | mkwst: I strongly suspect that if you include it for GET servers will assume CORS and hickup |
| 08:11 | <mkwst> | annevk: *shrug* I haven't had enough coffee yet this morning, so I wouldn't be surprised if it's a bad suggestion. But I'd prefer to expand something that already exists if possible, rather than introducing a new thing. |
| 08:14 | <annevk> | mkwst: also, for an ad-hoc defense From-Origin seems far easier to deploy at scale to protect users of many sites quickly |
| 08:16 | <mkwst> | annevk: It certainly requires less server-side logic for a static policy (e.g. "This endpoint is mine, mine, mine, go away everyone else!"). I'm not sure it's any simpler for a policy with more interesting rules, but maybe those are few and far between. |
| 08:18 | <mkwst> | To be clear: I'm not opposed to `from-origin` per se. Among other advantages, I think getting folks on board with shipping it would make it easier for me to come back to the Entry Point Regulation proposal we floated a few years ago. *shrug* I'd like to make sure we explore other options before shipping something, but I think the problem space is totally worth poking at. |
| 08:58 | <fergal_daly> | can anyone point me to what powers the spec diffs, e.g. https://whatpr.org/html/3566/be2f5df...e0567b2/interaction.html |
| 08:58 | <fergal_daly> | ? |
| 09:00 | <annevk> | fergal_daly: https://github.com/tobie/pr-preview |
| 09:00 | <annevk> | fergal_daly: though note that for HTML it's a specialized setup |
| 09:01 | <annevk> | fergal_daly: and for WHATWG in general it's a bit special, since we have our own domain to host these things on |
| 09:13 | <fergal_daly> | thanks |
| 12:46 | <nox> | annevk: Can I borrow your brain for a second? |
| 12:46 | <nox> | I'm getting confused by the wording in https://www.khronos.org/registry/webgl/specs/latest/2.0/#3.7.3 |
| 12:46 | <nox> | Specifically: "If srcData is a DataView, let copyLength be srcData.byteLength - srcOffset; the typed elements in the text below are bytes. Otherwise, let copyLength be srcData.length - srcOffset." |
| 12:46 | <nox> | Why does it matter whether srcData is a DataView or not? |
| 12:48 | <annevk> | nox: is that the normative prose? |
| 12:49 | <annevk> | Wow, looks like it might be |
| 12:49 | <nox> | annevk: AFAIK yes, that's the only prose using JS terminology in the whole stack. |
| 12:49 | <nox> | annevk: That spec is… not as good as it could be. |
| 12:50 | <annevk> | nox: DataView only has byteLength |
| 12:50 | <nox> | annevk: Oh I see. |
| 12:51 | <annevk> | nox: so .length would be undefined, but that they're branching on public getters is rather nuts |
| 12:51 | <annevk> | nox: and not at all how impls work |
| 12:51 | <nox> | :D |
| 12:52 | <nox> | annevk: I like how it totally ignores any under or overflow too. |
| 12:52 | <nox> | What could go wrong? |
| 12:53 | <annevk> | nox: don't tell Waldo |
| 12:53 | <annevk> | nox: but maybe do tell Waldo |
| 12:53 | <nox> | About which part specifically? |
| 12:54 | <annevk> | nox: bound checks; though maybe by now we've found all security issues with ArrayBuffer |
| 12:54 | <annevk> | It's also worth asking for a better specification, but I wonder if we're going to get it |
| 12:54 | <annevk> | (not from Waldo that last one) |
| 12:55 | <nox> | annevk: Isn't ArrayBuffer only for arrays of bytes? |
| 12:55 | <nox> | Confused about "If srcData is a DataView, set the size of buf to copyLength; otherwise, set the size of buf to copyLength * srcData.BYTES_PER_ELEMENT. " |
| 13:04 | <annevk> | nox: ArrayBuffer is for bytes, but views on top of it are generally not |
| 13:04 | <nox> | annevk: So can ArrayBufferView be backed by something that isn't for bytes? |
| 13:04 | <annevk> | nox: I think that one makes sense; e.g. if you had a float32array its elements would be 4 bytes each |
| 13:05 | <annevk> | nox: you cannot |
| 13:05 | <nox> | annevk: So it doesn't make sense, right? |
| 13:05 | <nox> | The method takes a `[AllowShared] ArrayBufferView srcData`. |
| 13:06 | <annevk> | nox: ArrayBufferView is a typed array object, backed by an ArrayBuffer |
| 13:07 | <annevk> | (or SharedArrayBuffer in some parallel universe where that's still a thing) |
| 18:35 | <Domenic> | domfarolino: FYI I've made all workstream editors able to edit https://github.com/whatwg/participant-data (e.g. to verify people). |
| 18:36 | <Domenic> | That's how it was supposed to be since the beginning, but we forgot |
| 18:36 | <domfarolino> | This is great, thank you! |
| 18:52 | <domfarolino> | Are browsers allowed to display content above a body-ok <link rel=stylesheet> *even* before a parser-blocking script below the <link> is ran? |
| 18:53 | <domfarolino> | It seems in Chrome/Firefox, parser-blocking scripts do not delay the first paint when they come after a body-ok link and i can't find in the spec where this might be specified |
| 19:07 | <Domenic> | This reminds me of some bug about non-interoperability here... |
| 19:08 | <Domenic> | I guess it's not really specified when browsers are allowed to display content at all? |
| 19:08 | <Domenic> | https://github.com/whatwg/html/issues/3355 was probably what I was thinking of |
| 19:08 | <Domenic> | Oh or https://github.com/whatwg/html/issues/1349 |
| 19:16 | <domfarolino> | Interesting, checking those out thanks. Before I saw ^^, I found https://jakearchibald.com/2016/link-in-body/ which does mention Chrome switching to allow rendering before a body-ok stylesheet (though DOMContentLoaded is still blocked) |
| 21:15 | <Domenic> | I think I'm achieving some level of bz-ness: https://github.com/w3c/payment-handler/issues/263#issuecomment-373734422 |
| 21:17 | <wanderview> | Domenic++ |
| 21:17 | <gsnedders> | Domenic: hello, new AI overlord |
| 21:27 | <jsbell> | ha! |