| 13:53 | <annevk> | domfarolino: thanks! |
| 13:56 | <noamr> | Hi annevk! I'm not seeing responses on the cross-origin EXIF concern (https://github.com/w3c/csswg-drafts/issues/5173), so I'm feeling blocked with EXIF resolution (https://github.com/whatwg/html/pull/5574). any suggestions? |
| 14:00 | <annevk> | noamr: reach out to implementers? |
| 14:01 | <noamr> | annevk: Chrome and WebKit said yes on github. I'm planning to write the patches for both. |
| 14:03 | <annevk> | noamr: to my solution for addressing the cross-origin leak? |
| 14:03 | <annevk> | noamr: or how to reorganize how we deal with images? |
| 14:03 | <noamr> | ah, no. they responded to the EXIF-resolution thingy. |
| 14:08 | <noamr> | oh ok I see - you wanted to have the issue more blocked on the general "images on the web" issue rather than on the cross-origin issue. I got those two issues mixed up. I'll see if I can ping some people at Blink/webkit to pitch in on https://github.com/w3c/csswg-drafts/issues/5173 |
| 14:10 | <annevk> | noamr: well both are important, but the security one we should have an answer one at least as that impacts tests and impl and observable behavior |
| 14:12 | <noamr> | annevk: I believe it doesn't impact observable behavior, tests and implementation for EXIF-resolution, as it's not yet exposed/overridable (until we implement CSS image-resolution). |
| 14:13 | <annevk> | noamr: but we couldn't add that point decide on a change of model |
| 14:13 | <annevk> | at that point* |
| 14:19 | <noamr> | you mean for the cross-origin issue? Seems like there was some consensus on that, at least between the three people that commented on the issue. |
| 14:19 | <noamr> | I'm not sure how to put it into the spec though - currently the EXIF resolution proposal doesn't expose that metadata, unlike https://github.com/whatwg/html/pull/5603, so I don't know how to add a clause that says that that information should not be exposed for opaque resources... |
| 14:20 | <annevk> | noamr: fair; I guess what I'm looking for is agreement from WebKit/Blink on the model |
| 14:21 | <annevk> | noamr: well, and it does impact orientation so it does impact existing implementations and they might want something else therefore; which is why having this be a bit more explicit would help |
| 14:21 | <annevk> | It's important to keep the whole picture in mind |
| 14:22 | <noamr> | it affects future implementation as currently orientation is also an implementation detail (not exposed via CSS or attributes) |
| 14:23 | <noamr> | (CSS image-orientation is not a thing yet) |
| 14:23 | <annevk> | noamr: image-orientation:none is a thing afaik |
| 14:24 | <noamr> | hmm ok then. thanks annevk |
| 16:24 | <rosenjcb> | So I was reading over the first version of the DOM spec and I notice that the entire thing is defined with interfaces and an "object oriented" approach. Though in the article "What is the Document Object Model?", it says that "[The DOM] can be implemented in any computing environment and does not requrie the object binding runtimes generally associated with such IDLs." Does that mean we don't even necessarily need to use an OO |
| 16:24 | <rosenjcb> | approach? Could my DOM just be data structures and free functions? |
| 16:35 | <domfarolino> | annevk: Could you give a review for the iframe lazyload PR? I think it's ready to be thoroughly reviewed, and personally I'd like to get it in soon if at all possible |
| 16:44 | <annevk> | domfarolino: not sure about this week, but next week starting Tuesday is probably doable |
| 16:44 | <domfarolino> | Thanks |
| 16:47 | <Domenic> | annevk: any thoughts on https://github.com/WICG/origin-isolation/issues/24#issuecomment-643507493 ? I'm unsure myself. |
| 16:48 | <annevk> | Domenic: continuing to return false seemed reasonable to me, despite the slight complexity increase |
| 16:48 | <Domenic> | OK, sounds good, so sticking with (2). |
| 16:49 | <annevk> | In particular given the idea that we only want to convey differences to the agent cluster boundary and document.domain (neither of which would change) |
| 16:52 | <Domenic> | Yeah, I mean the alternative with (3) is conveying "did you send the header and not get it overwritten by a previous header in the BCG". But probably conveying differences in agent cluster boundary is more useful. |
| 17:04 | <annevk> | Domenic: I ran my window.find() test in Chrome and it works there |
| 17:04 | <annevk> | Domenic: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A...test%0A%3Cscript%3E%0Aw(window.getSelection())%0Awindow.find(%22test%22)%3B%0Aw(window.getSelection())%0A%3C%2Fscript%3E |
| 17:04 | <Domenic> | annevk: oh no, is it platform-dependent too? |
| 17:04 | <Domenic> | I wish I had my Mac |
| 17:05 | <annevk> | Domenic: could be, but it works in Chrome/Firefox/Safari |
| 17:05 | <Domenic> | annevk: ah I see, I think focusing devtools changes window.getSelection() in Chrome but not in Firefox |
| 17:05 | <annevk> | Domenic: first logs Selection "", then Selection "test" |
| 19:23 | <domfarolino> | Domenic: regarding https://github.com/whatwg/html/pull/5579#issuecomment-644308355, did you mean changing the “referrerpolicy” attr shouldn’t cause a refetch |
| 19:23 | <Domenic> | domfarolino: ugh yes, I got it backward again. Will edit... |
| 19:24 | <Domenic> | Interesting, I guess that makes it slightly more consistent with iframes... |
| 20:01 | <domfarolino> | Domenic: Gotcha. I think I said it will cause a refetch because chrome’s memory cache also uses the referrerpolicy as a memory cache key (but technically that’s not specified) |
| 22:00 | <domfarolino> | Domenic: if you want we can hold off on merging |
| 22:00 | <domfarolino> | Domenic: If you want to add notes that point to the spec discussoin around the parser document checks |
| 22:00 | <domfarolino> | I'm fine either way though |
| 22:00 | <Domenic> | domfarolino: nah, I like merging; no need to present the historical context there I think. |
| 22:00 | <domfarolino> | Cool |
| 22:03 | <Domenic> | Very excited to close that off! |
| 22:03 | <Domenic> | Less cross-document script execution is better for everyone... |