| 01:29 | <Krinkle> | Hmm.. SW cache is persistent and atomic? I was hoping it'd have at least have TTL or LRU by size (ideally both) |
| 01:30 | <Krinkle> | That'll make it a bit more complex to e..g. cache the basic app shell + a buffer of content for offline viewing. |
| 01:30 | <Krinkle> | Can't seem to find existing uses of SW that do this properly. |
| 08:24 | <annevk> | If you accidentally created a PR with a commit on your own master branch, is there a way to move that commit into a branch and have the PR be based on that branch instead? |
| 08:30 | <annevk> | ritsyy: https://github.com/whatwg/html/issues/722#issuecomment-188576457 might be relatively easy to fix for you; it will probably require a little bit of learning about HTML's rendering section |
| 08:33 | <ritsyy> | annevk: oh okay, going through it |
| 09:03 | <jgraham> | annevk: Moving that commit onto a branch is easy (just create a branch and reset master back to origin/master), but I don't think you can tell GitHub to change the branch for a PR |
| 09:06 | annevk | finds https://stackoverflow.com/questions/10081053/how-to-change-the-base-branch-of-a-pull-request/11983910#11983910 and decides not to go there |
| 09:07 | <annevk> | Hmm, https://stackoverflow.com/questions/35605688/modules-in-es6-full-project/35623318 says thank you but does not give me pointless internet points |
| 09:16 | <Ms2ger> | If you ever find a way to change the branch that backs a PR, lemme know |
| 09:18 | <annevk> | Ms2ger: see "finds" above, it's possible through the GitHub API |
| 09:19 | <Ms2ger> | Ugh |
| 09:20 | <Ms2ger> | Apparently doesn't work |
| 09:22 | <annevk> | Ms2ger: yeah, "Edit: Note: according to comments, the above is only for attaching a new pull request to an existing issue." |
| 09:22 | <annevk> | Ms2ger: my bad |
| 09:23 | <annevk> | I've seen someone do this once, turn an issue into a PR |
| 09:23 | <Ms2ger> | Oh, that's something else than I was thinking |
| 09:24 | <annevk> | Yeah, I wanted to change the branch of an existing PR |
| 09:24 | <annevk> | But I guess there's no API surface for that |
| 09:25 | <annevk> | MikeSmith: why can folks still file bugs in the XHR component? https://www.w3.org/Bugs/Public/show_bug.cgi?id=29506 |
| 09:25 | <annevk> | MikeSmith: we should probably close that |
| 09:25 | <annevk> | MikeSmith: as in, you 😃 |
| 09:27 | <MikeSmith> | hah |
| 09:29 | <MikeSmith> | at first I thought just now that I had closed that already |
| 09:29 | <MikeSmith> | but then I remembered I hadn’t yet |
| 09:29 | <MikeSmith> | I had closed the whatwg one already |
| 09:34 | <MikeSmith> | I may still get dressed down by somebody else but I’ll deal with that whupping when it comes |
| 09:38 | <MikeSmith> | btw the only bugzilla components that I see which are still active are one for the DOM fork, one for DOM Parsing and Serialization (which we probably really should try to find our own editor for again), File API, Web IDL, the WebSocket API fork |
| 09:38 | <MikeSmith> | seems like we should close the WebIDL component too |
| 09:39 | <MikeSmith> | for WebIDL I need to confirm with heycam|away but I thought all issue-tracking had moved to github |
| 09:40 | <MikeSmith> | https://github.com/heycam/webidl/issues |
| 09:45 | <annevk> | File API definitely moved to GitHub |
| 09:45 | <annevk> | (although also without editor) |
| 09:48 | <MikeSmith> | will fix that one too then |
| 09:58 | <annevk> | MikeSmith: I think you can close DOM too |
| 09:58 | <annevk> | MikeSmith: even the TR/ copy links to GitHub (although the W3C GitHub, which appears inactive) |
| 09:59 | <annevk> | Hahahaha, https://github.com/w3c/dom/blob/gh-pages/LICENSE.md |
| 09:59 | <annevk> | It's a direct fork of whatwg/dom |
| 09:59 | <annevk> | Ugh |
| 10:01 | <annevk> | https://www.w3.org/TR/dom/ is actually a year older than advertised too |
| 11:25 | <odinho> | jgraham: I'd love visiting you, thanks for the preemptive invitation. :) |
| 12:52 | <JakeA> | annevk: why do we need a wrapper after respondWith? I thought the existing response types would be enough |
| 12:52 | <annevk> | JakeA: how would an existing type work? |
| 12:53 | <JakeA> | annevk: it's either opaque or visible, those things already exist. Particular headers are filtered, that already exists with CORS |
| 12:53 | <annevk> | JakeA: CORS does that in a particular way that does not work for this |
| 12:55 | <annevk> | JakeA: we could maybe make it reuse most of the CORS setup and even the type, but there's a need for changes still |
| 12:56 | <JakeA> | annevk: fair. I saw it as the same as it's a header guard in both CORS and foreign fetch. Conscious that we keep adding stuff to response and thought this could be isolated to foreign fetch via a wrapper |
| 12:57 | <annevk> | JakeA: the response stuff is not a header guard really |
| 12:57 | <annevk> | JakeA: a CORS response is protected by https://fetch.spec.whatwg.org/#concept-filtered-response-cors |
| 12:58 | <annevk> | JakeA: https://fetch.spec.whatwg.org/#dom-headers-get doesn't need any guard because of that |
| 13:00 | <ritsyy1> | annevk: https://github.com/whatwg/html/pull/748,, landed a bit late :-[ |
| 13:00 | <JakeA> | annevk: I see, so foreign fetch's respondWith will create a filtered response from the response & the headers list passed to makeVisible (or whatever it ends up being called) |
| 13:01 | <annevk> | JakeA: yeah |
| 13:02 | <annevk> | JakeA: most of that should probably be in Fetch somehow since it requires changes to responses |
| 13:02 | <annevk> | JakeA: which is my Response.makeVisible or Response.reveal() isn't too bad either I think |
| 13:04 | <JakeA> | annevk: the reason I don't like Response.makeVisible is you don't get failure feedback, since it doesn't know the target origin |
| 13:05 | <JakeA> | And it feels too specific to put on a generic response. A generic way to create a filtered response might be useful… maybe |
| 13:07 | <annevk> | ritsyy1: ta |
| 13:08 | <annevk> | JakeA: yeah, I guess I don't feel too strongly |
| 13:08 | <annevk> | but the filtered response stuff is needed |
| 13:08 | <JakeA> | agreed |
| 13:09 | <annevk> | ritsyy1: there's also a specific bit on the details element in the rendering section |
| 13:09 | <annevk> | ritsyy1: I wonder if that's still required |
| 13:09 | <JakeA> | annevk: if responses become structured cloneable or transferrable, then they can be postMessaged to other origins, the makeVisible would have to mean something in that case too. |
| 13:11 | <JakeA> | postMessage would have to hook into the cloning process and throw if the visibility is wrong. Dunno if that's desirable. |
| 13:12 | <annevk> | JakeA: my idea was for that origin to not persist |
| 13:12 | <annevk> | JakeA: but simply be a sanity check at the boundary |
| 13:12 | <annevk> | JakeA: once an origin gets hold of the data, it should no longer be origin-bound in that way |
| 13:13 | <ritsyy1> | annevk: yeah there it is about summary, i think it should be removed then, right?, i am not sure |
| 13:13 | <annevk> | To make structured cloning work btw we'd have to do structured cloning of promises first, hasn't been making much headway lately though Domenic did have a design |
| 13:13 | <annevk> | ritsyy1: I think the changes you made are all correct |
| 13:14 | <annevk> | ritsyy1: I just want to check with upsuper about the section on details |
| 13:14 | <ritsyy1> | ritsyy1: okay, yes will wait for upsuper's review |
| 13:15 | <JakeA> | annevk: sure, and our only boundary right now is foreign fetch, but if makeVisible is a generic method on Response then we need to consider other potential boundaries, and postMessage could be one |
| 13:15 | <JakeA> | So the question is whether we're happy with it being a generic thing, or want to keep this specific to the foreign fetch boundary |
| 13:15 | <annevk> | JakeA: yeah, it probably makes more sense for makeVisible to be tighlty coupled with respondWith somehow |
| 13:16 | <JakeA> | annevk: that's why I was suggesting foreignFetchEvent.makeVisible etc |
| 13:16 | <annevk> | JakeA: perhaps it's indeed better for foreign fetch to have its own respondWith variant where you return a promise for a dictionary that has the various bits |
| 13:16 | <JakeA> | Which can also throw if the destination origin doesn't match the target |
| 13:16 | <annevk> | {response: ..., origin: ..., headers: ...} |
| 13:16 | <JakeA> | annevk: yeah, that was one of my suggestions in the thread |
| 13:16 | <annevk> | I think that would be the cleanest and then we let Fetch handle the security checks as we did with Handle Fetch |
| 13:17 | <annevk> | JakeA: I'm starting to like it |
| 13:17 | <JakeA> | annevk: benefit of a seperate method is it can throw and be recovered from |
| 13:18 | <annevk> | JakeA: but then you need to know everything synchronously; recovery here seems hard, better be sure when you resolve the promise |
| 13:18 | <JakeA> | But that could just be a verify method that takes that dict |
| 13:19 | <annevk> | Yeah, I like this design, and for opaque you'd simply omit the origin/headers members |
| 13:19 | <JakeA> | annevk: it's a synchronous check isn't it? We know the destination, we have the response, we have the target |
| 13:20 | <JakeA> | Agreed. A request object could be upgraded to { request }, unless that's too magic |
| 13:21 | <annevk> | JakeA: the check is synchronous, yes (although a standalone verify method would have to be on the event object to know about the target) |
| 13:21 | <JakeA> | Agreed |
| 13:21 | <annevk> | JakeA: you mean a response object? Seems too magic |
| 13:21 | <JakeA> | Ah yes. Yeah, you're right, making it explicit is fine |
| 14:02 | <annevk> | Domenic: can you help with https://github.com/tc39/ecma262/issues/418? |
| 15:48 | annevk | gives up on https://www.w3.org/Bugs/Public/show_bug.cgi?id=29506#c6 |
| 16:12 | <rektide> | what was the place that formed, and recently renamed itself, that intends to help newcomers create new specs? |
| 16:16 | <astearns> | rektide: https://www.w3.org/community/wicg/ ? |
| 16:17 | <rektide> | astearns: yeah, exactly. thanks for the help! |
| 16:17 | <Ms2ger> | Having newcomers create new specs sounds like the worst idea |
| 16:18 | <rektide> | Ms2ger: if you or someone else wants to create a spec for global hotkeys, please take it off my plate |
| 16:18 | <rektide> | volunteers will be thanked |
| 16:20 | <jgraham> | global hotkeys? |
| 16:21 | <annevk> | Ms2ger: ? You have to start somehow |
| 16:21 | <rektide> | I'd like to build a media player app, where play/pause/mute/fwd/back keys work whether i'm on the page or not. I need hotkeys which are global. |
| 16:21 | <annevk> | rektide: that is https://mediasession.spec.whatwg.org/ |
| 16:22 | <Ms2ger> | annevk, sure, but I don't think just going off and writing your own spec if you have no experience in spec work is going to end up with a useful result |
| 16:22 | <annevk> | Ms2ger: it took ten rewrites or so before I got somewhere with XHR, but that's how I started |
| 16:22 | <rektide> | Ms2ger: that seems like a really good reason for wicg to exist then, no? To perhaps be a mechanism to inject some slim chance of hope. |
| 16:23 | <jgraham> | annevk: Not really |
| 16:23 | <jgraham> | By the time you did XHR you already had like 10 years experience working on other specs |
| 16:24 | <Ms2ger> | annevk, intentionally "spec work", not "spec editing" :) |
| 16:24 | <rektide> | this MediaSession spec is awesome! |
| 16:24 | <annevk> | I started XHR in 2006, that would mean I started in 1996 when I was 10 years old |
| 16:24 | <annevk> | Seems unlikely |
| 16:25 | <annevk> | But yes, I had been active in the community for about two years I suppose |
| 16:26 | <jgraham> | annevk: Pretty sure you did start when you were about 10 years old :p |
| 16:26 | <Ms2ger> | Wasn't that gsnedders? |
| 16:26 | <jgraham> | Isn't he still 10 years old? |
| 16:27 | <gsnedders> | Ms2ger: AFAIK the person who came closest to that is still Aaron |
| 16:28 | <gsnedders> | I was 14 when I appeared around specs, I think |
| 16:28 | <Ms2ger> | Looks like 16 for me |
| 16:30 | <gsnedders> | IIRC, Aaron was 12 |
| 16:30 | <nox> | :| |
| 16:31 | <gsnedders> | (Swartz, this is) |
| 16:41 | <gsnedders> | At least he was 12 when he first attended a F2F, from memory of what timbl said (to me, at my first F2F, at 16). |
| 20:06 | <nox> | What static attributes are there in the platform? |
| 20:34 | <nox> | In https://dom.spec.whatwg.org/#dom-element-setattribute, shouldn't step 3 use https://dom.spec.whatwg.org/#concept-element-attributes-get-by-name? |
| 20:40 | <annevk> | nox: Notification.permission |
| 20:41 | <nox> | annevk: I thought that was the answer to my last question and I was quite confused. :) |
| 20:41 | <nox> | annevk: Thanks. |
| 20:43 | <annevk> | nox: I think it does not to avoid duplicating a step |
| 20:43 | <nox> | I see. |
| 21:18 | <nox> | annevk: What's the proper procedure for reviewing? |
| 21:19 | <nox> | Oh I guess I can just say it's ok. |