| 06:38 | <annevk> | yhirano_: hey, do you want me to rebase and all that? |
| 06:39 | <annevk> | yhirano_: cause it looks good now, apart from that |
| 06:46 | <yhirano_> | annevk: yeah, I'll do |
| 06:46 | <annevk> | yhirano_: thank you |
| 06:57 | <annevk> | yhirano_: all good now? |
| 07:04 | <yhirano_> | annevk: i'm reading through now, so please wait for a minute. |
| 07:05 | <annevk> | sure |
| 07:24 | <annevk> | yhirano_: can you remove the "." from the commit title? |
| 07:25 | <annevk> | yhirano_: perhaps make the title "Fix #118: add Response.prototype.body" |
| 07:27 | <yhirano_> | annevk: got it >> "." |
| 07:27 | <yhirano_> | annevk: I plan to add example (https://github.com/yutakahirano/fetch-with-streams/#fetch-api) as a separate commit so i planned to close the issue after that |
| 07:28 | <yhirano_> | annevk: though it is possible to include the example change in this commit |
| 07:28 | <annevk> | yhirano_: new PR is fine |
| 07:35 | <yhirano_> | annevk: fixed the commit title and message |
| 07:41 | <mkwst> | annevk, JakeA: I'm around if you two still have concerns about the Fetch handling proposed in the CSP3 draft. |
| 07:41 | <mkwst> | Or we can chat later today. Whatever works. |
| 07:43 | <annevk> | mkwst: working on something else at the moment, but have you thought through whether it makes sense for the service worker to be able to set the policy of a synthetic response (or perhaps a non-opaque response it got from somewhere) similar to how a server can? |
| 07:45 | <mkwst> | annevk: I'd like to get this bit hammered out this week, but no rush to get it done today. If you're busy, we can chat later. |
| 07:47 | <mkwst> | annevk: To the specific question, the SW is the network, right? I don't see why it wouldn't be able to set headers on a response. There are particular headers that must take effect before the SW has a chance to screw with them (`clear-site-data` comes to mind), but I guess if the SW can create an entirely synthetic response, there's no real value in |
| 07:47 | <mkwst> | restricting its access to the CSP header. |
| 07:48 | <annevk> | mkwst: given that you patched HTTP-network fetch, it wouldn't have any effect |
| 07:49 | <mkwst> | annevk: Ah, I see the concern. Yeah. It makes sense that we'd need to parse the headers somewhere further down for that case. |
| 07:49 | <mkwst> | Not sure how to do that and preserve the option to effect `set-cookie` behavior, but I'll hack something together and ask you to take a look at it later. |
| 07:50 | <mkwst> | n:1 |
| 07:52 | <annevk> | Affecting the set-cookie header sounds intriguing, I guess I should review that |
| 08:02 | <mkwst> | annevk: I guess I should write it up. Will eventually live in https://w3c.github.io/webappsec-csp/cookies/, which modifies cookies currently, but also needs to poke at Fetch. |
| 08:06 | <annevk> | mkwst: interesting |
| 08:07 | <annevk> | mkwst: https://w3c.github.io/webappsec-csp/cookies/#monkey-patching-rfc6264 should be a patch to Fetch afaict |
| 08:08 | <annevk> | mkwst: although I guess if you're going to do this on a per-cookie basis... hmm |
| 08:08 | <annevk> | mkwst: I guess in that case you'd have to do that |
| 08:08 | <annevk> | mkwst: although "none" could still be handled at the Fetch level |
| 08:09 | <mkwst> | We need to do that for `document.cookie = 'x=y';`. I guess we could do more granular `set-cookie` handling in Fetch, but if we're already doing it here for the JS interface, there's not much advantage in doing it twice. |
| 08:09 | <mkwst> | 'none' could certainly be handled in Fetch. |
| 08:11 | <mkwst> | annevk: I'll try to spell it out in more detail today and send it over for you to skim. |
| 08:11 | <annevk> | mkwst: I would really prefer we just give an API to block document.cookie/domain |
| 08:11 | <annevk> | mkwst: HTTP-based API |
| 08:11 | <annevk> | mkwst: instead of granular control over what can be set |
| 08:12 | <mkwst> | annevk: Why? |
| 08:12 | <annevk> | mkwst: even with granular control you can still exhaust the store through XSS |
| 08:13 | <annevk> | mkwst: because both are bad APIs and should be avoided |
| 08:13 | <mkwst> | annevk: Yes. Both should be avoided. And we should give folks the ability to turn them off (and I plan to). |
| 08:14 | <mkwst> | annevk: But apps use them, for better or worse. Allowing them to lock down the usage to their specific needs seems like a way of allowing those apps to harden themselves, and doesn't seem like it adds substantial complexity. |
| 08:14 | <mkwst> | annevk: I'll write it up one way or the other, and we can argue about whether or not it makes sense. :) |
| 08:15 | <annevk> | mkwst: I'd rather always block those two and offer a new asynchronous API where you would get more granular access |
| 08:15 | <annevk> | but okay, will wait |
| 08:16 | <mkwst> | *shrug* I think it's better to spend our time getting CSP's integrations into shape, and then we can argue about what kind of new stuff to add on top. :) |
| 08:16 | <mkwst> | So when I said "today", I think I was lying. :) |
| 08:31 | <Ms2ger> | > Symbol.iterator is undefined for document.all |
| 08:31 | <Ms2ger> | ._. |
| 09:37 | <Mikaela> | Hi, I am wondering `Error: Bad value Content-Security-Policy for attribute http-equiv on element meta.` which I get when validating my site. From what I have understood it's w3 standard, so why would it cause validation error? Or was that just invented by caniuse.com or Chrome? http://caniuse.com/#feat=upgradeinsecurerequests Validation results in question: |
| 09:37 | <Mikaela> | https://validator.w3.org/nu/?doc=https%3A%2F%2Fmikaela.info%2F |
| 09:39 | <Ms2ger> | http-equiv doesn't support all headers |
| 09:39 | <Ms2ger> | However, I seem to recall ongoing work to support CSP there |
| 09:40 | <Mikaela> | I see, so I can just safely ignore it for now? |
| 09:41 | <Ms2ger> | I don't think it'll do anything right now, so you can ignore it unless you actually want CSP to apply |
| 09:42 | <Mikaela> | thanks, It does apply on Chrome, no idea on the others |
| 09:43 | <Ms2ger> | mkwst, ^ |
| 09:43 | <mkwst> | Ask MikeSmith. |
| 09:43 | <mkwst> | I added it to HTML, but I don't think the validator is updated yet. |
| 09:44 | <mkwst> | https://html.spec.whatwg.org/#attr-meta-http-equiv-content-security-policy |
| 09:47 | <mkwst> | Mikaela: That directive in particular works in Chrome today, and will work in Firefox 42+. |
| 09:48 | <Mikaela> | and is valid? |
| 09:48 | <Mikaela> | (that link seems to be loading forever here) |
| 09:49 | <mkwst> | Mikaela: Yes. The HTML spec is monstrous. It'll take forever to load, but once it does, you'll see that the `http-equiv` value is indeed specified. |
| 09:49 | <Mikaela> | thanks :) |
| 09:49 | <mkwst> | Mikaela: The validator hasn't been updated, which is reasonable, since the value just got added to the spec ~weeks ago. |
| 09:50 | <Ms2ger> | https://html.spec.whatwg.org/multipage/#attr-meta-http-equiv-content-security-policy is less monstrous |
| 09:50 | <MikeSmith> | Mikaela: yeah, sorry I've just not made time to update the sources of the HTML checker yet |
| 09:51 | <Ms2ger> | On an unrelated note, is there a way to write a css rule that's overridden by a preshint? |
| 09:51 | <Mikaela> | no problem, I was just curious as I was quite sure that it's valid |
| 09:51 | <Mikaela> | that less monstrous version works, thanks |
| 09:52 | <Ms2ger> | zcorpan, surely you'd know that ^ :) |
| 09:53 | <zcorpan> | Ms2ger: write it in your user stylesheet without !important |
| 09:53 | <zcorpan> | not very test-friendly |
| 09:54 | <raintrap_> | hey guys, any nice WYSIWYG editor you can recommend? |
| 09:55 | <Ms2ger> | zcorpan, yeah, no :) |
| 09:55 | <Ms2ger> | I don't want this test that badly |
| 09:58 | <zcorpan> | preshint vs UA style is not material to interop anyway |
| 09:59 | <Ms2ger> | I was trying to test whether ol type=decimal is supported |
| 09:59 | <Ms2ger> | But if it only affects people with weird user styles.. Meh |
| 10:00 | <annevk> | MikeSmith: http://dev.w3.org/html5/html4-differences/ redirects to a 404 |
| 10:00 | <Ms2ger> | Is that bad? :) |
| 10:01 | <zcorpan> | Ms2ger: you can test <ul><li type=decimal> though |
| 10:01 | <annevk> | Ms2ger: someone emailed me and suggest I replace a link from my site to that location with some spam |
| 10:15 | <nox> | annevk: Sorry for the useless issue. :) |
| 10:15 | <annevk> | it's cool, I think I mistakenly reported that one too once |
| 10:37 | <MikeSmith> | annevk: hmm yeah lemme fix that |
| 10:39 | <MikeSmith> | ah good after upgrading to El Capitan it seems there's no longer an Apple-provided cvs command |
| 10:39 | <MikeSmith> | which is as things should be |
| 10:39 | MikeSmith | homebrews is |
| 10:43 | <MikeSmith> | annevk: fixed that redirect |
| 10:43 | <MikeSmith> | thanks for the heads-up |
| 10:43 | <annevk> | MikeSmith: brave new era of useful spam |
| 10:48 | <MikeSmith> | hah |
| 10:49 | <MikeSmith> | achievement unlocked, found a valid use case for spam |
| 10:52 | <MikeSmith> | in similar news, we found somebody actually prefers the IETF for something https://twitter.com/mikewest/status/651342403962601473 |
| 10:52 | <MikeSmith> | will wonders never cease |
| 10:54 | <annevk> | lol, creating a new IANA registry |
| 10:56 | <mkwst> | Oh, the exciting life of me. |
| 10:56 | <mkwst> | The IETF's publication system is so simple. It puts the W3C's to shame. |
| 10:57 | <mkwst> | I think I've mentioned this before. |
| 11:00 | <MikeSmith> | yeah among other things, the result is great for weeding out the people who might ever want try to read some part a spec on a smartphone |
| 11:01 | <MikeSmith> | the lack of ability to include useful internal cross-reference also frees up editors from the nuisance of trying to fill their documents with them |
| 11:13 | Ms2ger | remembers when Hixie was told to stop publishing so often, because the publishmonkey couldn't keep up |
| 11:44 | <annevk> | Yeah, the W3C is averse to change, but the IETF is worse |
| 12:22 | <annevk> | philipj: hmm, now I'm thinking that perhaps navigation doesn't always discard |
| 12:28 | <philipj> | annevk: https://html.spec.whatwg.org/#navigate calls "unload a document" which calls "discard the document", but I didn't check for early returns or conditions or anything |
| 12:29 | <annevk> | philipj: only when it cannot be salvaged |
| 12:29 | <annevk> | philipj: so my patch probably breaks Mozilla's bfcache |
| 12:29 | <annevk> | good times |
| 12:30 | <jgraham> | Hmm? |
| 12:30 | <philipj> | oh, the spec actually doesn't just pretend that every navigation loads the URL from scratch? |
| 12:30 | <jgraham> | No |
| 12:31 | <jgraham> | Because that's observably different |
| 12:31 | jgraham | doesn't know the context btw |
| 12:31 | <philipj> | Right, but I have pretty low expectations in the area of navigation :) |
| 12:31 | <jgraham> | Well fair enough but it *tries* to be right |
| 12:31 | <philipj> | Fascinating |
| 12:32 | <jgraham> | So it gets things right like pageshow being different for actual loads vs history navigations |
| 12:32 | <philipj> | I guess that means annevk needs to understand how this works, and then I need to pretend to have understood the change :P |
| 12:32 | <jgraham> | What is "this"? |
| 12:32 | <philipj> | jgraham: when to exit fullscreen during navigation |
| 12:32 | <jgraham> | Oh |
| 12:33 | <jgraham> | Is that supposed to be always? |
| 12:33 | <philipj> | for top-level documents, yes, but not when navigating an iframe |
| 12:34 | <philipj> | I'm actually not sure what these restrictions achieve, though. |
| 12:35 | <jgraham> | Seems like it might be right to exit fullscreen after firing pagehide if the document is in a tlbc, or something? |
| 12:35 | jgraham | hasn't thought about it too much |
| 12:44 | <annevk> | jgraham: yeah maybe, though we also need to tackle browsing contexts closing |
| 12:44 | <annevk> | jgraham: if you close a browsing context, I guess history is not preserved? |
| 12:47 | <jgraham> | Well if you close a child browsing context, the join session history doesn't change. If you close a tlbc I think it all goes through the same steps to fire pagehide+unload+etc. |
| 13:05 | <annevk> | philipj: are you sure we shouldn't fire the event btw? |
| 13:06 | <annevk> | philipj: wouldn't it be better if the site could still perform animations and such before being navigated |
| 13:07 | <izhak> | Hi, guys! What is the status of the multipart responses in http 1.*, http 2.0 and current browsers? |
| 13:07 | <izhak> | I mean, how well is it supported in browsers as well as in protocols..& |
| 13:07 | <izhak> | ? |
| 13:28 | <philipj> | annevk: I would think it's too late to do anything at that point, or how long could the animation be? |
| 13:29 | <annevk> | philipj: dunno, but there's other events firing at that point |
| 13:30 | <philipj> | annevk: an easy way to find out is to just use the incantations that will result in events being fired and see if implementors complain that it doesn't make any sense. |
| 13:30 | <philipj> | or more likely, if it doesn't make sense, the events just won't be fired anyway |
| 13:31 | <annevk> | hmm |
| 13:31 | <annevk> | We should actually know |
| 13:33 | <philipj> | Well, for documents that aren't salvageable and are being discarded, it doesn't make much sense to fire any events I think |
| 13:34 | <philipj> | but if you can navigate away from a fullscreen page and then back without a full reload, it would be very strange if the page still thinks it's fullscreen because no event has been fired |
| 14:04 | annevk | finds "If any event listeners were triggered by the earlier unload event step" and wonders how that is explained |
| 14:06 | <Ms2ger> | Not |
| 14:07 | <Ms2ger> | annevk, did we ever have dom explain the IDB "if any event listener threw an exception" pattern? |
| 14:07 | <annevk> | Ms2ger: nope |
| 14:08 | <annevk> | how many fricking hacks did people add? |
| 14:08 | <annevk> | IDB no less, I though there was no real theoretical reason to dislike that API |
| 14:09 | <annevk> | time for 😓 |
| 14:09 | <annevk> | or maybe 😠since it seems the floodgates on event listener hacks are open |
| 14:11 | <Ms2ger> | > Call for Review: W3C DOM4 Proposed Recommendation Published |
| 14:11 | <Ms2ger> | lol |
| 14:16 | <annevk> | wat |
| 14:16 | <annevk> | "This branch is 209 commits ahead, 120 commits behind whatwg:master." |
| 14:16 | <gsnedders> | So, uh, how many tests did they have to get to PR? |
| 14:17 | <annevk> | Ms2ger: another interesting data point for https://github.com/w3c/charter-html/issues/112#issuecomment-141880890 though I doubt anyone really cares |
| 14:19 | <annevk> | plh is on his solo mission to replicate all things WHATWG |
| 14:20 | <annevk> | but not doing a great job of it for the couple of things I checked |
| 14:21 | <wanderview> | can stylesheet @imports be cross-origin? |
| 14:23 | <ondras> | wanderview: that opens a potential xss vector, as you can verify whether a certain css rule was applied and thus if that rule has been defined, right? |
| 14:23 | <wanderview> | ondras: I don't know... I would be happy to hear its spec'd as same-origin only |
| 14:26 | <wanderview> | ah, here it is: "The origin of an imported style sheet is the same as the origin of the style sheet that imported it." |
| 14:26 | <wanderview> | although maybe that means its just changing the origin of the imported stylesheet? hmm |
| 14:27 | <wanderview> | oh, thats some css origin concept |
| 14:28 | <ondras> | http://jsfiddle.net/m4drt18k/ |
| 14:28 | <ondras> | loading cross origin css apparently works |
| 14:30 | <ondras> | and the followup... http://jsfiddle.net/m4drt18k/1/ |
| 14:34 | <annevk> | wanderview: yes they can |
| 14:34 | <wanderview> | yea... nice way to start the morning :-\ |
| 14:34 | <annevk> | wanderview: CSS is full of SOP fail |
| 14:35 | <wanderview> | my easy bug fix is turning into a month-long endeavor |
| 14:53 | <caitp> | isn't that just the worst? |
| 15:05 | <gsnedders> | is it deliberate the Acid tests don't have any clear license on them? |
| 16:43 | <smaug____> | hmm, stable links to html spec would be nice |
| 17:22 | <annevk> | smaug____: what link broke? |
| 17:27 | <smaug____> | annevk: https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-9:run-the-animation-frame-callbacks |
| 17:30 | <Domenic> | smaug____: so, I do have plans for this |
| 17:31 | <Domenic> | You'll be able to press "y" on your keyboard and your URL will mutate to something like https://streams.spec.whatwg.org/commit-snapshots/02e0a6431731da258d0dcad8b813c216c9f16d7c/#queuing-strategies (but for HTML of course) |
| 17:32 | <smaug____> | well, what I'd like to see is to avoid removing fragment identifiers from the spec if just possible |
| 17:33 | <smaug____> | but of course that isn't always possible |
| 17:33 | <Domenic> | hmm |
| 17:55 | <annevk> | smaug____: I'm guessing that fragment identifier was generated by dfn.js |
| 17:55 | <annevk> | or maybe Wattsi, not sure what's up |
| 18:18 | <Domenic> | yay URL! |
| 19:37 | <Domenic> | Can you not CC people by email on W3C bugzilla |
| 19:41 | <smaug____> | one needs to have a bugzilla account |
| 19:41 | <smaug____> | or perhaps you meant something else |
| 19:42 | <Domenic> | yeah |
| 19:42 | <Domenic> | that is annoying |
| 19:43 | <smaug____> | Domenic: how is that different to github or chromium's bug tracker? |
| 19:43 | <Domenic> | smaug____: neither of those have CC fields which list email addresses, inviting you to simply add another email address |
| 19:44 | <smaug____> | oh. Never seen it that way |
| 19:45 | smaug____ | is annoyed by chromium's bug tracker requiring a Google account |
| 19:45 | <Domenic> | that is pretty bullshit :-/ |
| 19:46 | <smaug____> | Domenic: well, it in practice reduces the likelihood I'd file blink bugs |
| 19:47 | <smaug____> | I do have google accounts but try to not use them |
| 19:47 | <smaug____> | (since google tends to track me so well) |
| 19:47 | <smaug____> | oh well |
| 19:48 | <Domenic> | I heard there was a header you could send </troll> |
| 19:54 | <annevk> | heycam|away: we need (undefined or type) stuff in IDL |
| 19:55 | <annevk> | heycam|away: on the input side it exists as optional type, but there's nothing for the return side |
| 19:55 | <annevk> | (if someone wants to file a bug on that, be my guest, I'll get to it eventually otherwise) |
| 20:01 | <annevk> | smaug____: feel free to file them through IRC proxy |
| 20:03 | <smaug____> | annevk: blink bugs? |