| 05:31 | <igrigorik> | annevk: thanks for the reference, followed up on the thread: https://github.com/whatwg/fetch/issues/47#issuecomment-143948846 |
| 06:13 | <annevk> | gsnedders: yeah, mkwst is investigating writing a standard for it |
| 06:13 | <annevk> | igrigorik: you haven't really addressed the issue |
| 06:52 | <mkwst> | gsnedders, annevk: Yeah. I had a spec for this, and the group got cold feet after some challenges popped up. I'd like to bring it back up, but I'm loath to do so until I know how to do the blocking in Chromium so that it's not just an empty document. |
| 06:53 | <annevk> | mkwst: why does it have to be an empty document? |
| 06:53 | <annevk> | mkwst: is this related to Chromium making error pages same-origin? |
| 06:53 | <mkwst> | annevk: Hrm? No, sorry. Maybe I didn't understand the discussion. |
| 06:54 | <mkwst> | annevk: I mean that it's tough for our network stack to distinguish a priori an intranet address from an internet address before connection time. |
| 06:54 | <mkwst> | annevk: And we don't have enough context at the time that we're making a connection to determine whether we should block the former or not. |
| 06:54 | <annevk> | mkwst: oh |
| 06:54 | <mkwst> | So I need to do some work (or find someone to do some work). |
| 06:55 | <mkwst> | I don't really want to put up a doc that says "DO X!" if I don't know how to do X in the browser I'm responsible for. :) |
| 06:55 | <mkwst> | That's what I mean by "empty document". A spec without code is fairly worthless. |
| 07:03 | <annevk> | mkwst: oh, I thought you meant the type of error handling |
| 07:04 | <mkwst> | Yeah, sorry. I wasn't clear. |
| 07:09 | <annevk> | By the way, there's an intern spot to be filled for the HTML Standard: https://wiki.mozilla.org/Outreachy/2016/December_to_March#Contribute_to_the_HTML_Standard.21 |
| 07:10 | <annevk> | And also somewhat relevant to the WHATWG, folks can work on implementing Fetch in Servo: https://wiki.mozilla.org/Outreachy/2016/December_to_March#Servo:_Complete_implementation_of_Fetch_standard |
| 08:23 | <philipj> | Ms2ger: there? |
| 08:45 | <philipj> | Ms2ger: It looks like idlharness.js doesn't try to pass null or invalid types to methods in order to check if they'll throw TypeError, is that right or am I doing it wrong? |
| 08:46 | <Ms2ger> | That sounds plausible |
| 08:47 | <Ms2ger> | In general, "invalid type" is somewhat difficult to construct |
| 08:50 | <philipj> | Ms2ger: for interface types that are not nullable, passing in null would be nice |
| 08:50 | <Ms2ger> | Agreed |
| 08:51 | <Ms2ger> | There's also overloads, unfortunately |
| 08:51 | <philipj> | and I guess there are no types that are both instanceof Document and instanceof Window, so one could always use one of those? |
| 08:51 | <philipj> | oh, right |
| 08:52 | <philipj> | yeah, whatever the implementation of giveMeAnInvalidType() is, it should be possible to write an interface that defeats it |
| 08:56 | <philipj> | Ms2ger: is there somewhere I could file an issue for the simple null case that has a non-zero chance of being fixed? |
| 08:56 | <philipj> | I'm trying to answer a question for someone else, so I'm not excited about fixing it myself today :) |
| 09:45 | <Ms2ger> | philipj, testharness.js repo, I sometimes look at it :0 |
| 09:45 | <philipj> | Ms2ger: ok :) |
| 10:21 | <SteveF_> | Domenic: pinged you on twitter (then realised I am persona non grata [wise move] in your twitterverse) so leaving here Script-Based Web Accessibility proposal https://github.com/cyns/wapa/blob/master/ScriptAccessibility.md#script-based-web-accessibility |
| 11:05 | <annevk> | mkwst: this whole modularizing CSP seems like a Process hack and I suspect will only cause you pain due to the shifting dependencies and requirements over time |
| 11:11 | <annevk> | mkwst: this is basically what's wrong with the way the W3C works, you start optimizing for producing RECs and as a result you create a disaster for everyone else trying to follow along |
| 11:37 | <mkwst> | annevk: Eh. I understand that critique, and I agree to an extent. |
| 11:38 | <mkwst> | annevk: However: 1. Beyond W3C process, I think separate documents will give folks like Microsoft the ability to say they implemented a thing without blocking on implementing everything. |
| 11:39 | <mkwst> | annevk: 2. Directives are already modular to a great extent. There's no particular reason that `upgrade-insecure-requests` needs to be in the same document as `sandbox`. They do completely divergent things, and are only in the same document because of the delivery mechanism. |
| 11:39 | <mkwst> | annevk: 3. Separate documents allow more explanation. I think the cookies feature is significantly clearer, both in justification and scope, in a separate, focused document. |
| 11:45 | <mkwst> | (In other words, CSP is a generic delivery mechanism for a bunch of stuff. Some of that stuff is similar to some other bits of that stuff, and grouping them together makes sense to me.) |
| 12:02 | <annevk> | mkwst: did Microsoft actually say as much? It has never been a problem for them before |
| 12:02 | <annevk> | mkwst: see e.g., HTML or URL |
| 12:02 | <mkwst> | annevk: No. They've said they aren't prioritizing "CSP2", and have been unresponsive to my (repeated) suggestions that there are important bits and not so important bits. |
| 12:03 | <annevk> | mkwst: right, I don't think splitting will change that |
| 12:05 | <mkwst> | annevk: I'm not suggesting that it solves the problem. I think it makes the problem smaller. |
| 12:06 | <Ms2ger> | It makes the problem bigger, because now they have a dozen specs they can ignore |
| 12:08 | <mkwst> | If the specs are smaller, implementing them is easier, which means they can tick a nice feature checkbox. That's appealing. |
| 12:09 | <mkwst> | (also, annevk: if you haven't already, tell me I'm an idiot on the mailing list. :) ) |
| 12:11 | <jgraham> | I'm unconvinced that smaller specs are easier to implement |
| 12:11 | <jgraham> | depending on how they became "smaller" |
| 12:12 | <jgraham> | Like, one way to make small specs is to specify features in isolation and conveniently ignore the interaction between that feature and other features |
| 12:12 | <jgraham> | So things look small but actually they aren't |
| 12:12 | <philipj> | annevk: when merging PRs that need a new ack, do you think we should just change the commit, or do a separate "ack for previous commit" thing? |
| 12:12 | <jgraham> | They're just underspecified |
| 12:12 | <annevk> | mkwst: I've made the point that the W3C Process has detrimental effects on everyone but lawyers enough times |
| 12:12 | <jgraham> | (*cough* web-performance *cough*) |
| 12:12 | <annevk> | philipj: I think we should change the commit and override with --author |
| 12:13 | <mkwst> | annevk: If you can invent a world in which lawyers don't matter, I'm totally happy to join you there. |
| 12:13 | <philipj> | annevk: you mean preserve the original author, or to pretend that we are the authors of the fix too? |
| 12:13 | <annevk> | philipj: preserve |
| 12:13 | <annevk> | mkwst: you're already here |
| 12:13 | <philipj> | annevk: right, that's what git commit --amend does by default |
| 12:13 | <mkwst> | ... |
| 12:14 | <annevk> | :-P |
| 12:14 | <annevk> | philipj: so whenever I use git commit --amend I can modify the commit message, but not the commit itself |
| 12:14 | <philipj> | annevk: you need to git add -p first |
| 12:15 | <philipj> | or any kind of git add, -A would do as well |
| 12:15 | <annevk> | philipj: so make a change, use git add -p, then do git commit --amend? |
| 12:15 | <philipj> | annevk: yep |
| 12:15 | <annevk> | philipj: thanks, that should make things easier |
| 12:15 | <philipj> | annevk: :) |
| 12:15 | <annevk> | philipj: I usually fiddle around a bit with the GitHub GUI which is not really ideal, but I managed to get the same effect in the end |
| 12:16 | <jgraham> | mkwst: So the flip side of the lawyer coin is that if no one had done HTML5 because W3C dropped it and WHATWG weren't lawyer-friendly then, well, that world would be a worse world than this one. So it's empirically true that it is possible to worry too much about the problems with doing work and not enough about the problems of not doing work. |
| 12:17 | <mkwst> | jgraham: Put the lawyer stuff to the side. My problem at the moment is that the work I'm doing is helping Chrome users, and Firefox users to an extent, but isn't helping anyone else (and, due to that lag, isn't helping Chrome users as much as it should). |
| 12:17 | <mkwst> | jgraham: I'm looking for solutions to that problem. |
| 12:18 | <jgraham> | Well, I don't know of a way to force Microsoft to implement something :| |
| 12:18 | <mkwst> | Or Apple. Or Mozilla. |
| 12:18 | <mkwst> | Forcing is the wrong question, I think. |
| 12:18 | <mkwst> | I want to make things appealing to implement. |
| 12:19 | <jgraham> | I think things are appealing to implement if they solve real problems that users are percived to have |
| 12:19 | <jgraham> | I suspect the way the spec is structured is a correction to that |
| 12:20 | <mkwst> | I think splitting things out makes individual improvements clearer, yes. |
| 12:21 | <mkwst> | https://w3c.github.io/webappsec/specs/csp-cookies/ is a tiny spec that (tries to) identify a specific problem, and proposes a specific solution. It delivers that solution in terms of CSP. *shrug* That seems like a clear package. |
| 12:21 | <mkwst> | (With the usual strawman, rough draft, etc. caveats. Assume I spent time to polish things.) |
| 12:22 | <annevk> | I've never know the presentation of a specification to be what convinces Apple and/or Microsoft |
| 12:22 | <annevk> | What matters is developers requesting the functionality and the popularity of the features |
| 12:23 | <annevk> | That's why Microsoft eventually caved and implemented CORS for XMLHttpRequest, and dropped XDomainRequest |
| 12:27 | <Domenic> | SteveF_: oh cool, will take a look... and should probably unblock you, I just remember blocking you after you said something about cocks in response to one of my tweets |
| 13:48 | <annevk> | Hmm, more magic in HTML |
| 13:48 | <annevk> | Discard tasks. If anything got discarded, do x. |
| 13:57 | <SteveF_> | Domenic: sorry can't remember tweeting "about cocks in response to one of my tweets", but will make an effort not to tweet such stuff to you in future. |
| 14:52 | <annevk> | Domenic: could you give https://github.com/whatwg/html/pull/203 a final pass? |
| 14:53 | <Domenic> | annevk: will do |
| 15:09 | <annevk> | Domenic: ah thank you for catching that |
| 15:09 | <annevk> | Domenic: it seems the parser does not choke on typos |
| 15:10 | <Domenic> | annevk: yeah I figured this one would need a review of the built product |
| 15:54 | <annevk> | Domenic: pushed the changes you wanted |
| 15:54 | <annevk> | Domenic: I think HTMLAllCollection should just become its own class |
| 15:54 | <Domenic> | annevk: reviewing built output now |
| 15:55 | <Domenic> | annevk: that seems probably true, although we should investigate in a follow-up bug |
| 15:55 | <annevk> | Domenic: although perhaps someone could quickly peek at the Chromium code for HTMLAllCollection whether that is true there too |
| 15:55 | <annevk> | Domenic: will file an issue |
| 23:30 | <MikeSmith> | anybody else having a problem with gmail currently not loading in Canary (on OS X at least)? |
| 23:31 | <MikeSmith> | and if so, know any workaround |
| 23:31 | <MikeSmith> | it hasn't been working for me for days now |