| 00:37 | <sideshowbarker> | Help wanted / Good first issue: For anybody interested in contributing to the HTML standard, https://github.com/whatwg/html/issues/1102 might be a good issue you could resolve, by writing a spec patch for it with a modest amount of effort — perhaps mostly by just porting over the existing <input capture> spec text from https://w3c.github.io/html-media-capture/ |
| 09:01 | <vrafaeli> | I'm confused about why you cannot directly download the resource (file) on the local machine using JS, but you can do it with JS if you fetch the resource, construct the a element with the fetched resource as URL and then click it using JS? |
| 09:26 | <zcorpan> | Is there a spec issue about upstreaming https://wicg.github.io/document-policy/#integrations ? |
| 12:31 | <annevk> | zcorpan: I don't think there is one against HTML |
| 12:32 | <zcorpan> | annevk: ok |
| 12:57 | <annevk> | vrafaeli: example? I thought <a download>.click() would generally work. Seems weird if it performs a same-origin check ahead of time given redirects. |
| 13:18 | <annevk> | I initially thought https://github.com/whatwg/html/issues/9491 was about making /> conforming on all tags but also have it continue to be meaningless |
| 13:19 | <annevk> | So you can write <div />yolo</div> and the HTML checker won't yell |
| 13:20 | <annevk> | Anyway, if we do a flag it should just be "XML5" (and the flag is text/xml) |
| 13:45 | <vrafaeli> | https://codesandbox.io/s/interesting-nightingale-vkpy9s?file=/src/index.js I use a Chrome plugin to inject response header "content-disposition: attachment". (in my real case the server sets it) I was expecting that this would make the Chrome browser to do a download to the local machine. |
| 13:46 | <vrafaeli> | but the download to local machine does not happen |
| 18:14 | <TabAtkins> | Hm, is there a term I can reference for "frames that can be communicated with"? Basically just anything you can postMessage to? |
| 18:17 | <Jeremy Roman> | browsing context group? |
| 18:18 | <Jeremy Roman> | (though BroadcastChannel is an exception) |
| 18:18 | <TabAtkins> | (Context is "things that should be able to see an MQ change if it gets toggled by script", re: https://github.com/w3c/csswg-drafts/issues/6517) |
| 18:19 | <TabAtkins> | Because if you darkmode a site via an in-site toggle you'd like iframes to darkmode as well, ideally. |
| 19:41 | <zcorpan> | TabAtkins: you can postMessage() across origins. In the issue you say it shouldn't be visible to cross-origin iframes |
| 20:14 | <TabAtkins> | Basically I just don't want to invent a new security boundary. If you can already freely message a cross-domain frame, you should be able to affect their MQs. |
| 20:30 | <zcorpan> | TabAtkins: for popups you can communicate between opener and openee unless it was opened with noopener. For iframes I think you can always send a message (if embedding is allowed). When same-origin, you can communicate even if there's no reference to the window (with BroadcastChannel or localStorage or document.cookie or a shared worker) |
| 20:30 | <TabAtkins> | Right, all this detail is why I was asking if there's already a spec concept for communicating subframes. |
| 20:34 | <zcorpan> | TabAtkins: it's still not clear to me what you want |
| 20:39 | <TabAtkins> | I want to define that you can toggle certain MQs from script. These MQs want to transmit their script-changed values to subframes (so an iframe will also be darkmode if the top-level frame was set to darkmode). But I don't want to open a new communication channel. I'm presuming that "frames you can postMessage" is a reasonable description of the boundary for things that can see the altered MQs. |
| 20:40 | <TabAtkins> | And I'm hoping this is already a concept defined somewhere so I don't have to create and maintain such a definition in a CSS spec that doesn't otherwise care about the web's communication/security boundaries. |
| 20:40 | <zcorpan> | TabAtkins: what about popups? |
| 20:41 | <TabAtkins> | I suspect we should treat them like subframes in this regard. |
| 20:42 | <emilio> | I want to define that you can toggle certain MQs from script. These MQs want to transmit their script-changed values to subframes (so an iframe will also be darkmode if the top-level frame was set to darkmode). But I don't want to open a new communication channel. I'm presuming that "frames you can postMessage" is a reasonable description of the boundary for things that can see the altered MQs. |
| 20:42 | <emilio> | Or discuss doing it or something? |
| 20:42 | <TabAtkins> | yeah we at least discussed it, tho I don't recall the conclusion exactly. But we should rely on the same mechanism, def. |
| 20:43 | <emilio> | Seems like if we do that stuff then it works. But yeah gecko has the "browsing context group" concept which is just that, stuff you can postMessage to |
| 20:50 | <zcorpan> | I'm a bit uneasy with making custom MQ available to the whole browsing context group. It would be like BroadcastChannel but to all origins |
| 20:59 | <TabAtkins> | I don't really care what concept I end up leaning on. If browsing context group is too large, then a smaller one would work just fine for me. I just need the concept to exist somewhere where it can be reasonably maintained as we continue to add more distinctions and guards to it. |
| 21:00 | <annevk> | TabAtkins: it seems like you only want to propagate to descendant documents so that's probably what you want to say; or do you also want to go to ancestors or popups? |
| 21:01 | <TabAtkins> | Not ancestors (ancestors need to be able to propagate to me). Possibly popups, but I don't think I have much of an opinion. Seems reasonable that if the page is in darkmode its popups should be too. |
| 21:02 | <annevk> | "Its popups" is somewhat of a corner area as some popups are created deliberately without communication channel |
| 21:02 | <TabAtkins> | yeah that's fair |
| 21:02 | <annevk> | Anyway, if you don't want ancestors claiming you want equivalence with postMessage() is not too helpful |
| 21:02 | <annevk> | I would start with a document and its descendant documents (HTML has some terms for this though they are not super) |
| 21:05 | <TabAtkins> | Descendants will count things like, say, fenced frames tho I assume, so I'll still need more clarification there. |
| 21:05 | <TabAtkins> | But yeah that's probably the starting point. |
| 21:06 | <annevk> | Fenced frames aren't integrated with HTML so who knows how they work. If descendant documents return them they probably have some issues to work out. |
| 21:06 | <TabAtkins> | fair |
| 21:06 | <TabAtkins> | Probably just leaving an impl note next to the definition will suffice for now. |