| 08:48 | <noamr> | annevk: following the metadata/cors thing, I found a scenario where metadata resolution of image can be detected for cross-origin images even with the current patch, due to the behavior of srcset :( |
| 08:49 | <annevk> | noamr: interesting, did you document that somewhere? |
| 08:49 | <noamr> | annevk: https://github.com/whatwg/html/pull/5574#issuecomment-654100058 |
| 08:49 | <annevk> | zcorpan might be able to help out solutions-wise |
| 08:49 | annevk | looks |
| 08:51 | <annevk> | noamr: I guess what should happen there is that 2x will be interpreted as 4x per the rules I proposed |
| 08:51 | <noamr> | I'm beginning to think that both with this and with orientation, the metadata should be completely ignored unless there's either CORS or a new header similar Allow-Timing-Origin |
| 08:53 | <annevk> | Yeah, that's what I suggested initially and is rather attractive due to its simplicity |
| 08:54 | <noamr> | though it would create a thing where images sometimes rotate correctly and sometimes not, depending on who's presenting them |
| 08:54 | <noamr> | which is I guess is unavoidable anyway |
| 08:54 | <annevk> | Same with scaling |
| 08:54 | <noamr> | right |
| 08:55 | <noamr> | but it's unavoidable in a way. it's a matter of what's the default |
| 08:56 | <annevk> | To recap: the solutions we have for opaque-response images are 1) ignore metadata 2) use metadata when decoding and creating a bitmap and forget it afterwards |
| 08:57 | <noamr> | 1) would make images seem different for different embedders. 2) will make images seem different for different embedders under certain conditions only, such as the embedder using srcset or CSS image-orientation |
| 08:59 | <noamr> | (2) would maybe allow a nicer working "default" but would create somewhat of a set of intricate rules that's difficult to follow and may be subject to change. |
| 09:00 | <annevk> | Yeah, I'm also not entirely convinced about a new header for metadata btw. Metadata is data and especially if we decide to expose more image metadata over time (e.g., all of EXIF) it might not be a tradeoff folks are equipped to make well |
| 09:01 | <annevk> | 2 requires a particular implementation architecture to ensure stuff doesn't leak, which indeed may be tricky and error-prone. |
| 09:19 | <noamr> | maybe a header can be more specific, rather than about metadata, it would be about intrinsic geometry (orientation/preferred-size) |
| 09:22 | <annevk> | It's a bit of a slippery slope though. And also, some of the rotation values make it easy to determine an image is a selfie. I'm not sure that's the kind of thing people would think of though when deciding to expose it to help with rendering. |
| 09:27 | <noamr> | yea, I can see that. If we get some consensus behind the direction of blocking metadata for opaque-resource images, I can update my EXIF-resolution patch to do the right thing (probably option 1). |
| 12:39 | <zcorpan> | annevk: noamr: not extending capabilities of opaque cross-origin responses seems like a good strategy, though I haven't given it a lot of thought |
| 13:54 | <bradleymeck> | in https://mimesniff.spec.whatwg.org/#sniffing-a-mislabeled-binary-resource there is a warning about loading a scriptable mime type, but I don't see WASM/JS which now have `import` listed as scriptable even though they now can load scripts directly |
| 13:55 | <bradleymeck> | is there some more background on that call out? |
| 14:13 | <Domenic> | bradleymeck: loading those MIME types is not dangerous since they display as text/plain |
| 14:14 | <Domenic> | https://html.spec.whatwg.org/multipage/browsing-the-web.html#process-a-navigate-response step 5 |
| 14:14 | <Domenic> | Although wasm isn't handled explicitly; I'd imagine it ends up in one of the fallthrough cases |
| 16:16 | <annevk> | andreubotella: heya, I'm not sure I understand |
| 16:17 | <annevk> | andreubotella: if read were to return a blocking token, wouldn't that require us to update all callers to keep invoking read until it no longer does? |
| 16:17 | <andreubotella> | annevk: The idea was to have read block for some time, undefined by the spec, until the implementation got the next byte / scalar value from I/O. |
| 16:18 | <andreubotella> | the token's blocking-ness would be irrelevant once it was returned |
| 16:18 | <andreubotella> | but now that I've thought it over, this idea was probably not the best |
| 16:21 | <andreubotella> | As I said before, I was trying to keep the blockiness of read which was never explicit in the spec |
| 16:23 | <annevk> | andreubotella: another alternative might be to have a buffered queue and an I/O queue |
| 16:23 | <annevk> | andreubotella: and read blocks when operating on the latter |
| 16:23 | <annevk> | andreubotella: this would allow making callers more precise over time |
| 16:24 | <annevk> | andreubotella: and we'd say that I/O queue can only be used "in parallel" |
| 16:26 | <andreubotella> | annevk: Do we even want to have read block? Or is there no point in making it async when a page is being loaded? |
| 16:27 | <annevk> | andreubotella: it's fine for it to block if you run it in parallel |
| 16:28 | <annevk> | andreubotella: and I guess if we were to more formally define, say, the HTML parser, that's what we'd do |
| 16:28 | <annevk> | andreubotella: and then only tree construction we'd run on the main thread from tasks (which would also properly deal with mutation observers, script execution, custom elements, and such) |
| 16:29 | <annevk> | andreubotella: other kinds of things that decode I/O streams can similarly be run in parallel from the main thread, afaik |
| 16:30 | <andreubotella> | I was thinking that for the encoding sniffing algorithm, say, there's not much point in waiting for the 1024 bytes off the main thread, since there's not much else for the thread to do while the page is loading |
| 16:30 | <andreubotella> | but for everything else it must be run in parallel |
| 16:31 | <andreubotella> | but that distinction can be refined later on |
| 16:32 | <annevk> | andreubotella: well, while a new document is being loaded, the old document is still active, we wouldn't want to block it |
| 16:32 | <andreubotella> | hm, right |
| 16:32 | <andreubotella> | I'm not as familiar with those parts of the HTML spec |
| 16:33 | <annevk> | If we find a case where we need to block the main thread on I/O I guess we could remove the "in parallel" requirement, but I doubt we will as it seems like a bug |
| 16:36 | <andreubotella> | So I think I'll close that PR and wait for #215 to be merged before opening another one with those changes |
| 16:36 | <andreubotella> | Especially since it gets hard to talk about a concept while we're bikeshedding its new name |
| 20:56 | <zeroed> | Dear Editors, thank you so much for your incredible work on url.spec.whatwg.org |