freenode :: #whatwg

11 Jan 2017
00:02esprehnJakeA: it was awesome
02:18AscendHello fetch developers
02:19AscendDoes anybody have an idea when the fetch standard will be set in stone, so that we can use it in production?
02:26boogymanAscend: http://caniuse.com/#search=fetch
02:31DomenicAscend: 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:28annevkFor anyone with an html5.org ssh account, DreamHost moved servers, so you might get the "this is wrong" message...
08:23annevkJakeA: btw, I'm not sure I'm the best person to review your service worker / fetch test
08:24annevkJakeA: maybe jungkees could do it or someone implementing?
08:24annevkJakeA: ah, Mek?
08:35JakeAannevk: the PR auto-pinged mek & ehsan
08:35annevkJakeA: good times
08:35JakeA(because they're in the owners file)
08:36annevkJakeA: FWIW, the new WHATWG process is such that we land the spec PR after the test PR lands
08:36annevkI should probably get foolip_sheriff to document that somewhere
08:38ehsanJakeA: which PR?
08:38JakeAannevk: gotcha. I'll be proactive about getting someone to review the test
08:42annevkehsan: https://github.com/w3c/web-platform-tests/pull/4518
09:24ehsanannevk: it's unlikely I'll get to that soon :/
10:19foolip_sheriffannevk, 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:22annevkfoolip_sheriff: one thing we need to do somehow is elevate the requirements to whatwg/*
10:22annevkfoolip_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:41foolip_sheriffannevk: do you think we can declare the experiment a success and "encourage" tests everywhere?
10:43annevkfoolip_sheriff: yeah
10:44foolip_sheriffannevk: I'm writing a short comment on https://github.com/whatwg/html/issues/1849 to ask how everyone is finding it.
10:44annevkfoolip_sheriff: in particular it would be good if it was part of the PR guidelines
10:44annevkhttps://github.com/w3c/dom/issues o_O
10:45annevkIt's really hard to sympathize with what's going on there
11:00foolip_sheriffannevk: https://github.com/whatwg/html/issues/1849#issuecomment-271840126
11:01foolip_sheriffannevk: wait, they didn't start from an up-to-date copy of the spec?
11:02annevkfoolip_sheriff: I don't even, somewhat surprised to see rbyers cheering them on, despite it failing massively last time around
11:02foolip_sheriffannevk: cheering, or just being polite?
11:03annevkfoolip_sheriff: https://github.com/w3c/dom/issues/13
11:24MikeSmiththe responsible party there seems well-intentioned and acting in good faith to carry out the task as its been explained to them
11:25MikeSmiththat said, I guess its 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:27MikeSmithregardless this reminds me that we need to come up with better guidelines for editors, whatever theyre working on
11:29MikeSmithregardless of what they are working on there are some basic things to know about so they at least dont end up costing other people time to explain to them
11:30MikeSmithlike, 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:31MikeSmithetc.
12:23rbyersAnnevk: 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:27annevkrbyers: apologies, should have gotten lunch first
12:27rbyers.. My "always up to date" requirement was something I assumed would never happen.
12:30rbyersBut 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:31rbyersBut I'm not going to stand in their way or refuse to file bugs when asked...
12:38annevkSounds interesting, but prolly internal?
12:45annevkfoolip_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:47foolip_sheriffannevk: 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:47annevkfoolip_sheriff: what happens is that we end up with one or a couple trivial tests
12:48annevkfoolip_sheriff: see e.g. https://github.com/whatwg/fetch/pull/425 which really needs hundreds of tests
12:48foolip_sheriffannevk: is anyone attempting to track what's still missing tests?
12:48annevkfoolip_sheriff: but hopefully those will be written during implementation
12:48annevkfoolip_sheriff: nope
12:49foolip_sheriffAlthough 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:49annevkfoolip_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:49annevkfoolip_sheriff: it's hard to tell from just new tests and new spec text alone without having an impl
12:51foolip_sheriffannevk: 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:53annevkfoolip_sheriff: as for "missing tests", couldn't we use code coverage tooling for that?
12:55annevkfoolip_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:55foolip_sheriffannevk: 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:55foolipmaybe nobody cares that I'm sheriff today :)
12:56foolip(it's for #chromium)
13:09jgrahamfoolip: I don't know, it was fun to imagine you in a nice hat with a shiny badge
13:09foolipjgraham: https://sheriff-o-matic.appspot.com/chromium does have a shiny favicon.ico
13:12jgrahamfoolip: And a very boring acces denied page :)
13:12foolipjgraham: oh. well the page itself is boring too.
13:48annevkIf I have promise_test(() => { fetch().then(...) }), why does adding a return statement before fetch() help?
13:49annevkBecause of the { and } it seems?
13:49annevkI guess I still don't understand how things work
13:51Domenicannevk: yeah because of the { and }
13:52JakeAannevk: () => blah(); is shorthand for () => { return blah(); }
13:54annevkI think I ran into this at least once or twice before, things just no longer stick in memory
13:55JakeAwelcome to getting older
13:56JakeA"what did I come into this room for?", "where are my pants?", "whose garden is this?" all things to look forward to
13:56jgrahamannevk being old is terrifying
13:57jgrahamSoon gsnedders will be old and then I'll be the one in the corner sobbing
13:57annevkgsnedders is still a teen, right?
17:15gsneddersannevk: yeah, I'm twenty-four-teen
17:16MikeSmithheh
17:22DomenicDo 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:27JakeADomenic: CSP, x-iframe-options
17:27DomenicOoh, good ones
17:27JakeADomenic: rel=noopener
17:27DomenicEveryone loves rel=noopener
17:31DomenicI feel like this deserves some kind of reference page or blog post or something.
17:31DomenicI 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:32tobieCSPs break bookmarklets and that makes me super sad. I get why, but still. :'-(
17:50annevkDomenic: same-origin policy?
17:59annevkgsnedders: even if it's not getting fixed, I'm curious to dig for rationale
17:59annevkgsnedders: having more control over the server in WPT would be great though
17:59annevkgsnedders: and I'd be happy to see a rewrite that also allows early responses
18:04gsneddersannevk: essentially, they use RFC2822-like parsing for it
18:05gsneddersannevk: which I think matches RFC 2616?
18:06annevkgsnedders: it doesn't afaict
18:07annevkgsnedders: only HT, CR, LF, and SP count as whitespace in HTTP
18:08gsneddersit says they do, but then the ABNF disagrees, I think?
18:08annevkgsnedders: no
18:08gsnedders"HTTP header fields [] follow the same generic format as that given in Section 3.1 of RFC 822"
18:09annevkgsnedders: oh, you meant it the other way around
18:09jochen__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:09gsneddersannevk: yeah
18:09gsnedders"Request (section 5) and Response (section 6) messages use the generic message format of RFC 822"
18:10annevkgsnedders: I don't see anything in 822 that is special for 0B and 0C though
18:11annevkgsnedders: uses the exact same productions afaict
18:12jgrahamFWIW it might be possible to rewrite just the header parsing in wptserve by making a class with the same interface as mimetools.Message
18:12gsneddersyeah, I think it is
18:12jgrahamIt's just defined as a class attribute so it's swappable without replacing the entire server class
18:13jgraham(OTOH that won't give you early responses or so)
18:13gsneddersI think we probably want to do something that works for HTTP/2 well at the same time
18:14jgrahamWell
18:14annevkjochen__: it seems that doesn't quite address bz's comment
18:14annevkjochen__: if presentation attributes turn into some kind of CSS declaration block too that is
18:14jgrahamI think that http/2 might end up using hyper or something to provide the protocol implementation
18:14gsneddersjgraham: right
18:14jgraham(the python thing, not the similarly named rust thing)
18:14jgrahamSo I don't see how that would affect the HTTP/1 case
18:15gsneddersannevk: https://github.com/python/cpython/blob/2.7/Lib/email/feedparser.py is the thing used ultimately
18:15annevkjochen__: 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:16gsneddersjgraham: we want the same API to get responses, no?
18:16annevkgsnedders: maybe the rather sloppy lastvalue = [line[i+1:].lstrip()] is the culprit?
18:16gsneddersannevk: oh, probably
18:18jgrahamgsnedders: 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:19jgrahamFor the internal API exposed to .py handlers I mean
18:19annevkjgraham: there's also a small desire to be able to transmit HTTP/1.0 responses, but I think that's possible right?
18:19annevkjgraham: some stream stuff should fail on HTTP/1.0, but not HTTP/1.1
18:21jgrahamHmm, 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:22annevkYeah, I think that's all we need
18:22gsneddersequally the 0.9 response case
18:23gsneddersjgraham: HTTP/2 adds the ability to do duplex stuff so we need API extensions but they should be optional for handlers
18:23gsneddersjgraham: e.g., so they can push resources
18:26gsneddersjgraham: we probably just *optionally* let the handler have a new arg, and handle the case when we get a TypeError throwing it?
18:26jochen__annevk: I'm trying that since a few months, and so did Boris, but we haven't gotten any answer :-/
18:32jgrahamgsnedders: 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:38jgrahamIs it a CSS meeting or something?
18:40gsneddersyeah
18:41DomenicOh dang, new CSSOM became mutable again
18:41* gsnedders is going through his red-ink covered copy of the wpt docs
19:05annevkjochen__: no fast access to TabAtkins for you?
19:06annevkjochen__: did you file an issue?
19:25TabAtkinsWait what's up?
19:26TabAtkinsYeah, I haven't seen this particular issue. :/
19:26TabAtkinsDomenic: Yeah, mutable but not live.
19:27TabAtkinsWas 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:56gsneddersannevk: so Foo: b\x0bar should result in a Foo header with a value of b\x0bar right?
19:59gsneddersWhich doesn't work per RFC 822 and its sucessors because a field value cannot contain \x0b
20:01annevkgsnedders: that already works
20:02annevkgsnedders: leading or trailing is the issue
20:02gsneddersdoes it?
20:02annevkgsnedders: see the test I wrote
20:02gsneddersthen WTF am I seeing happen
20:03annevkSleep deprivation?
20:03gsnedders:)
20:03annevkI might be missing something though, more time tomorrow
20:04gsneddersTrying this in the Python command-line has this work fine
20:05gsneddersoh wait
20:06gsneddersI'm testing the wrong thing
20:18gsneddersannevk: okay, so this is fixed in Py3
20:22gsneddersgiven, e..g, Access-Control-Allow-Origin, we could try making this out to be a security issue
22:46zcorpanMikeSmith: There&#39;s no body. bug? doesn&#39;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:07tobieDomenic, annevk: in the infra standard, would it make sense to have a dfn for a map entry, list item, etc.?
23:07Domenictobie: yeah it probably would
23:37tobieDomenic: for lists, sets, queues and stacks, it&#39;s clearly &quot;item&quot;, it&#39;s less consistant for maps which use: &quot;key/value pair&quot;, &quot;entry&quot;, and &quot;item&quot;.
23:38DomenicGood bug report :). I guess I would pick entry? &quot;Each key/value pair is called an entry&quot;?
23:39tobieDomenic: likewise
12 Jan 2017
No messages
   
Last message: 5 days and 18 hours ago