| 00:02 | <esprehn> | JakeA: it was awesome |
| 02:18 | <Ascend> | Hello fetch developers |
| 02:19 | <Ascend> | Does anybody have an idea when the fetch standard will be set in stone, so that we can use it in production? |
| 02:26 | <boogyman> | Ascend: http://caniuse.com/#search=fetch |
| 02:31 | <Domenic> | Ascend: set in stone, never. https://wiki.whatwg.org/wiki/FAQ#What_does_.22Living_Standard.22_mean.3F use in production, see http://caniuse.com/#search=fetch |
| 06:28 | <annevk> | For anyone with an html5.org ssh account, DreamHost moved servers, so you might get the "this is wrong" message... |
| 08:23 | <annevk> | JakeA: btw, I'm not sure I'm the best person to review your service worker / fetch test |
| 08:24 | <annevk> | JakeA: maybe jungkees could do it or someone implementing? |
| 08:24 | <annevk> | JakeA: ah, Mek? |
| 08:35 | <JakeA> | annevk: the PR auto-pinged mek & ehsan |
| 08:35 | <annevk> | JakeA: good times |
| 08:35 | <JakeA> | (because they're in the owners file) |
| 08:36 | <annevk> | JakeA: FWIW, the new WHATWG process is such that we land the spec PR after the test PR lands |
| 08:36 | <annevk> | I should probably get foolip_sheriff to document that somewhere |
| 08:38 | <ehsan> | JakeA: which PR? |
| 08:38 | <JakeA> | annevk: gotcha. I'll be proactive about getting someone to review the test |
| 08:42 | <annevk> | ehsan: https://github.com/w3c/web-platform-tests/pull/4518 |
| 09:24 | <ehsan> | annevk: it's unlikely I'll get to that soon :/ |
| 10:19 | <foolip_sheriff> | annevk, JakeA: https://github.com/whatwg/html/blob/master/CONTRIBUTING.md#tests and https://github.com/whatwg/html/blob/master/TEAM.md#handling-pull-requests is the current documentation, do we need more? |
| 10:22 | <annevk> | foolip_sheriff: one thing we need to do somehow is elevate the requirements to whatwg/* |
| 10:22 | <annevk> | foolip_sheriff: perhaps by moving this kind of documentation to whatwg/meta? Although I guess that would make it a little more annoying to get to |
| 10:41 | <foolip_sheriff> | annevk: do you think we can declare the experiment a success and "encourage" tests everywhere? |
| 10:43 | <annevk> | foolip_sheriff: yeah |
| 10:44 | <foolip_sheriff> | annevk: I'm writing a short comment on https://github.com/whatwg/html/issues/1849 to ask how everyone is finding it. |
| 10:44 | <annevk> | foolip_sheriff: in particular it would be good if it was part of the PR guidelines |
| 10:44 | <annevk> | https://github.com/w3c/dom/issues o_O |
| 10:45 | <annevk> | It's really hard to sympathize with what's going on there |
| 11:00 | <foolip_sheriff> | annevk: https://github.com/whatwg/html/issues/1849#issuecomment-271840126 |
| 11:01 | <foolip_sheriff> | annevk: wait, they didn't start from an up-to-date copy of the spec? |
| 11:02 | <annevk> | foolip_sheriff: I don't even, somewhat surprised to see rbyers cheering them on, despite it failing massively last time around |
| 11:02 | <foolip_sheriff> | annevk: cheering, or just being polite? |
| 11:03 | <annevk> | foolip_sheriff: https://github.com/w3c/dom/issues/13 |
| 11:24 | <MikeSmith> | the responsible party there seems well-intentioned and acting in good faith to carry out the task as it’s been explained to them |
| 11:25 | <MikeSmith> | that said, I guess it’s not super encouraging that for something which intends to be seen as a referencable spec for the DOM, the person working on it does not have an accurate understanding of the implementation status of Shadow DOM, nor apparently understand how in general to get an accurate understanding of the implementation status for a feature |
| 11:27 | <MikeSmith> | regardless this reminds me that we need to come up with better guidelines for editors, whatever they’re working on |
| 11:29 | <MikeSmith> | regardless of what they are working on there are some basic things to know about so they at least don’t end up costing other people time to explain to them |
| 11:30 | <MikeSmith> | like, our editor guidelines should say, Do not assume any site anywhere has accurate information about the implementation status of something. If you want to determine implementation status, find test or make test and run them yourself in different UAs to see what the results are. |
| 11:31 | <MikeSmith> | etc. |
| 12:23 | <rbyers> | Annevk: I wouldn't say I'm cheering them on. I started by trying to fix the references to W3C Dom in PE: https://github.com/w3c/pointerevents/issues/160 |
| 12:27 | <annevk> | rbyers: apologies, should have gotten lunch first |
| 12:27 | <rbyers> | .. My "always up to date" requirement was something I assumed would never happen. |
| 12:30 | <rbyers> | But after reading slightlyoff@'s take on this, I'm trying hard not to be hostile about it. It sucks and I'm not going to waste any time reading/PRing it. |
| 12:31 | <rbyers> | But I'm not going to stand in their way or refuse to file bugs when asked... |
| 12:38 | <annevk> | Sounds interesting, but prolly internal? |
| 12:45 | <annevk> | foolip_sheriff: FWIW, Fetch and URL have also used the "require tests" policy and it's been working out well, though with Fetch it's trickier sometimes to get good tests (new features) |
| 12:47 | <foolip_sheriff> | annevk: awesome, looks like there's a future in this tests thing. new features are indeed tricky, whatever you learn from Fetch would be great to document somehow. I suppose in some cases tests are punted? |
| 12:47 | <annevk> | foolip_sheriff: what happens is that we end up with one or a couple trivial tests |
| 12:48 | <annevk> | foolip_sheriff: see e.g. https://github.com/whatwg/fetch/pull/425 which really needs hundreds of tests |
| 12:48 | <foolip_sheriff> | annevk: is anyone attempting to track what's still missing tests? |
| 12:48 | <annevk> | foolip_sheriff: but hopefully those will be written during implementation |
| 12:48 | <annevk> | foolip_sheriff: nope |
| 12:49 | <foolip_sheriff> | Although it's not at all obvious that trying to be pedantic about maintaining such a "missing tests" list would be the best use of time, it's easy to see it become just a huge list of TODOs, and someone else just starts from scratch ignoring it. |
| 12:49 | <annevk> | foolip_sheriff: also, what we found with URL is that having an implementation modified per spec changes and then run the tests is kinda vital to ensuring the new tests and spec changes are good |
| 12:49 | <annevk> | foolip_sheriff: it's hard to tell from just new tests and new spec text alone without having an impl |
| 12:51 | <foolip_sheriff> | annevk: yeah, I think this all works best with small iterative changes a la HTML or URL, I guess for new things one could leave it just untested until there is an implementation, and then do one big pass of what test coverage is still there. Although it should be a good citizen implementer doing that. |
| 12:53 | <annevk> | foolip_sheriff: as for "missing tests", couldn't we use code coverage tooling for that? |
| 12:55 | <annevk> | foolip_sheriff: with URL it wasn't new things, it was just existing algorithms that were wrong in some way, but the newly written algorithm wasn't necessarily correct either |
| 12:55 | <foolip_sheriff> | annevk: probably for one-off checks that would work, but unless the implementation has the spec algorithms all in one place it might be tricky to see what steps have missing error handling tests and so on |
| 12:55 | <foolip> | maybe nobody cares that I'm sheriff today :) |
| 12:56 | <foolip> | (it's for #chromium) |
| 13:09 | <jgraham> | foolip: I don't know, it was fun to imagine you in a nice hat with a shiny badge |
| 13:09 | <foolip> | jgraham: https://sheriff-o-matic.appspot.com/chromium does have a shiny favicon.ico |
| 13:12 | <jgraham> | foolip: And a very boring acces denied page :) |
| 13:12 | <foolip> | jgraham: oh. well the page itself is boring too. |
| 13:48 | <annevk> | If I have promise_test(() => { fetch().then(...) }), why does adding a return statement before fetch() help? |
| 13:49 | <annevk> | Because of the { and } it seems? |
| 13:49 | <annevk> | I guess I still don't understand how things work |
| 13:51 | <Domenic> | annevk: yeah because of the { and } |
| 13:52 | <JakeA> | annevk: () => blah(); is shorthand for () => { return blah(); } |
| 13:54 | <annevk> | I think I ran into this at least once or twice before, things just no longer stick in memory |
| 13:55 | <JakeA> | welcome to getting older |
| 13:56 | <JakeA> | "what did I come into this room for?", "where are my pants?", "whose garden is this?" all things to look forward to |
| 13:56 | <jgraham> | annevk being old is terrifying |
| 13:57 | <jgraham> | Soon gsnedders will be old and then I'll be the one in the corner sobbing |
| 13:57 | <annevk> | gsnedders is still a teen, right? |
| 17:15 | <gsnedders> | annevk: yeah, I'm twenty-four-teen |
| 17:16 | <MikeSmith> | heh |
| 17:22 | <Domenic> | Do we have other restriction models? So far I can think of iframe sandboxing, allow* attributes/feature policy, and secure contexts. https://github.com/whatwg/html/issues/2259#issuecomment-271931992 |
| 17:27 | <JakeA> | Domenic: CSP, x-iframe-options |
| 17:27 | <Domenic> | Ooh, good ones |
| 17:27 | <JakeA> | Domenic: rel=noopener |
| 17:27 | <Domenic> | Everyone loves rel=noopener |
| 17:31 | <Domenic> | I feel like this deserves some kind of reference page or blog post or something. |
| 17:31 | <Domenic> | I actually realized I don't have a great sense of how CSP works... I just know that if I want to productionize a website I should try to slap as tight of a CSP policy on it as possible. |
| 17:32 | <tobie> | CSPs break bookmarklets and that makes me super sad. I get why, but still. :'-( |
| 17:50 | <annevk> | Domenic: same-origin policy? |
| 17:59 | <annevk> | gsnedders: even if it's not getting fixed, I'm curious to dig for rationale |
| 17:59 | <annevk> | gsnedders: having more control over the server in WPT would be great though |
| 17:59 | <annevk> | gsnedders: and I'd be happy to see a rewrite that also allows early responses |
| 18:04 | <gsnedders> | annevk: essentially, they use RFC2822-like parsing for it |
| 18:05 | <gsnedders> | annevk: which I think matches RFC 2616? |
| 18:06 | <annevk> | gsnedders: it doesn't afaict |
| 18:07 | <annevk> | gsnedders: only HT, CR, LF, and SP count as whitespace in HTTP |
| 18:08 | <gsnedders> | it says they do, but then the ABNF disagrees, I think? |
| 18:08 | <annevk> | gsnedders: no |
| 18:08 | <gsnedders> | "HTTP header fields […] follow the same generic format as that given in Section 3.1 of RFC 822" |
| 18:09 | <annevk> | gsnedders: oh, you meant it the other way around |
| 18:09 | <jochen__> | annevk: if you have a chance, could you have a look at https://github.com/w3c/webappsec-referrer-policy/issues/89 and the PR I linked to whether this makes sense? |
| 18:09 | <gsnedders> | annevk: yeah |
| 18:09 | <gsnedders> | "Request (section 5) and Response (section 6) messages use the generic message format of RFC 822" |
| 18:10 | <annevk> | gsnedders: I don't see anything in 822 that is special for 0B and 0C though |
| 18:11 | <annevk> | gsnedders: uses the exact same productions afaict |
| 18:12 | <jgraham> | FWIW it might be possible to rewrite just the header parsing in wptserve by making a class with the same interface as mimetools.Message |
| 18:12 | <gsnedders> | yeah, I think it is |
| 18:12 | <jgraham> | It's just defined as a class attribute so it's swappable without replacing the entire server class |
| 18:13 | <jgraham> | (OTOH that won't give you early responses or so) |
| 18:13 | <gsnedders> | I think we probably want to do something that works for HTTP/2 well at the same time |
| 18:14 | <jgraham> | Well |
| 18:14 | <annevk> | jochen__: it seems that doesn't quite address bz's comment |
| 18:14 | <annevk> | jochen__: if presentation attributes turn into some kind of CSS declaration block too that is |
| 18:14 | <jgraham> | I think that http/2 might end up using hyper or something to provide the protocol implementation |
| 18:14 | <gsnedders> | jgraham: right |
| 18:14 | <jgraham> | (the python thing, not the similarly named rust thing) |
| 18:14 | <jgraham> | So I don't see how that would affect the HTTP/1 case |
| 18:15 | <gsnedders> | annevk: https://github.com/python/cpython/blob/2.7/Lib/email/feedparser.py is the thing used ultimately |
| 18:15 | <annevk> | jochen__: my advice is again to ask the CSS WG how the layering works, since I think there's not enough terminology/layering to describe what we need |
| 18:16 | <gsnedders> | jgraham: we want the same API to get responses, no? |
| 18:16 | <annevk> | gsnedders: maybe the rather sloppy lastvalue = [line[i+1:].lstrip()] is the culprit? |
| 18:16 | <gsnedders> | annevk: oh, probably |
| 18:18 | <jgraham> | gsnedders: Yeah, that's a reasonable point. I haven't looked into the http2 case enough to figure out if it will require breaking api changes though |
| 18:19 | <jgraham> | For the internal API exposed to .py handlers I mean |
| 18:19 | <annevk> | jgraham: there's also a small desire to be able to transmit HTTP/1.0 responses, but I think that's possible right? |
| 18:19 | <annevk> | jgraham: some stream stuff should fail on HTTP/1.0, but not HTTP/1.1 |
| 18:21 | <jgraham> | Hmm, I'm not actually sure that you can do that easilly at the moment because it's baked into the server that it's a HTTP 1.1 server. Although you can certainly write a raw response, which is probably fine for the small number of cases that require it |
| 18:22 | <annevk> | Yeah, I think that's all we need |
| 18:22 | <gsnedders> | equally the 0.9 response case |
| 18:23 | <gsnedders> | jgraham: HTTP/2 adds the ability to do duplex stuff so we need API extensions but they should be optional for handlers |
| 18:23 | <gsnedders> | jgraham: e.g., so they can push resources |
| 18:26 | <gsnedders> | jgraham: we probably just *optionally* let the handler have a new arg, and handle the case when we get a TypeError throwing it? |
| 18:26 | <jochen__> | annevk: I'm trying that since a few months, and so did Boris, but we haven't gotten any answer :-/ |
| 18:32 | <jgraham> | gsnedders: Yeah I'm sure it's possible to design a thing |
| 18:35 | gsnedders | is so sleep deprived, did not sleep well last night ;_; |
| 18:38 | <jgraham> | Is it a CSS meeting or something? |
| 18:40 | <gsnedders> | yeah |
| 18:41 | <Domenic> | Oh dang, new CSSOM became mutable again |
| 18:41 | gsnedders | is going through his red-ink covered copy of the wpt docs |
| 19:05 | <annevk> | jochen__: no fast access to TabAtkins for you? |
| 19:06 | <annevk> | jochen__: did you file an issue? |
| 19:25 | <TabAtkins> | Wait what's up? |
| 19:26 | <TabAtkins> | Yeah, I haven't seen this particular issue. :/ |
| 19:26 | <TabAtkins> | Domenic: Yeah, mutable but not live. |
| 19:27 | <TabAtkins> | Was an efficiency issue - you can now create a complex object (like a transform list) and just tweak it and repeatedly re-set it, rather than having to constrantly create new objects. |
| 19:56 | <gsnedders> | annevk: so Foo: b\x0bar should result in a Foo header with a value of b\x0bar right? |
| 19:59 | <gsnedders> | Which doesn't work per RFC 822 and its sucessors because a field value cannot contain \x0b |
| 20:01 | <annevk> | gsnedders: that already works |
| 20:02 | <annevk> | gsnedders: leading or trailing is the issue |
| 20:02 | <gsnedders> | does it? |
| 20:02 | <annevk> | gsnedders: see the test I wrote |
| 20:02 | <gsnedders> | then WTF am I seeing happen |
| 20:03 | <annevk> | Sleep deprivation? 😜 |
| 20:03 | <gsnedders> | :) |
| 20:03 | <annevk> | I might be missing something though, more time tomorrow |
| 20:04 | <gsnedders> | Trying this in the Python command-line has this work fine |
| 20:05 | <gsnedders> | oh wait |
| 20:06 | <gsnedders> | I'm testing the wrong thing |
| 20:18 | <gsnedders> | annevk: okay, so this is fixed in Py3 |
| 20:22 | <gsnedders> | given, e..g, Access-Control-Allow-Origin, we could try making this out to be a security issue |
| 22:46 | <zcorpan> | MikeSmith: There's no body. bug? doesn't happen in firefox in live dom viewer. https://checker.html5.org/parsetree/?parser=html5&content=<%21doctype+html><template><plaintext>a<%2Ftemplate>b&submit=Print+Tree |
| 23:07 | <tobie> | Domenic, annevk: in the infra standard, would it make sense to have a dfn for a map entry, list item, etc.? |
| 23:07 | <Domenic> | tobie: yeah it probably would |
| 23:37 | <tobie> | Domenic: for lists, sets, queues and stacks, it's clearly "item", it's less consistant for maps which use: "key/value pair", "entry", and "item". |
| 23:38 | <Domenic> | Good bug report :). I guess I would pick entry? "Each key/value pair is called an entry"? |
| 23:39 | <tobie> | Domenic: likewise |