instead of

in specs? [15:25:04.0000] smaug____: github uses tags for things like that [15:25:07.0000] Domenic: Our markup standards are a carry-over from pre-html? [15:25:13.0000] Sorry, pre html5 [15:25:28.0000] TabAtkins: hmm kind of what i figured, but a bit sad. [15:27:45.0000] Anyone have opinions on me auto-formatting IDL blocks like https://github.com/tabatkins/bikeshed/issues/449 suggests? [15:28:22.0000] I'm pretty sure the syntax highlighting is doable with a minimum of effort (all the structures already exist, I just need to tag them with classes and style them). [15:49:13.0000] TabAtkins: I object to the alignment. The coloring seems fine though. [16:49:56.0000] cvrebert, at 2015-08-02 06:51 UTC, MikeSmith said: no, the SVG reference is one thing that should not be updated. [16:55:02.0000] Any w3C peeps able to look up who's a GitHub Collaborator on https://github.com/w3c/css-validator ? 2015-08-05 [17:04:24.0000] cvrebert: the only people who have push access to that repo at this point are W3C staff [17:04:33.0000] why do you ask? [17:05:06.0000] MikeSmith: Trying to find out who to ping to merge my PR: https://github.com/w3c/css-validator/pull/10 [17:05:31.0000] we're not going to keep that repo [17:06:26.0000] it will end up getting overwritten when somebody (probably me) finally pushes the current code in the cvs repo to there [17:07:34.0000] Ah. I eagerly await that clobbering then :-) [17:07:53.0000] yeah sorry it's not been done already [17:08:27.0000] the thing that's holding me up from doing that right now is, doing a mapping of the names of the contributors in the cvs repo to their github usernames, so that the history will be as it should be [17:08:36.0000] eh, things happen :-) [17:09:57.0000] cvrebert: well please remind me about this again some time soon [17:10:10.0000] I may be able to do it today but I doubt it [17:11:17.0000] /me adds a calendar reminder [17:32:38.0000] botie, inform cvrebert it would be helpful if you just close https://github.com/w3c/css-validator/pull/10, since it's not going to end up getting merged. (P.S. I'm putting together the username mappings for the repo migration right now.) [17:32:38.0000] will do [17:33:27.0000] TabAtkins: might you know if Bert has a github account? [17:33:52.0000] MikeSmith: No clue! [17:34:29.0000] yeah I reckoned :) [17:34:34.0000] figured it was worth a try [17:34:48.0000] /me peruses https://github.com/w3c/csswg-test/graphs/contributors [17:35:56.0000] oh astearns, know if Bert has a github account? [17:36:29.0000] I don't know, but my guess would be no [17:36:33.0000] ok [18:35:29.0000] Hi good people. I got messy code when `fetch` Chinese. [18:35:59.0000] tried on both Chrome and Firefox, is this a issue of `whatwg-fetch` or Chrome/Firefox? [18:37:50.0000] @channel [18:44:25.0000] ssyrain: @channel is a Slack thing, not an IRC thing. [18:44:37.0000] ssyrain: But what do you mean by "got messy code when `fetch` Chinese"? [18:46:16.0000] when server respond with Chinese text with `utf-8` setted in response header, `fetch` can not recognize that and i got messy text. [18:47:30.0000] when i changed to XmlHTTPRequest, Chinese text can be recognized [18:49:36.0000] If fetch() and XMLHttpRequest are acting different for the Content-Type header, it's a bug. Please report it! [00:10:53.0000] cvrebert, at 2015-08-05 00:32 UTC, MikeSmith said: it would be helpful if you just close https://github.com/w3c/css-validator/pull/10, since it's not going to end up getting merged. (P.S. I'm putting together the username mappings for the repo migration right now.) [00:11:27.0000] Did that long ago :-) [00:13:36.0000] You should hang around here more often :) [04:28:11.0000] hsivonen: https://html5.validator.nu/ and https://validator.nu/ both 502 atm [06:09:15.0000] Domenic: I don't know what your plans are for the WHATCG, but if you want to automate checks that PRs come from people who've signed the CG CLA (i.e. are members in it) feel free to use https://labs.w3.org/hatchery/ash-nazg/ [06:09:23.0000] happy to send you further details if it helps [06:11:13.0000] darobin: oh very cool. philipj ^ [06:11:41.0000] Domenic: it's just a click for me to add the WHATCG as one of the groups using that [06:11:58.0000] there are still bugs, but it's used by the WICG and WebRTC WG already [06:12:08.0000] darobin: example of it in action? [06:12:18.0000] nazg for Nazgul? [06:13:21.0000] Domenic: if you look at https://github.com/ResponsiveImagesCG/picture-element/pull/270 for instance you can see that it has IPR checks passing [06:13:33.0000] whereas https://github.com/w3c-test/test-live/pull/1 doesn't [06:13:46.0000] darobin: excellent, full integration instead of google-cla-bot style nagging comments [06:13:49.0000] Ms2ger: close enough, ash-nazg is the one ring [06:14:02.0000] Domenic: yeah, it's basically just a status hook [06:14:13.0000] when you create a repo through it, or import a repo into it, it adds the hook [06:14:18.0000] would be nice if clicking "Details" didn't ask me for mega-permissions [06:14:23.0000] yeah [06:14:26.0000] Ah [06:14:42.0000] Domenic, darobin, that sounds cool! [06:14:54.0000] getting granularity with the GitHub API isn't simple [06:15:07.0000] or at least, I couldn't find a simple way to make it work [06:15:17.0000] yeah i've heard that from a lot of people [06:15:26.0000] still surprised that "details" can't go to a "this is what this check is about" page [06:15:49.0000] and since the tool needs to create repos, add files, add hooks for some of its functions, it's a bit of a PITA [06:15:49.0000] darobin: does it just check the committer, or can the commit say where the idea came from somehow? [06:16:20.0000] Domenic: I'm sure I can remove the login requirement on some pages; it's mostly a question of making sure the UI still makes sense and doesn't offer affordances for stuff you can't do [06:16:47.0000] philipj: when you create a PR you can add comments to it with +@whoever to add someone, or -@someone to remove them [06:16:57.0000] so yeah, you can get an idea from someone else and track that [06:17:05.0000] (and even remove yourself as PR author) [06:17:10.0000] darobin: awesomeness [06:17:19.0000] it's pretty new, it has its rough edges [06:17:36.0000] notably it doesn't mind if a PR has no contributors :) [06:17:52.0000] also, mapping CG participants to GH usernames is semi-manual [06:18:04.0000] for divinely inspired changes, presumably? [06:18:15.0000] (but since you typically only have few contributors, the admin overhead isn't too bad) [06:18:17.0000] lol [06:18:28.0000] I've got some docs in an email, I need to put them up [06:18:47.0000] anyway, I just wanted to say that if you folks want it it's there for you to use [06:19:01.0000] and of course the source is available, yadda yadda [06:19:27.0000] right now it creates repos that follow the WICG template, which isn't the same one you'd want — but that can be hacked in [06:21:35.0000] i'd kind of prefer not to create repos from it [06:23:50.0000] that's fine, but in order for a repo to be managed by it you'd need to at least import them [06:24:02.0000] and the current behaviour is that'll create files if they're not there :) [06:25:18.0000] anyway, if you think it could be useful but with some changes, in a few weeks' time we can just sit down together to hash something out :) [10:40:50.0000] MikeSmith: thanks. the validator is back up now. [10:41:09.0000] /me seriously needs to automate the response to this situation [10:45:15.0000] hsivonen: thanks [11:44:21.0000] I wish github had a better way to show diffs on html files [11:58:00.0000] http://services.w3.org/htmldiff can sometimes help [13:27:43.0000] /me misses context for https://twitter.com/W3CmemesExposed/status/628873727271415808 2015-08-06 [00:52:18.0000] Arguments thing? [00:53:06.0000] Ms2ger: that bikeshed treats arguments as if they're definitions [00:53:18.0000] Ah [02:49:03.0000] annevk, were you working on something for sites' database quota? [02:55:01.0000] Ms2ger: https://storage.spec.whatwg.org/#quota I think [02:55:42.0000] There we are [02:56:53.0000] though there's not much there there at this point [02:57:06.0000] Yeah [02:57:42.0000] /me wonders if we're going to move Storage into that spec [03:04:56.0000] Ms2ger: what is Storage? [03:05:06.0000] local/session [03:05:44.0000] We could maybe, would that shrink HTML a lot? [03:05:56.0000] The Cache API could move there too maybe [03:07:48.0000] I don't know that there's any single piece that would shrink HTML by a lot, compared to its overall size :) [03:09:03.0000] Print preview on the w3c fork says 20 pages or so, for whatever that's worth [03:09:37.0000] That's <5% I think [03:11:48.0000] Yeah, about 2% I suspect [04:10:20.0000] Well, and since it's the fork that likely includes a bunch of boilerplate, so more like 1%... [04:10:31.0000] But maybe as with performance every little bit helps? [04:11:17.0000] TabAtkins: https://github.com/whatwg/dom/issues/62 [05:06:24.0000] annevk: you around to help me with opaqueredirect? [05:07:25.0000] annevk: I don't see where the fetch algorithm consumes the opaqueredirect to actually do the redirect [05:09:27.0000] annevk: won't the original fetch algorithm that initiated the fetch event end up in the "manual" redirect mode of the 30x handling when an opaqueredirect is returned? thus returning another opaqueredirect? [05:10:07.0000] annevk: ultimately I'm trying to understand if an opaqueredirect can result in the navigation triggering a second fetch event [05:10:28.0000] JakeA: maybe you have thoughts about this too ^^^ [05:21:56.0000] wanderview: an opaque redirect to a navigation should result in another fetch event [05:22:09.0000] depending on the redirect location [05:22:19.0000] JakeA: depending? [05:22:24.0000] it'll go to the SW that controls the new location, if any [05:22:50.0000] JakeA: is this all "to be spec'd in HTML spec" sort of stuff? [05:22:59.0000] I don't see it currently [05:23:29.0000] So, if a navigation to //origin1/foo/bar returns a redirect to //origin2/baz, the SW which controls //origin2/baz will get the 2nd fetch event [05:24:04.0000] I have the feeling this is going to be really hard to implement in gecko [05:24:55.0000] JakeA: thanks [05:25:46.0000] wanderview: so a navigation hits https://fetch.spec.whatwg.org/#http-fetch, it gets an opaque redirect from the SW, which survives the checks in 2.2 [05:26:02.0000] yep [05:26:18.0000] It doesn't do 5.301.10, because it's manual, not follow [05:26:26.0000] yep [05:26:33.0000] The response is returned to the navigation algo [05:27:33.0000] JakeA: well, does it double wrap as an opaque response then? [05:27:40.0000] but yea [05:28:12.0000] In step 19 of https://html.spec.whatwg.org/multipage/browsers.html#navigating-across-documents, the navigate algo loops back to create a new fetch based on the redirect url [05:28:31.0000] ok... thats the part I was missing [05:28:43.0000] I find the html spec hard to navigate [05:28:55.0000] it's a beast [05:30:48.0000] /me wishes bz was not on vacation... [05:31:39.0000] JakeA: it seems an error that 5.301.11 creates a new opaqueredirect if it already has an opaqueredirect [05:31:51.0000] jgraham: have a moment to look at the last few comments in https://critic.hoppipolla.co.uk/showcomment?chain=12228 ? TIA! [05:32:24.0000] seems like it should just return the existing opaqueredirect [05:33:02.0000] yeah, not sure I fully understand that, annevk usually has a good reason though. He'll be able to clear it up. [05:33:35.0000] JakeA: at least in our impl, we assert that an opaqueredirect doesn't wrap an existing filtered response type [05:33:53.0000] since it breaks the "get unfiltered " semantics... that stuff only looks one level deep [05:37:01.0000] wanderview: what is 5.301.11? [05:37:24.0000] annevk: http-fetch step 5, for the 30x series of status codes, step 11 [05:38:25.0000] wanderview: hmm yes [05:40:08.0000] wanderview: I guess another problem is that when you return an opaqueredirect from a service worker when redirect mode is follow [05:40:23.0000] annevk: I don't think that is permitted today [05:40:24.0000] wanderview: although I guess that scenario fails in 2.2 [05:40:29.0000] annevk: yea [05:41:42.0000] still, the whole status code dance should probably operate on the internal response, which would avoid recursive wrapping [05:42:05.0000] JakeA: so if someone is doing read-through-caching... we would expect an opaqueredirect to end up in the Cache... and the following secondary fetch event will result in the final resource being in the Cache too? [05:42:54.0000] annevk: the restriction for opaqueredirect for navigations seems a bit problematic to me [05:42:55.0000] wanderview: unless they were serving from cache-first, in which case they'd get a redirect loop [05:43:28.0000] JakeA: hmm... not sure I see where the loop happens [05:43:34.0000] wanderview: you'll have to tell me what the problem is [05:44:10.0000] annevk: consider an opaqueredirect gets put in the Cache for navigation... but then the same URL is loaded as *not* a navigation, you will get a failure when its read out of the Cache [05:44:23.0000] annevk: for example, someone visits an img thats served with a redirect [05:44:33.0000] wanderview: no, you're right, it wouldn't loop, sorry [05:44:37.0000] visits the img as a navigation... then loads the page with the img embedded [05:46:18.0000] why would the Cache API cache a redirect? [05:47:18.0000] annevk: if the pattern is cache-after-fetch: User visits '/', fetches, response added to cache [05:47:46.0000] annevk: this pattern: https://jakearchibald.com/2014/offline-cookbook/#on-network-response [05:49:03.0000] Well, not handling manual redirects for navigations causes its own set of problems [05:49:10.0000] Pick your poison [05:49:49.0000] I don't think caching a redirect is so bad tbh. If it's temporary maybe. But yeah, developers will need to watch what they cache [05:50:23.0000] wanderview: I filed https://github.com/whatwg/fetch/issues/105 on your double wrapping issue [05:50:39.0000] annevk: by why not allow opaqueredirect for non-navigation [05:50:41.0000] ? [05:50:56.0000] wanderview: did you read #66? [05:51:02.0000] I think we discussed this [05:51:09.0000] not in its entirety, no [05:51:28.0000] I can look for the navigation restrict [05:54:10.0000] wanderview: I think https://github.com/whatwg/fetch/issues/66#issuecomment-121192316 discusses it [05:55:07.0000] wanderview: the main problem is where the request ends up if the redirect went cross-origin [05:55:20.0000] wanderview: that's clear for "manual", not for "follow" [05:55:59.0000] It might be worth explaining that in the specification since it's a security restrictions of sorts [05:56:12.0000] hallvors: Donw [05:56:16.0000] *Done [05:58:58.0000] I just received a long private rant about why we have to keep synchronous XMLHttpRequest... [06:00:08.0000] annevk: Do you have a Sync XHR bingo card yet? [06:02:30.0000] someone probably wrote "for a sync xhr, email annevk" in a bathroom stall somewhere [06:02:49.0000] If you're curious, I forwarded the email to the responsible party: https://lists.w3.org/Archives/Public/www-archive/2015Aug/0006.html [06:04:34.0000] annevk: Millions I tell you. MILLIONS! [06:05:16.0000] "Douglas Crockford has likened doing changes like the ones you and your ilk imposed, as being like a physical assault, like cutting people with knives..." [06:09:19.0000] Oh wow, both "nazi" *and* "indian giving". Had to throw in some racism at the end there I guess. [06:09:20.0000] imposed? [06:10:44.0000] i didn't think anyone actually turned the feature off yet [06:11:42.0000] Turning off sync XHR would have devastating effects on the web I think, although I can't back that up with data. [06:12:02.0000] yeah, it sounds like it's probably not going to happen [06:12:26.0000] The warning is there mostly to recommend better practice [06:12:42.0000] And it seems to be effective in raising awareness [06:13:21.0000] And, I guess, having people with unrelated bugs fly off the handle. [06:14:06.0000] annevk: you could have gotten a short message like he sent this person: http://thehandshakedrugs.tumblr.com/post/22360423717/i-woke-up-to-this-email-this-morning-its-pretty [06:15:30.0000] /me goes on kid duty [06:16:21.0000] wanderview: o_O nice detective work [06:16:49.0000] omg [06:17:54.0000] I missed this gem at the end: "my hate and that of many others will be forever" [06:52:53.0000] /me resists making a Warhammer joke. [06:53:54.0000] annevk: why is the http-fetch 2.2 check "fail if non-navigation and opaqueredirect" instead of "fail if redirect mode is follow and opaqueredirect"? [06:54:18.0000] annevk: I mean.. why can't code do fetch(url, { redirect: 'manual' }) and get it intercepted with an opaqueredirect? [06:57:13.0000] wanderview: well, redirects have tons of security issues around them, I rather keep them closely guarded until we know it's safe [06:58:10.0000] wanderview: what's the use case of allowing that? [06:58:24.0000] wanderview: we could work through it I suppose and add it if you think that's valuable [07:02:22.0000] annevk: no use case in mind... just trying to understand why we are operating on "navigation" instead of the primitives script can see/reproduce (since we rolled back context for now) [07:04:26.0000] wanderview: since it's more restrictive [07:04:39.0000] more MVP, if you will [07:28:50.0000] So for whoever is attending TPAC... When you book the Renaissance Sapporo Hotel through Egencia (perhaps Expedia too?) the rates are less than half from what is listed on w3.org and their recommend travel agency... [07:29:50.0000] As in, I'm staying six nights for USD ~400 [07:30:19.0000] Yes. I got it cheaper from Hotels.com. [07:31:43.0000] annevk: You're going to get angry mail from W3C management :) [07:31:56.0000] jgraham: Film at 11 [07:32:07.0000] I'm arriving in Tokyo on Saturday morning (23rd). Will drink the best cocktails in town that night (you're all invited). Off to Sapporo the next day. [07:32:52.0000] I'm arriving Friday morning... [07:33:19.0000] In Sapporo or Tokyo? [07:33:50.0000] Tokyo [07:34:24.0000] I'm either staying there until Sunday, or join mnot's road trip idea, but that thread's been kind of silent lately [07:38:29.0000] I'll be here all of Saturday night: http://www.japantimes.co.jp/life/2014/06/10/food/meet-willy-wonka-extraordinary-cocktails/ :D [07:38:36.0000] (The Akasaka branch.) [07:40:22.0000] wilhelm: If you're ever in Seoul, you must go to Le Chamber. Best cocktails I've ever had. [07:40:51.0000] /me takes notes. [07:41:12.0000] (We happened to go the night before the Korean bartending championships, so they had some guest mixers that night who made some *amazing* drinks.) [07:41:31.0000] The owners are brothers who have both won the championship, iirc [07:41:37.0000] Oh, fun. [07:42:10.0000] I believe you always need a reservation, at least for a bar seat (which you want). [07:47:46.0000] I attended a rather amazing food-and-cocktails pairing dinner at the above-mentioned place last week. The head bartender from Tippling Club in Singapore did the cocktails. That place is hereby recommended by proxy, too. [07:55:50.0000] wilhelm: Sat is the 24th? [07:56:28.0000] gsnedders: Yes. [07:56:40.0000] wilhelm: silly wilhelm, can't you even date? [07:56:41.0000] Eh, mistyped. [07:56:43.0000] No. [07:56:48.0000] Because timezones. [07:56:51.0000] …that sounded more questionable than I meant. [08:26:41.0000] JakeA: annevk: if a navigation triggers a fetch event, then fetch event does nothing (does not call respondWith()), then the normal browser processing hits a redirect, should a second fetch event be triggered in that case? [08:26:50.0000] or only a second fetch event if an opaqueredirect is hit? [08:27:24.0000] Second fetch event, targeted at the controller of the new url [08:27:51.0000] JakeA: even if the controller is the same as the first fetch event? (same origin/scope) [08:28:07.0000] wanderview: yep! [08:28:18.0000] ok [08:28:39.0000] /me is beginning to think taking this bug was a mistake. [08:28:47.0000] wanderview: if I respondWith(Request.redirect('/')) to a navigation, I'd expect another fetch event too [08:29:07.0000] JakeA: but only for navigations, right? [08:29:12.0000] or manual redirect flag [08:29:29.0000] JakeA: Request.redirect('/') is not an opaqueredirect, right? [08:31:07.0000] wanderview: I'd expect another fetch if the original request was manual-redirect, and the initiating algo reacts to redirects by starting a whole new fetch (which is navigations, there may be others) [08:31:26.0000] wanderview: Request.redirect('/') is just a Response [08:31:59.0000] JakeA: so I guess if a script does fetch(url, { redirect: 'manual' }) they could detect the 30x status code and do a new fetch() [08:32:20.0000] annevk: would it be useful to start a ticket for drafting the patches to HTML regarding fetch? [08:42:03.0000] JakeA: do you consider this new redirect behavior v1 or v2 for service workers? [08:42:21.0000] should I be concerned about being incompatible if chrome waits to implement? [08:53:52.0000] wanderview: Google docs hit a problem where, on navigation, their SW would fetch the page, but it'd hit a redirect to the (other origin) login page. If they served this they'd get an error. They could work around it by making a no-cors fetch and assuming an opaque response was a redirect, and issue the redirect themselves, but then they're downloading the [08:53:52.0000] login page twice [08:54:05.0000] The changes to redirect were to handle this case [08:54:50.0000] So, without these changes, offline may fail in Google Docs, so I guess it depends on how much that matters [09:09:20.0000] wanderview: yeah, because of manual and each request being fresh [09:09:33.0000] JakeA: yeah sounds fine [09:22:52.0000] JakeA: well... from the issue comments the chrome impl team were a bit surprised by the changes... so I was wondering if it was going to be implemented later, etc [09:22:57.0000] not a priority or something [09:23:46.0000] wanderview: Docs are a pretty high priority customer for us, so pretty sure it'll get done with pretty high priority [09:27:00.0000] JakeA: annevk: do we need Request.context sorted before integrating with other specs? [09:27:17.0000] or I guess its not hard to change later... just might be more work to roto-till the other specs twice [09:27:27.0000] wanderview: we'd just not define it for now I guess [09:27:40.0000] I should have made a proposal for that today [09:27:41.0000] forgot [09:27:45.0000] although CSP has kinda defined most of them [09:35:06.0000] Good morning WHATWG crew o/ [10:22:31.0000] annevk: any chance you want to put http-fetch step 4, 30x case, step 11 before the "follow" steps? short circuiting the short path is nicer when implementing [10:22:35.0000] minor nit [10:32:57.0000] wanderview: file an issue? [10:33:06.0000] wanderview: seems fine [10:33:14.0000] ok [10:39:39.0000] annevk: https://github.com/whatwg/fetch/issues/107 [11:10:54.0000] i need a better test word when trying to figure out how bikeshed works https://github.com/whatwg/compat/commit/2530dc6adcbd46f88f61c662501ff2ea81ba8ebf [11:10:55.0000] >_< [11:37:13.0000] so, what is the/an "associated url" of URLSearchParams? [11:37:29.0000] a hack of URLs that have a reference to it? [11:37:31.0000] hash* [11:38:31.0000] "run these steps for each associated url object urlObject" --- i assume that's like a weakmap that gets added to on assignment or something [11:56:48.0000] annevk: if you're still around, am I reading that right? we have this sort of URLSearchParams-looking polyfill in angular2, and if it's too complicated to actually polyfill correctly, or we end up wanting different behaviour, I'd like to clarify that asap [12:34:30.0000] caitp: we will probably make it 1:1 instead [12:34:43.0000] caitp: need to check if the change in Mozilla sticked around [12:35:45.0000] but during the update step, any original search query stuck on the associated url is replaced right? [12:36:46.0000] sure [12:37:23.0000] Jeff Cross at google is saying that's probably not very good for our use cases, so i guess we can't leverage the native URLSearchParams if available :( oh well [12:38:38.0000] caitp: he should file an issue against the URL spec [12:38:56.0000] caitp: if it's not meeting someone's needs I'd like to know [12:41:48.0000] maybe another method like URLSearchParams.prototype.append(urlSearchParams) { /* update current fields with new ones or different ones */ } might work better for us, we could probably leverage that [12:41:57.0000] anyway I'll let him know he can file [13:14:28.0000] caitp: Note the possible semantic confusion - when there's a collision, are you adding your values, or replacing them? [13:14:49.0000] yeah, i renamed that idea to .merge() in PM with jeff [13:15:05.0000] So adding? [13:16:36.0000] that's a hard semantic to really figure out :| [13:16:50.0000] Because there's no single right answer! [13:17:22.0000] Thus why MultiMaps expose API for manipulating their values as a list *or* as a single value, depending on what your particular model is for the keys. [13:17:31.0000] but the primitive of doing it manually by iterating over each field and deciding on a key by key basis, kind of sucks too [13:19:10.0000] Yeah, sure. Just means that we need *two* update methods (like we have .set() and .append(), and .get() and .getAll()) with names that suggest the right behavior as clearly as possible. [13:19:44.0000] Like updateReplace() and updateAppend() (using "update" because it's the Python name for the operation) [13:22:44.0000] well, already got set/add/delete, how about merge(object, optionalSchema) :x [13:25:04.0000] You only listed a subset of the operations, and mixed the two modes together in doing so. I'm confused... [13:26:20.0000] We'd got get/set (for treating it as a Map) and getAll/append (for treating it as a MultiMap). has/delete work the same in either type, so they're not duplicated. [13:26:57.0000] So for merging in another map, you need both a Map version (replaces collisions) and a MultiMap version (appends collisions). [13:28:27.0000] so, if one key in your Map has a List value, and another key in your Map has a String value, you may want to append to one, and replace the other [13:28:43.0000] Then you have to do it manually, because you're being complicated. [13:30:15.0000] well it is complicated, but nobody would want to write instructions for multiple query parameters that need to be merged with some default query parameters specified somewhere else, if they could simply write up a frozen schema and just reuse it, right? [13:30:33.0000] that seems more friendly [13:31:49.0000] It's quite trivial to package that up yourself in a method on your own, so you just have to pass in the two maps and get the result. I don't think there's enough call for "mixed" maps to justify specifying a schema, *particularly* not if you're suggesting using that *instead of* providing the two simple Map/MultiMap variants. [13:32:44.0000] alright, not a fan of the idea, I get that =) [13:33:23.0000] It's super easy to write a function that does this automatically based on whether the key ends in [], a la PHP, too. [13:36:54.0000] yeah but there are problems with that :( certain php authors assume that every client and backend understands that notation [13:37:26.0000] ah well, can't spend too much time on this discussion, but maybe someone who has more time to think it through will float a proposal at whatwg/url [13:51:04.0000] Yeah, I didn't mean it as some universal baked into a spec, just as something you could do within a project to enable a generalized function for merging url search params, rather than having to write individual ones for each different search param pattern, or write up a separate schema for each pattern. 2015-08-07 [18:12:52.0000] hsivonen: I was wondering if you could provide tips on requesting Maemo Source Code from Nokia (or Microsoft, as it may be)? https://hsivonen.fi/maemo-src/ You have source code for osso-rss-feed-reader version 1.2.31-1, while I am wondering about version 1.8.22-2 . Of course, I would prefer getting the latest source codes of _everything_ , if possible. [21:57:29.0000] Multimaps :-) At some point we'll redo FormData, URLSearchParams, and Headers in terms of them [21:57:40.0000] Ugh that underscore [03:42:01.0000] Oksana: I put the text of my request letter at https://hsivonen.fi/maemo-src/request.html . Feel free to adapt that text to the facts of your case. The GPL offer notice was in some sort of system-wide about box. [05:36:35.0000] Hi, Iv been redirected here, anyone knows what's the usage for the "xmlhttprequest" context? cf https://fetch.spec.whatwg.org/#concept-request-context [05:42:52.0000] n0a___: yeah, it's not xmlhttprequest, it's fetch. It means a serviceworker can detect the rough type of the request, which is useful when determining what kind of fallback content to show. It's also useful for CSP when deciding whether to block content or not. Also useful for network stack when deciding priority [05:45:15.0000] JakeA: sorry but I understand for most of the other values [05:45:26.0000] but not for this one or others connect-src ones [05:45:54.0000] in these cases does it refer to the context of the destination? [05:46:18.0000] or do you have a simple use case? [05:46:40.0000] n0a___: that big list is likely to be boiled down to something simpler. See https://github.com/whatwg/fetch/issues/93#issuecomment-126686379 [05:47:29.0000] hum [05:48:06.0000] so ur saying these connect-src context values will be dropped? [05:49:00.0000] in short what is the use case for any connect-src scenario using fetch? [05:49:10.0000] ur fetching from xhr? [05:49:19.0000] that doesn't make sense to me [05:49:42.0000] you are fetching the url string to feed to xhr? [05:49:44.0000] fetch('/hello') would have a context of "connect" in that proposal [05:49:55.0000] as would xhr requests [05:52:03.0000] JakeA: so "processor" in your comment corresponds to the context property? [05:52:14.0000] annevk: Israel from Microsoft, what was his surname? (trying to find his email address) [05:52:37.0000] JakeA: see pm [05:52:57.0000] n0a___: yeah, the context property is likely to be replaced by something like the things in that github comment [05:53:32.0000] that's a good thing because it seems easier to grasp [05:53:59.0000] is the current context property already supported by current browsers? [05:54:05.0000] well I could check [05:55:48.0000] JakeA: context is already supported by browsers so my question remains what does it mean to have an xhr context? [05:56:12.0000] n0a___: which browsers support context? [05:56:17.0000] chrome [05:56:29.0000] new Request({}) [05:57:04.0000] I dunno if it supports the values though [05:57:10.0000] would require more tests [05:58:29.0000] n0a___: Chrome would drop 'context' and move to the new thing (which may still be called 'content') [05:58:52.0000] I don't think the current implementation is useful enough to create a breaking change [05:58:57.0000] JakeA: I still need to understand what are those src-connect value today [05:59:42.0000] of course if they are not supported that's another sotory [05:59:44.0000] n0a___: I don't think I understand your question. Are you asking what the context value would be in XHR? Do you mean in the current spec or the thing we're proposing on github? [05:59:46.0000] *story [05:59:53.0000] I don't think they're supported [06:00:51.0000] I am not proposing anything on GitHub, I want to understand why you would use the value "xmlhttprequest" for the property context of a request object [06:01:38.0000] what's the use case that supports it [06:01:45.0000] n0a___: well, the proposal on GitHub is to use "connect" as defined as CSP [06:02:02.0000] The use cases are at https://github.com/whatwg/fetch/issues/93#issuecomment-126653941 [06:02:07.0000] n0a___: it gives the service worker the ability to impose policies based on who requested the resource [06:02:17.0000] n0a___: but as several folks pointed out, we're going to change how this works [06:02:34.0000] annevk: sorry to be so dense but what are the resorces in that case? [06:02:52.0000] n0a___: anything a page requests [06:02:55.0000] resources why do you need to set specifically to xhr? [06:03:09.0000] n0a___: do you know what a service worker is? [06:03:17.0000] yes [06:03:23.0000] n0a___: we're not specifically setting xhr, the proposal is to use "connect" as defined by CSP [06:03:24.0000] n0a___: and in particular how it can intercept fetches? [06:03:48.0000] n0a___: "xmlhttprequest" is used when the service worker intercepts a fetch coming from XMLHttpRequest [06:03:48.0000] by using what's already defined by CSP, we're not really inventing much new [06:04:03.0000] OHHH so it's not fetch() [06:04:13.0000] but xhr using fetch internally? [06:04:37.0000] n0a___: everything that does requests uses Fetch internally, but not necessarily the fetch() API [06:04:50.0000] JakeA: I don't think "connect" is a value we should use [06:05:06.0000] ok but I wasn't interested in internal stuff… now I get it [06:05:08.0000] JakeA: the type stuff made much more sense to me anyway [06:05:28.0000] I guess I should try to resolve this next week [06:06:15.0000] annevk: I agree that "connect" is a bad name. I was just reusing CSP for consistency [06:06:38.0000] you should really differentiate fetch [intern] and fetch global [06:06:45.0000] it's quite confusing [06:06:57.0000] n0a___: well, fetch() and fetch [06:07:05.0000] n0a___: but... open to suggestions I suppose [06:07:22.0000] just a remark, you do whatever you want with it [06:08:00.0000] n0a___: I agree with your remark, but I don't really have any better ideas [06:08:39.0000] I go with "fetch event" "fetch spec" and "fetch api" verbally [06:09:28.0000] maybe be very verbose whenever it could be confusing if it's taken out of context [06:09:40.0000] I see ppl quoting the spec and being confused [06:10:32.0000] or just add examples, always work :) [06:12:49.0000] n0a___: well if you're already in the spec you can read https://fetch.spec.whatwg.org/#preface which should make things pretty clear [06:13:20.0000] like I said, ppl do quote the spec so it's out of context [06:13:25.0000] https://code.google.com/p/chromium/issues/detail?id=455116 [06:17:00.0000] I’m pushing svg4everybody v2 today. Any last minute pass over the README.md is very welcome: https://github.com/jonathantneal/svg4everybody/tree/feature/2.0.0 [06:17:42.0000] gosh this is messy now they want to remove it https://code.google.com/p/chromium/issues/detail?id=515786 [06:19:02.0000] reminds me of IE5 and document fragments [06:19:31.0000] implemented removed reimplemented [06:20:56.0000] n0a___: not too messy, we knew shipping aggressively may mean making breaking changes. I haven't seen a lot of use of it, although we're going to gather evidence [06:21:22.0000] well I am starting [06:21:56.0000] but something that puzzled me is the lack of type for the Response object [06:22:17.0000] as if you have to know the type [06:23:34.0000] and even more confusing is that we have https://developer.mozilla.org/en-US/docs/Web/API/Response/type [06:24:08.0000] n0a___: what type do you want? [06:24:15.0000] as in, what information are you wanting? [06:24:33.0000] If it's content type, look at the headers [06:24:36.0000]