| 00:53 | <__n0a> | hi, Id like to know why https://developer.mozilla.org/en-US/docs/Web/API/Body#Methods doesn't have a document method |
| 00:54 | <__n0a> | is there a reson to not match https://xhr.spec.whatwg.org/#xmlhttprequestresponsetype ? |
| 00:54 | <__n0a> | reason* |
| 00:54 | <__n0a> | (fetch API) |
| 00:57 | <__n0a> | annevk: any idea? |
| 00:59 | <__n0a> | shouldn't https://github.com/slightlyoff/ServiceWorker/issues/462 be on the fetch repo? |
| 01:03 | <__n0a> | jgraham: ? |
| 06:51 | <annevk> | MikeSmith: I would be happy accepting a clarification to the text that explains CORS preflights |
| 06:52 | <annevk> | MikeSmith: I'd imagine it would say something about only headers set directly through XMLHttpRequest and fetch() being qualified for being checked against the whitelist due to the unsafe-request flag which is only set for those APIs |
| 06:52 | <annevk> | MikeSmith: and I guess you could point out that therefore EventSource's Last-Event-ID does not cause a preflight |
| 07:05 | <MikeSmith> | annevk: OK, I'll make some time to write up a PR |
| 07:05 | <annevk> | MikeSmith: in general pretty happy accepting CORS clarifications |
| 07:05 | <annevk> | MikeSmith: it's pretty hard it turns out |
| 07:06 | <MikeSmith> | I think webdevs have a hard time with some of it, yeah |
| 07:06 | <MikeSmith> | part of it is that the server-side systems they use don't make it all as easy as they could |
| 07:07 | <MikeSmith> | and part of it is that the docs at MDN and elsewhere could be made more clear as well |
| 07:08 | <MikeSmith> | I personally don't think the spec itself is the best place to pile in a lot of informative details just for webdevs |
| 07:08 | <MikeSmith> | though that said I think it should have just a few more |
| 07:17 | <annevk> | MikeSmith: well, someone has to read all the information in the spec to create all those other materials |
| 07:19 | <MikeSmith> | sure, so it needs to be clear enough for those people and/or they can ask in places like this for clarification |
| 07:20 | <MikeSmith> | but anyway that's a small(er) set of people (the people who contribute MDN and what not) and not just average webdevs |
| 07:21 | <annevk> | The worst is of course if they end doing up what we had to do in '04, reverse engineer browsers |
| 07:21 | <annevk> | Although that might get us a few more editors :-P |
| 07:45 | <MikeSmith> | hah |
| 07:45 | <MikeSmith> | secret strategy for creating more editors |
| 08:44 | <mkwst> | terinjokes: SRI only applies to those elements because the current spec is basically a test to check that we can actually verify integrity on the wild and crazy internet. |
| 08:44 | <mkwst> | terinjokes: Basically, they decided to do the simplest thing possible, make sure it works, and then expand it based on that experience. |
| 08:45 | <mkwst> | terinjokes: Tacking `integrity` attributes onto other elements as necessary is an obvious next step. |
| 08:45 | <annevk> | Well, it also applies to fetch() |
| 08:46 | <mkwst> | annevk: Right. I'm surprised they went for that, given the justification for stripping everything else out. *shrug* |
| 08:47 | <annevk> | mkwst: I think the main problem with the prior version was browsing contexts, everything else was probably fine |
| 08:47 | <mkwst> | ? |
| 08:52 | <annevk> | mkwst: I might misremember |
| 08:53 | <mkwst> | I kinda stopped following the details. I figure the four folks editing the doc have things in hand. |
| 09:05 | <mkwst> | https://twitter.com/ryosukeniwa/status/648201610800185344 is a bit frustrating. |
| 09:06 | <annevk> | Well, to be fair to Apple, the way SW was developed wasn't exactly business as usual |
| 09:07 | <mkwst> | The conversation around it is a bit flamey, but if WebKit folks really see CR as the point to _start_ reviewing, then they're pretty substantially out of step with the way Chrome folks see CR (which boils down to "We're done here, time to move on."). |
| 09:07 | <annevk> | Both seem wrong :-) |
| 09:07 | <mkwst> | Not trying to defend SW specifically, but I would agree with Alex's suggestion that it's been "ready for review" for more than a few days. |
| 09:08 | <MikeSmith> | rniwa is not at his best on twitter |
| 09:08 | <MikeSmith> | it's not his medium |
| 09:08 | <mkwst> | MikeSmith: But really, who is? |
| 09:08 | <MikeSmith> | true that |
| 09:08 | <annevk> | mkwst: they've given feedback before, fwiw |
| 09:08 | <jgraham> | I think it's fair to say that humanity is not at their best on twitter |
| 09:08 | <annevk> | mkwst: I remember that being mostly dismissed at the time |
| 09:08 | <mkwst> | annevk: Hope so! All I know is what I see on Twitter, so, yeah. I assume more is going on. :) |
| 09:09 | <annevk> | mkwst: but SW isn't really ready for CR |
| 09:09 | <jgraham> | Well don't tell Apple! ;) |
| 09:09 | <mkwst> | annevk: I assume you've told the Chrome folks that? |
| 09:10 | <annevk> | mkwst: and I can see why you might want to wait until CR or some such if you're overcommitted, at least at that point you know it's at least somewhat reviewed |
| 09:10 | <annevk> | mkwst: sure did |
| 09:10 | <mkwst> | annevk: good. |
| 09:10 | <Domenic> | later in the thread it's admitted that that's just an excuse for resource constraints/prioritization |
| 09:10 | <Domenic> | there are definitely specs where apple participates before CR |
| 09:10 | <MikeSmith> | with ryosuke in particular I think it's a mistake to give him too much of a hard time for stuff he (mis)states on twitter |
| 09:10 | <annevk> | mkwst: so much specifications get pushed through rather fast without anyone paying much attention |
| 09:11 | <Domenic> | e.g. all web components |
| 09:11 | <mkwst> | annevk: There's a tough balance between getting everyone on board, and ever shipping anything. |
| 09:11 | <mkwst> | annevk: and, of course, distinct priorities that drive decisions. |
| 09:12 | <mkwst> | annevk: I think it's safe to say that Apple and Google have different things they/we want to build. And that causes some tensions. |
| 09:12 | <mkwst> | Firefox too, to be fair. |
| 09:12 | <mkwst> | Also Opera. And Microsoft. And every web developer. :) |
| 09:13 | <howdoi> | How does one get the arguments of a proxy method call? |
| 09:13 | <mkwst> | jgraham: Would you mind commenting on https://github.com/w3c/web-platform-tests/pull/2205? It's not clear to me how best to deal with prefixed junk in WPT. |
| 09:13 | <howdoi> | as in if p is my proxy, on p.meow(1,2,3) in the handler (target, name) => (p,meow); but I am interested in (1,2,3) the arguments. |
| 09:14 | howdoi | sorry if ^ caused some noise in a serious discussion |
| 09:14 | <Ms2ger> | Solution: get rid of CRs |
| 09:15 | <howdoi> | Got it! |
| 09:15 | <howdoi> | apply, hmm thanks. |
| 09:16 | <mkwst> | Ms2ger: Nope. CR => PR => REC => patent protection. |
| 09:17 | <Ms2ger> | Lol |
| 09:18 | <Domenic> | lol indeed. |
| 09:18 | <mkwst> | *shrug* That's the value. I know you disagree with it, but that doesn't mean it's at all worthless. :) |
| 09:19 | <annevk> | Not sure that's really been established |
| 09:20 | <Ms2ger> | I don't disagree that patent protection is theoretically useful |
| 09:20 | <Domenic> | Just make sure nobody implements until it's in REC, since otherwise people might try to assert patents... |
| 09:20 | <mkwst> | Domenic: You know that's a strawman, right? |
| 09:21 | <Domenic> | mkwst: yes, thus "PSA: Web Components vs Extract Widget patent" |
| 09:22 | <howdoi> | Duh! that doesn't help |
| 09:22 | <Domenic> | If only we'd held off implementing web components until they were a REC! |
| 09:23 | <mkwst> | Domenic: I didn't say a path to REC prevented patent claims. I said it provided protection. Laywers like having clear processes that provide a framework for constructing a defense. |
| 09:24 | <Domenic> | mkwst: and my point is it's not actually helpful in practice---we have no evidence of it being so proven, and in fact evidence of the opposite, where because people implement pre-REC, patent claims happened and there was no protection present. |
| 09:25 | <mkwst> | Domenic: I disagree that this is evidence of the opposite. That is, of course trolls gonna troll. If idiotic claims go to court, the equally idiotic W3C process provides a clear defense. |
| 09:26 | <mkwst> | Domenic: In a perfect world, we wouldn't need it. The world, however, is idiotic. :) |
| 09:26 | <Domenic> | mkwst: the process provides a clear defense in the hypothetical world where implementations happen after REC. |
| 09:28 | <mkwst> | Domenic: I think you're taking too narrow a view of things, but I'm not a lawyer. *shrug* |
| 09:31 | <jgraham> | I thought that people believed that if someone who was actually covered by the patent policy tried to sue at some point before Rec. judges would take a very dim view of their behaviour |
| 09:34 | <Domenic> | Maybe there is an unclear defense yeah |
| 09:37 | <howdoi> | what's the status of streams.spec? |
| 09:38 | <Domenic> | howdoi: Living Standard ;) |
| 09:38 | <Domenic> | What do you mean more precisely |
| 09:38 | <mkwst> | jgraham: I'd like to write some tests that verify behavior on `http://localhost` and `http://127.0.0.1`. Is that something that should land in WPT? If so, how? :) |
| 09:38 | <howdoi> | which browser will implement it first ;) ? |
| 09:39 | <howdoi> | Edge! ? |
| 09:39 | <Domenic> | howdoi: much is implemented in Chrome since 43. Firefox has intent to implement. WebKit nighties have it but not Safari yet. |
| 09:40 | <jgraham> | mkwst: Well, that could be a problem I think |
| 09:40 | <howdoi> | Domenic: any flags must be enabled to use it? I am on Version 45.0.2454.99 not seeing it :( |
| 09:41 | <mkwst> | jgraham: https://w3c.github.io/webappsec/specs/powerfulfeatures/#is-origin-trustworthy special-cases those kinds of origins for local development. I can test them in Blink's test runner, but I'd love to have generic tests if possible. |
| 09:41 | <jgraham> | mkwst: wpt only guarantees that web-platform.test and various subdomains exist, and doesn't make any specific assurances about ports |
| 09:41 | <Domenic> | howdoi: nope, enabled by default. No constructors yet though, and only readable streams. |
| 09:42 | <Domenic> | I wish there were a way to use the python runner without editing my hosts file :( |
| 09:42 | <howdoi> | Domenic: nice! any quick examples to try? typeof ReadableStream === 'function'; true! nice |
| 09:43 | <jgraham> | Domenic: wptrunner? You could use Firefox. Or Servo :) |
| 09:43 | <Domenic> | howdoi: there is a Chrome samples of fetch response body, do a quick search |
| 09:43 | <howdoi> | https://googlechrome.github.io/samples/fetch-api/fetch-response-stream.html this? |
| 09:43 | <jgraham> | mkwst: I think it would happen to work the way that Mozilla run the tests, I don't think it would work running from w3c-test.org |
| 09:43 | <Domenic> | Apparently on Unix you can use HOSTALIASES but that doesn't work on Windows even in Git bash... |
| 09:44 | <Domenic> | howdoi: yes |
| 09:44 | <mkwst> | jgraham: no, it couldn't work when running from the web. |
| 09:44 | <howdoi> | Killer, thanks! |
| 09:44 | <mkwst> | jgraham: I'll write some tests for Blink, and then point you to them to chat about how to get them into Firefox at least. |
| 09:45 | <jgraham> | mkwst: Yeah, at the very least if you write them in testharness.js format we have a way of running tests that can't be upstreamed for whatever reason |
| 09:45 | <howdoi> | mit stuff, heh heh cool |
| 09:47 | <jgraham> | Domenic: (if Chrome has a way of setting hosts using a pref or similar then we could use that in wptrunner) |
| 09:47 | <howdoi> | Domenic: the search can get better there, it's like O(n^2) now, right? |
| 09:49 | <howdoi> | So, res.body.getReader() gives use a reader |
| 09:50 | <howdoi> | reader.cancel() will result in reader.done hmm |
| 09:50 | <Domenic> | jgraham: this is for jsdom, so might be a tougher sell... I tried using the don't validate hosts thing but it still hung somewhere in the Python. I should try again maybe and debug harder. |
| 09:52 | <Domenic> | I should probably just fall back to the hosted tests though for contributors who don't want to muck with all the prereqs. |
| 09:53 | <mosulica> | Hi everyone, please follow us on twitter , https://twitter.com/nubomedia - PaaS for WebRTC - European FP7 project |
| 10:16 | <espadrine> | that sounded spammy |
| 10:43 | <annevk> | mkwst: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24091 |
| 10:50 | <mkwst> | annevk: Without thinking about it too hard, locking it down to navigation (which would include iframes) seems like the right way to go. |
| 12:38 | <JonathanNeal> | TIL Chrome doesn’t respect changes to the rem size. |
| 12:45 | <JonathanNeal> | ^ http://codepen.io/jonneal/pen/ZbBjPY |
| 13:08 | <zcorpan> | JonathanNeal: maybe you're hitting a minimum font-size issue? |
| 13:10 | <JonathanNeal> | zcorpan: yeah, although you can change the font-size to 0 or 1px and it honors that. |
| 13:10 | <JonathanNeal> | But I do wonder if Chrome / Safari has a minimum rem size. |
| 13:10 | <zcorpan> | hmm yeah it works fine for font-size |
| 13:11 | <JonathanNeal> | Like a holdover from the old says when you couldn’t define a font-size smaller than 9px. |
| 13:11 | <JonathanNeal> | Because the 30rem padding becomes 270px, and 270/30 is 9. |
| 13:12 | <JonathanNeal> | s/old says/old days |
| 13:13 | <zcorpan> | you still can't, except for 0 |
| 13:13 | <zcorpan> | at least for me |
| 13:15 | <JonathanNeal> | zcorpan: did you try 1px? |
| 13:15 | <zcorpan> | yes. renders the same as 9px (on mac) |
| 13:15 | <JonathanNeal> | 1rem rendered the same as 9px for me, but 1px rendered as 1px for me. |
| 13:17 | <mkwst> | JonathanNeal: https://crbug.com/new :) |
| 13:17 | <mkwst> | give me a bug ID, I can route it to the right folks. |
| 13:17 | <zcorpan> | ah yes, i see that in chrome canary also. opera beta 32 renders 1px as 9px though |
| 13:17 | <JonathanNeal> | Yay, everyone does it slightly different. That’s the way we like it. |
| 13:29 | <JonathanNeal> | mkwst: thanks https://code.google.com/p/chromium/issues/detail?id=536784&thanks=536784&ts=1443446992 |
| 13:31 | <mkwst> | JonathanNeal: Thanks! |
| 13:47 | <wanderview> | mkwst: annevk: regarding that twitter thread about SW CR and apple review... I'd say its a better time to jump in due to the html spec integration more than anything... they can get a full picture now |
| 14:57 | <JoWie> | someone mentioned quirksmode.org being down with a registrar error |
| 14:58 | <JoWie> | this might be because xs4all is having issues since yesterday |
| 15:03 | <JoWie> | ah it was mikesmith that mentioned that |
| 15:04 | <JoWie> | http://tweakers.net/nieuws/105492/veel-xs4all-sites-zijn-onbereikbaar-door-probleem-domeinnaamregistratie.html (dutch) |
| 15:07 | <qq[IrcCity]> | JoWie: was it a transient registrar problem, in short? |
| 15:09 | <annevk> | wanderview: https://twitter.com/cconcolato/status/648512201452584960? |
| 15:10 | <wanderview> | thanks |
| 15:17 | <terinjokes> | MikeSmith: ah, sounds good |
| 15:30 | <JoWie> | xs4all messed up in their book keeping or something |
| 15:30 | <JoWie> | and networksolutions killed all their domains |
| 15:31 | <JoWie> | but there is a 15 day grace period that xs4all has to resolve the issue |
| 15:51 | <igrigorik> | annevk: https://fetch.spec.whatwg.org/#concept-bodyinit-extract .. any reason why we don't have a clause for object -> JSON in that switch? |
| 16:20 | <Ms2ger> | TabAtkins, r? https://github.com/w3c/csswg-test/pull/891 |
| 17:01 | <annevk> | igrigorik: how would that work? |
| 17:03 | <annevk> | igrigorik: see also https://github.com/whatwg/fetch/issues/47 |
| 18:23 | <MikeSmith> | terinjokes: ? > MikeSmith: ah, sounds good |
| 18:23 | <MikeSmith> | terinjokes: maybe you were responding to what mkwst wrote earlier about the integrity attribute? |
| 18:23 | <terinjokes> | MikeSmith: why SRI only applies to two things |
| 18:23 | <MikeSmith> | annevk: http://stackoverflow.com/questions/32581503/microsoft-edge-blocked-cross-domain-requests-sent-to-ips-in-same-private-network |
| 18:23 | <terinjokes> | MikeSmith: probs, i was still half asleep when i replied |
| 18:24 | <MikeSmith> | annevk: "Internet pages are not able to frame Intranet pages, load images or resources from them, *send them CORS XHR requests*, etc." |
| 18:24 | <MikeSmith> | sorta seems to defeat the purpose of CORS |
| 18:25 | <MikeSmith> | 「A public space address (internet) page was attempting to load a page with a private space address (intranet) in an iframe and Edge would refuse to load the intranet page with the same "Hmm, we can't reach this page" message, and with "SEC7117 Error" in the debug console. Turns out Edge doesn't like mixing internet/intranet zones (see this blog post for reasons why). Edge runs tabs in separate AppConta |
| 18:25 | <MikeSmith> | iners, and AppContainer network restrictions are sensitive to your network configuration." |
| 18:26 | <MikeSmith> | http://stackoverflow.com/a/32828629/441757 |
| 18:34 | <annevk> | MikeSmith: it doesn't much |
| 18:34 | <annevk> | MikeSmith: you can't reliably tell what is intranet and what is not |
| 18:38 | <MikeSmith> | annevk: it seems like IE/Edge at least are attempting to do just that |
| 18:38 | <MikeSmith> | and when this fails in IE/Edge, it's not obvious to webdevs why it's failing |
| 18:38 | <annevk> | MikeSmith: they have some limits that other browsers should copy, but it's not robust |
| 18:38 | <MikeSmith> | OK |
| 18:41 | <annevk> | MikeSmith: e.g., IP-based authentication is not covered |
| 18:41 | <annevk> | MikeSmith: or intranets that use "public" IP addresses |
| 18:42 | <annevk> | MikeSmith: also I believe you cannot really them apart anymore with IPv6, but I don't know enough about that to be sure |
| 18:44 | <MikeSmith> | ah yeah |
| 19:48 | <gsnedders> | annevk: reminds me of Presto blocking stuff from public IPs to private-use IPs (and from private-use to localhost) |
| 19:49 | <gsnedders> | I mean such things do block a lot of attacks on intranets, even though they aren't perfect. |