| 00:35 | <gregwhitworth> | Domenic: even though that ended up not being the case for option, mind sending me an event example for another element so I know what to look for. Thanks :) |
| 03:50 | <MikeSmith> | annevk: I edited https://wiki.developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts to make a number of refinements to align it with the Secure Contexts spec. Please review and let me know if it looks OK or if you have suggestions for further refinements or corrections. |
| 04:02 | <annevk> | gregwhitworth: it could be some kind of activation behavior I suppose; but yeah, mouse events are not really defined, hit testing is not defined, and the select popup box is not defined |
| 04:06 | <annevk> | MikeSmith: it might be better to say top-level document as the browsing context can contain both secure and insecure contexts; it strikes me that “context” was a poor word choice for this feature |
| 04:06 | <annevk> | MikeSmith: also maybe make mitm say monster-in-the-middle |
| 04:14 | <annevk> | MikeSmith: thanks for fixing it up! |
| 05:12 | <MikeSmith> | annevk: so I actually replaced some instances of “top-level document” which had been in that article — because neither HTML nor Secure Contexts defines “top-level document” |
| 05:12 | <MikeSmith> | so now I’m unsure how to word it in order to align it with how the specs actually define things |
| 05:13 | <annevk> | MikeSmith: you could also top-level browsing context's active document |
| 05:13 | <MikeSmith> | ah yeah |
| 05:13 | <annevk> | MikeSmith: but the thing to keep in mind is that a browsing context doesn't have authority |
| 05:13 | <MikeSmith> | oh really? |
| 05:13 | <annevk> | (even though HTML sometimes incorrectly makes it look like it does) |
| 05:14 | <annevk> | MikeSmith: it doesn't have an origin, it represents a sequence of documents that can all have different origins |
| 05:14 | <MikeSmith> | well that’s hard to tell from the Secure Contexts spec as well |
| 05:14 | <MikeSmith> | aha yeah |
| 05:14 | <annevk> | I'm not surprised |
| 05:15 | <MikeSmith> | yeah you were able to explain it clearly in a couple sentences |
| 05:15 | <MikeSmith> | so I wish the Secure Contexts spec could be refined to state it in similar terms |
| 05:16 | <MikeSmith> | anyway for now I’ll make another update to the MDN article |
| 05:31 | <gregwhitworth> | annevk: thanks. "select popup box is not defined" This is something we're actively looking into however, which is one way in which this was interop gap difference was found |
| 05:37 | <annevk> | gregwhitworth: makes sense, filing an issue against whatwg/html for the click/activation behavior on option might be worth doing |
| 05:38 | <gregwhitworth> | sounds good - let me get the Open UI group aligned a bit on the event mapping so it's a bit more clear. Also, I'd like to extend the invite because the Open UI discussions will propagate to WHATWG for web platform changes at some point |
| 05:41 | <gregwhitworth> | https://github.com/WICG/open-ui/ |
| 15:13 | <Domenic> | Is PR preview just broken for all Bikeshed specs now, or only WHATWG ones, or...? |
| 15:17 | <annevk> | Domenic: all Bikeshed it seems |
| 15:17 | <annevk> | https://github.com/tobie/pr-preview/issues/67 |
| 16:01 | <annevk> | noamr: I'd like to talk to heycam a bit; it might actually be better if EXIF wasn't exposed for opaque images at all (or treated as if not present); because making each caller do the correct origin check seems like a recipe for disaster |
| 16:02 | <noamr> | annevk: I see a risk there... people would enable CORS on image just for the sake of getting them to display correctly, exposing the image content to canvas |
| 16:03 | <noamr> | and what's the harm in making EXIF affect the orientation/resolution, if there's no CSS/markup way to override it? |
| 16:05 | <annevk> | noamr: I don't think we can guarantee there will never be such features, right? Would each such feature need to get a security check? |
| 16:06 | <noamr> | annevk: I think so, if the alternative is to cripple features that in themselves don't pose a security risk... |
| 16:07 | <annevk> | That doesn't really seem acceptable |
| 16:07 | <noamr> | I think the opaque image restrictions should be on the "overriding" features - like HTML attributes / CSS properties / JS, rather than on how images are handled by default |
| 16:08 | <annevk> | That's an extremely brittle design and will likely fail |
| 16:09 | <noamr> | (sorry for the inappropriate "cripple" colloquialism btw) |
| 16:12 | <noamr> | annevk: so are you suggesting to do the same re. EXIF orientation, and make it so that only same-origin/CORS-enabled images can use that feature? |
| 16:14 | <annevk> | Yeah |
| 16:21 | <annevk> | Domenic: sorry about that, my commit had a green checkmark so I assumed it was in order |
| 16:21 | <annevk> | Domenic: it seems Travis is kinda lagging or something |
| 16:34 | <noamr> | thanks for the clarifications and patience, annevk. waiting to see what more people have to say on https://github.com/w3c/csswg-drafts/issues/5165 :) |
| 16:40 | <annevk> | noamr: you should share your concern as well, though I hope we can avoid a Cross-Origin-Expose-Image-Metadata |
| 16:40 | <annevk> | ah you did already |
| 17:35 | <TimothyGu> | yay, class strings on interfaces finally got fixed on every browser https://wpt.fyi/results/WebIDL/ecmascript-binding/class-string-interface.any.html?label=experimental&label=master&aligned |
| 17:45 | <andreubotella> | annevk, Domenic: I'm working on the conversion algorithms between token queues (a.k.a "Encoding streams") and strings/byte sequences, and I'm not sure what to do with the dfns |
| 17:45 | <andreubotella> | I can't have four algorithms named <dfn for="token queue">convert</dfn> |
| 18:01 | <Domenic> | andreubotella: quick answer between meetings without me looking at the spec to confirm in makes sense: you can put arbitrary strings in for="", so you could have for="token queue to X", for="token queue to Y", etc. It's not reader-visible (except maybe in the autogenerated IDs) |
| 18:02 | <andreubotella> | Yeah, that might work |
| 18:02 | <andreubotella> | thanks |
| 18:05 | <annevk> | TimothyGu: cool, I guess that means we can check it in idlharness now |
| 18:06 | <annevk> | Yeah, for=“” is the best |
| 18:06 | <TimothyGu> | Indeed, though iterator objects are still inconsistent |