| 03:24 | <MikeSmith> | krijn: I wonder if we could get the Web History Project to archive the logs |
| 03:25 | <MikeSmith> | krijn: and maybe also provide some funds, however modest |
| 03:25 | <MikeSmith> | krijn: we have 10 years of important history there |
| 03:26 | <MikeSmith> | I mean other than just whatever is at archive.org |
| 04:58 | <krijn> | MikeSmith: if I can do anything to help, let me know! |
| 05:18 | <MikeSmith> | krijn: FYI https://lists.w3.org/Archives/Public/public-webhistory/2016Apr/0000.html |
| 05:30 | <krijn> | Thanks The Mike Smith :) |
| 05:31 | <krijn> | I can easily make a static dump of all files and add a redirect to a new location |
| 05:33 | <MikeSmith> | yeah I am partly interested in just raising awareness about the logs among web-archaeologist people who could benefit from knowing about them |
| 05:33 | <MikeSmith> | heh yeah I don’t know where that “the” in “the Krijn Hoetmer” crept in from |
| 09:20 | <Ms2ger> | Lovely: https://twitter.com/LeonieWatson/status/715788733040168960 |
| 09:21 | <Ms2ger> | TabAtkins, you know why google is wasting money on the fork? |
| 09:22 | <hallvors> | There still isn't a spec which can give a canonical answer to whether a key should fire 'keypress' events or not, right? |
| 09:25 | <annevk> | hallvors: nope |
| 09:26 | <hallvors> | I'm pretty sure I wrote several tests that could be applied.. |
| 09:26 | <hallvors> | ..to create such a spec |
| 09:27 | <hallvors> | s/applied/useful to sound less like a chatbot or something |
| 09:28 | <annevk> | hallvors: in theory https://www.w3.org/TR/uievents/ should do it, but they have been opting out of most hard things it seems |
| 09:30 | <hallvors> | Right. I did scan through it.. |
| 09:31 | <annevk> | Most spec editors seem to fancy adding cruft, specifying existing cruft isn't much loved |
| 09:32 | <annevk> | That nobody seems to learn that the existing cruft influences the new cruft is a little worrisome |
| 10:26 | <jgraham> | hallvors: You don't sound nearly nazi enough to be a chatbot |
| 10:32 | <hallvors> | jgraham: thanks :) |
| 11:56 | <annevk> | krijn: btw, krijn.html5.org is still a thing if you need space |
| 12:15 | <nox> | annevk: https://github.com/whatwg/url/commit/ae7a0f6f4f0314fa1af163844c33cfdefd83334f Is it intended that URL.href's setter doesn't take into account the URL's base anymore? |
| 12:17 | <annevk> | Yeah I think so |
| 12:17 | <nox> | annevk: Why? |
| 12:18 | <annevk> | URL.prototype.href should probably just have been a getter |
| 12:18 | <nox> | annevk: Oh I see, URL doesn't have a base anymore anyway? |
| 12:18 | <annevk> | nox: yeah |
| 12:18 | <nox> | annevk: Makes sense. :) |
| 13:34 | <krijn> | annevk: oh right! I could move big part of the archive there of course, and then start logging new stuff. Now remember at some point I put http://krijn.html5.org/irc-logs/ up there already.. |
| 13:38 | <annevk> | It has all the space you want... |
| 13:44 | <smaug____> | annevk: has it been discussed somewhere how shadow scripts should be executed? |
| 13:45 | <smaug____> | or have we always just think of "like normal script" |
| 13:47 | <annevk> | That was the conclusion based on some discussion |
| 13:49 | <krijn> | annevk: will do, thanks! |
| 13:50 | <krijn> | And then 301 a few years over there |
| 13:51 | <krijn> | Wouldn't something like irc-logs.html5.org be better by the way? No need to keep my personal branding in there (even though I'm a sucker for all the extra attention throughout the years! ;) |
| 13:52 | <annevk> | krijn: sure if you want |
| 14:21 | <annevk> | krijn: can set that up later |
| 14:22 | <annevk> | krijn: also happy to provide you with money for a new hard drive or some such, or something else you need |
| 14:29 | <wanderview> | annevk: do you think we will ever expose the URLs in the Response url list to script? I'm trying to decide if its worth the storage costs of saving the entire URL list or if we can just save a boolean "redirected" flag |
| 14:31 | <wanderview> | annevk: nm, I see spec note now that it won;t be allowed due "atomic HTTP redirect handling" |
| 14:31 | <annevk> | wanderview: ever is hard, but not until we have CORS-like protocol for redirects |
| 14:31 | <annevk> | wanderview: right |
| 14:32 | <wanderview> | annevk: we can start tracking URLs at that point |
| 14:32 | <wanderview> | if its added |
| 14:32 | <annevk> | wanderview: yeah, makes sense, would require quite some work anyway |
| 14:33 | <wanderview> | annevk: are their other algorithms that look at older URLs in the list? like internal stuff that says "if ever redirected through origin X, do Y"? |
| 14:33 | <wanderview> | my impression is there are not |
| 14:39 | <annevk> | wanderview: CSP and MIX maybe |
| 14:40 | <annevk> | wanderview: if main page CSP wants to act on SW response |
| 14:40 | <annevk> | wanderview: not sure if mkwst has defined the details yet |
| 14:41 | <wanderview> | I guess that would be good to know if its going to be needed |
| 14:41 | <wanderview> | mkwst: any thoughts? |
| 14:42 | <annevk> | I think that's the reason the spec keeps track |
| 14:45 | <JonathanNeal> | Would anyone know why all elements appear block when you put display: flex on a button in Firefox? |
| 14:45 | <JonathanNeal> | s/elements/child elements |
| 14:47 | <wanderview> | JonathanNeal: #layout at irc.mozilla.org may be able to help more if its firefox specific behavior |
| 14:48 | <JonathanNeal> | Thanks @wanderview, I didn’t know if that’s how flex is supposed to lay things out. |
| 14:48 | <wanderview> | I don't know if it is either, but if its a firefox bug the people in #layout would probably be the ones to talk to about it |
| 14:52 | <wanderview> | annevk: I guess we will store all the URLs in the list... it should be a minor hit given most Responses will still only have one URL |
| 15:22 | <JonathanNeal> | That is a seriously quiet room, @wanderview, but thanks all the same :) |
| 15:23 | <wanderview> | JonathanNeal: ah, sorry... they might be on west coast US time... just waking up |
| 15:23 | <JonathanNeal> | Fair enough. |
| 15:58 | <mkwst> | I think the CSP and MIX integrations are ~clearly defined. |
| 15:58 | <mkwst> | annevk, wanderview ^^ |
| 15:58 | <mkwst> | I haven't looked at MIX in a while, though, so I won't swear on it. |
| 15:59 | <mkwst> | But CSP certainly has a hook at the bottom of Fetch to deal with Responses (and passes in the Request for context). |
| 15:59 | <mkwst> | I haven't implemented that in Chrome yet. It's on a list somewhere. |
| 16:58 | <annevk> | jyasskin: I was thinking, most permissions probably do need to deal with revocation |
| 16:58 | <annevk> | jyasskin: e.g., if I revoke "notifications", existing notifications should probably be cleared |
| 16:59 | <annevk> | jyasskin: and for "persistent-storage", the box mode should be changed and such (I don't want to change the box mode when permission is granted though, I think that should still go through the persist() method) |
| 17:18 | <jyasskin> | annevk: So then I wouldn't bother defining "boolean permission", and would just have each permission define its revocation algorithm. Boolean ones would just make that the only algorithm they define. |
| 17:19 | <annevk> | jyasskin: yeah, I guess null or algorithm makes sense for some of them |
| 17:19 | <jyasskin> | annevk: For now, nothing defines its revocation behavior, and I think some permissions need to take the argument into account, but I'll plan for almost every permission needing to do something. |
| 17:20 | <annevk> | jyasskin: yeah, it seems like revocation should mostly have an effect, e.g., stop watchPosition for "geolocation" |
| 17:40 | <annevk> | Ooooh https://twitter.com/FxSiteCompat/status/715908743351967744 |
| 17:40 | <annevk> | No more AppCache API |
| 17:43 | <annevk> | I hope that works out, saves me a bunch of work fixing the existing stuff |
| 18:02 | <wanderview> | annevk: I think there is some question about the use counter analysis... they are still looking at it |
| 23:14 | <gwicke> | hi, my interpretation of https://fetch.spec.whatwg.org/#http-redirect-fetch is that the fetch spec intends to preserve custom request headers across redirects, especially for same-origin redirects; however, https://bugzilla.mozilla.org/show_bug.cgi?id=216828#c4 implies that this is not the case. Is anybody here familiar with this topic? |