| 00:30 | <zewt> | dear microsoft: stop deliberately ignoring the vocabulary of the entirely software industry and using your own |
| 00:31 | <zewt> | re: calling localization "globalization" |
| 00:32 | <a-ja> | g12n |
| 00:33 | <zewt> | :| |
| 00:34 | <a-ja> | erm...g11n |
| 05:46 | <annevk> | hey slightlyoff |
| 05:47 | <annevk> | slightlyoff, isSynchronous was mostly about exposing what the main thread was doing |
| 05:47 | <annevk> | slightlyoff: e.g. if you want to log synchronous XHR requests |
| 05:47 | <annevk> | slightlyoff: it's not mutable |
| 05:48 | <annevk> | slightlyoff: and I'm totally with you on asynchronous access to .body, .toBlob() seems a bit ugly though, I wonder if we can do better |
| 05:49 | <annevk> | slightlyoff: feel free to file tickets somewhere on me |
| 06:16 | <zcorpan> | annevk: allowsameorigindataurl is quite long. any reason allowdataurl doesn't work? |
| 06:17 | <annevk> | zcorpan: other than not being quite as clear, can't really think of anything |
| 06:19 | <zcorpan> | i'm not convinced it's clear to people what "same-origin data url" means |
| 06:48 | <karlcow> | allowsameorigindataurlandreadthespecifyoudontunderstandwhatitmeans |
| 06:49 | <annevk> | karlcow: you had to abbreviate specification? |
| 06:50 | <karlcow> | hmm good point, this leads to ambiguity. I need to fix that ;) |
| 07:31 | <annevk> | tobie: only Map.prototype.set seems to return this |
| 07:32 | <annevk> | tobie: in any event, seems like a separate issue from how to represent headers |
| 07:40 | <annevk> | Oh, Safari has IndexedDB and SPDY now |
| 08:07 | <JakeA> | annevk: slightlyoff: There's a ticket on the toBlob stuff https://github.com/slightlyoff/ServiceWorker/issues/251 |
| 08:07 | <JakeA> | I still kinda like .to(type) |
| 08:26 | <annevk> | JakeA: bodyAs(type) maybe? |
| 08:26 | <annevk> | JakeA: seems so weird to not name the member |
| 08:28 | <annevk> | JakeA: you back from the protests now? |
| 08:28 | <annevk> | JakeA: would be great to nail down this API |
| 08:28 | <annevk> | JakeA: headers and body are the main difficulties |
| 08:34 | <JakeA> | annevk: yep, back! Got to do a bit of video work at some point, but mostly free |
| 08:34 | <annevk> | JakeA: I'll have more time starting 2:30PM or so |
| 08:35 | <annevk> | JakeA: which is 1:30PM your time |
| 08:35 | <JakeA> | annevk: Works for me. I'll catch up on all the stuff |
| 08:35 | <annevk> | cool |
| 10:25 | <MikeSmith> | for those who like validation, SteveF made a bookmarklet that lets you validate the serialized DOM for any given document |
| 10:25 | <MikeSmith> | http://codepen.io/stevef/full/LasCJ/ |
| 10:27 | <MikeSmith> | it uses http://validator.w3.org/nu/ but you could change it to use http://html5.validator.nu/ just by changing the URL in the source and everything else will just work the same |
| 10:27 | <MikeSmith> | oh |
| 10:27 | <MikeSmith> | hsivonen: http://validator.nu/ and http://html5.validator.nu/ both seem to be down still |
| 12:48 | <JakeA> | annevk: brace for questions. Number 1: What does headers .getAll return? |
| 12:48 | <JakeA> | annevk: I'm guessing [['key', 'val'], ['key', 'val'], ...]? |
| 12:49 | <JakeA> | annevk: Whatever it is, having it as a constructor would be nice |
| 13:02 | <JakeA> | annevk: Agree with others re lowercase in enums |
| 13:03 | <JakeA> | annevk: "CORS-with-forced-preflight" to "cors-force-preflight" |
| 13:05 | <darobin> | in the platform's great tradition we could make it CORS-with-Forced-PreFlight |
| 13:07 | <JakeA> | annevk: which requests have mode "tainted cross-origin"? |
| 13:09 | <JakeA> | darobin: "API security: strong" |
| 13:13 | <zcorpan> | JakeA: <img>, <video>, <link rel=stylesheet>... <track> (and maybe webfonts?) use "fail cross-origin" or what it's called |
| 13:14 | <Domenic> | JakeA: I think .getAll should return ['val', 'val', 'val', ...] most likely |
| 13:15 | <Domenic> | (since it takes a key) |
| 13:15 | <JakeA> | Domenic: ah yes, I missed the arg |
| 13:20 | <JakeA> | zcorpan: gotcha. Huh, so even with CORS headers, I won't be able able to get at the structure of an other-origin stylesheet? *learning* |
| 13:21 | <zcorpan> | JakeA: no, tainting is when you have an other-origin stylesheet without CORS headers |
| 13:22 | <zcorpan> | JakeA: the style sheet is applied but you can't access the CSSOM |
| 13:22 | <JakeA> | zcorpan: But with CORS headers you can? |
| 13:23 | <zcorpan> | yeah. at least that's the intent in the spec, but the spec might be a bit broken there and i don't know what the impl status is now |
| 13:23 | <JakeA> | zcorpan: In that case, what's the difference between a "cors" fetch and a "tainted cross-origin" fetch? |
| 13:27 | <zcorpan> | JakeA: see step 6 in http://fetch.spec.whatwg.org/#concept-fetch |
| 13:28 | <JakeA> | zcorpan: So, assuming a stylesheet is "tainted cross-origin" and on a different origin, wouldn't that make it always tainted? |
| 13:28 | <zcorpan> | JakeA: it's possible that i'm out of sync with annevk's terminology |
| 13:29 | <JakeA> | More likely that my mental model is broken, there'll be an aha moment soon |
| 13:30 | <zcorpan> | JakeA: not if "url's origin is request's origin and the CORS flag is unset" |
| 13:31 | <zcorpan> | which is the same-origin case |
| 13:32 | <JakeA> | zcorpan: but cross-origin? |
| 13:32 | <annevk> | JakeA: getAll takes a header name and returns its values |
| 13:32 | <JakeA> | annevk: yeah, Domenic pointed out I'd missed the arg when I read it |
| 13:32 | <annevk> | JakeA: <img> has tainted cross-origin unless you set the crossorigin attribute |
| 13:32 | <annevk> | seems other people answered questions |
| 13:33 | <JakeA> | Currently trying to work out how the tainting happen on stylesheets |
| 13:35 | <zcorpan> | JakeA: possibly it would still be tainted unless you used the crossorigin attribute |
| 13:35 | <JakeA> | zcorpan: Aha! That's it, didn't realise crossorigin was supported on <link> too |
| 13:36 | <annevk> | JakeA: enjoy |
| 13:37 | <zcorpan> | JakeA: yep. crossorigin is a planned addition to url() in css also so you can use CORS with e.g. @import |
| 13:39 | <GPHemsley> | Hixie: Is it a known difference between Firefox and Chrome that the former will wait on a script that's not resolving before rendering the page while the latter won't? |
| 13:39 | <JakeA> | annevk: I guess there's a reason we can't have "give me a non-opaque version of this if it uses simple headers & method and returns Access-Control-Allow-Origin: *, otherwise give me an opaque response"? |
| 13:39 | <JakeA> | zcorpan: gotcha |
| 13:40 | <GPHemsley> | Hixie: script and/or stylesheet and/or images |
| 13:41 | <zcorpan> | JakeA: i think it wasn't compatible to always send an Origin request header, but maybe we can still do something like that |
| 13:43 | <annevk> | JakeA: that would be a new type of fetch |
| 13:43 | <annevk> | JakeA: which we could do, but would explain nothing about the platform whatsoever |
| 13:44 | <JakeA> | annevk: I'm sure there's a reason it wasn't the default for images and stylesheets, was it something to do with Host as zcorpan suggests? |
| 13:44 | <annevk> | JakeA: Origin, yes, we could not use it for each fetch |
| 13:45 | <JakeA> | annevk: What did it break? (sorry just curious) |
| 13:45 | <annevk> | JakeA: ask abarth |
| 13:45 | <annevk> | JakeA: and if you find out, let me know, so I can update the comment in the source of Fetch |
| 13:45 | <JakeA> | hah |
| 13:46 | <annevk> | zcorpan: is someone finally solving the issues from that public-fx thread? |
| 13:46 | <annevk> | zcorpan: though maybe not, CORS style sheets did not come up, what's the benefit of that? |
| 13:50 | <zcorpan> | annevk: http://krijnhoetmer.nl/irc-logs/css/20140521#l-1296 |
| 13:53 | <annevk> | zcorpan: CSSOM would've been shorter :p |
| 13:54 | <annevk> | zcorpan: or do you like to taunt my poor memory? |
| 13:54 | <zcorpan> | annevk: sorry :-) |
| 13:55 | <annevk> | JakeA: static method is brilliant |
| 13:58 | <JakeA> | annevk: I figured fetch(url) would resolve to an Opaque response for a response that failed a CORS check and didn't need a preflight. Understand why it doesn't do that. Not sure it's an issue yet |
| 13:58 | <JakeA> | hah, muscle-memory capitalised Opaque |
| 14:00 | <annevk> | aah |
| 14:02 | <JakeA> | annevk: So, now I understand it better, "tainted cross-origin" could be "no-cors"? |
| 14:03 | <annevk> | JakeA: you think it's clear to developers that it the response will be tainted in that case? I guess... |
| 14:03 | <JakeA> | annevk: Well, it won't be tainted if its same-origin, right? |
| 14:03 | <annevk> | JakeA: fair |
| 14:04 | <annevk> | JakeA: same-origin is a mode too ;-) |
| 14:04 | <JakeA> | annevk: I was going to suggest "same-origin-only" but adding chars feels like a step backwards |
| 14:06 | <annevk> | I like no-cors |
| 14:07 | <JakeA> | annevk: omitCredentialsMode - XHR uses withCredentials, why invert it for fetch? |
| 14:07 | <annevk> | JakeA: we could not offer same-origin... |
| 14:07 | <annevk> | JakeA: it's mostly there for a couple of APIs that want it |
| 14:07 | <zcorpan> | also see http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#attr-crossorigin-none |
| 14:08 | <zcorpan> | which apis use "same-origin"? |
| 14:08 | <JakeA> | annevk: any serviceworker-visible requests? I can only think of serviceworker requests that are same-origin |
| 14:08 | <annevk> | zcorpan: document.load() |
| 14:09 | <annevk> | zcorpan: <track> when there's no crossorigin attribute I thought |
| 14:09 | <zcorpan> | annevk: ok right yeah |
| 14:09 | <zcorpan> | annevk: i hope we can drop document.load() though |
| 14:09 | <annevk> | zcorpan: same |
| 14:10 | <annevk> | I'll rename tainted cross-origin |
| 14:10 | <annevk> | I'm glad people finally care about Fetch, only took me a year |
| 14:11 | <JakeA> | zcorpan: Requests for serviceworkers themselves, although I don't know if we'll use same-origin, I think we'll fail on *all* redirects |
| 14:11 | <JakeA> | annevk: It's brilliant |
| 14:11 | <annevk> | JakeA: so we could invert omit credentials |
| 14:12 | <zcorpan> | JakeA: why fail on all redirects? |
| 14:12 | <annevk> | credentials is a bit icky, I forgot the exact rationale |
| 14:12 | <JakeA> | zcorpan: tbh, I can't remember, maybe same origin redirect is fine |
| 14:12 | <annevk> | JakeA: euhm, please copy me on the ticket where service worker fetching is defined |
| 14:13 | <annevk> | I'd really like us not to have another API that does not follow redirects |
| 14:13 | <JakeA> | annevk: yeah, I think same origin is fine. So yeah, it would be a same-origin request |
| 14:14 | <JakeA> | annevk: I guess appcache manifest is too, as are a lot of requests that are under appcache control |
| 14:14 | <JakeA> | annevk: There isn't a ticket for SW fetch, I should update the algos now I understand fetch betterer |
| 14:20 | <annevk> | JakeA: http://fetch.spec.whatwg.org/#http-fetch step 9 has a SW placeholder now |
| 14:20 | <annevk> | jungkees: ^^ |
| 14:21 | <annevk> | JakeA: I worked out a better .default() handling with jungkees so everything is a lot less magic |
| 14:21 | <JakeA> | annevk: ohh, did that happen here or in a ticket? |
| 14:22 | <annevk> | JakeA: both and also as comments on diffs |
| 14:22 | <annevk> | JakeA: somewhat messy |
| 14:22 | <JakeA> | annevk: I'll wait for the spec :D |
| 14:23 | <annevk> | JakeA: the spec is basically that SW invokes Fetch with request and a special flag set on the request object noting it comes from the SW (since .client still points to the actual origin) |
| 14:25 | <JakeA> | annevk: sounds better |
| 14:26 | <JakeA> | annevk: So, the credentials stuff… <img> is always credentials, <img crossorigin> is never with credentials, XHR withCredentials = true is "cors"? |
| 14:28 | <annevk> | JakeA: it's unclear how the crossorigin vs crossorigin=use-credentials is actually implemented |
| 14:28 | <annevk> | JakeA: it might be that nothing in the platform has the "never" semantics |
| 14:29 | <annevk> | (except in the case where you're always cross-origin due to sandboxing, but that's no different from "cors" in that case) |
| 14:30 | <JakeA> | annevk: Is new Request({ mode: "cors", withCredentials: "always" }) an invalid combination? |
| 14:32 | <annevk> | JakeA: sorry |
| 14:32 | <annevk> | JakeA: XHR withCredentials = false is "cors" |
| 14:32 | <annevk> | JakeA: it means there's actually credentials for same-origin fetches, but not for cross-origin |
| 14:35 | <JakeA> | annevk: Ohhh, would withCredentials: "same-origin" make more sense? |
| 14:35 | <caitp> | it's a bit late to change that |
| 14:36 | <JakeA> | caitp: Is it? |
| 14:36 | <caitp> | well, maybe not |
| 14:36 | <JakeA> | caitp: We're talking about Request here, not XHR |
| 14:39 | <JakeA> | annevk: btw, bodyAs(type) works for me |
| 14:41 | <annevk> | JakeA: cleaned up service worker integration a bit more |
| 14:41 | <JakeA> | annevk: I agree with Domenic that allowing headers to be provided as a simple JS object would be nice in Request/Response constructors |
| 14:41 | <annevk> | JakeA: with headers I'm awaiting some feedback, ideally from implementers, on how we want to deal with them |
| 14:42 | <annevk> | JakeA: currently the spec follows HTTP, but browsers and the web don't always, and it's unclear to me what we want |
| 14:42 | <annevk> | JakeA: I like withCredentials: "same-origin" |
| 14:43 | <annevk> | JakeA: flipping the credentials flag in meaning again is going to annoy some people, but hopefully it's for the best |
| 14:43 | <JakeA> | annevk: spec is looking great. It seems like a crime not to throw Cache into the window as soon as possible, especially if we're going to have Request/Response/fetch |
| 14:43 | <JakeA> | annevk: Where else is it "omit"? I've only seen it on XHR |
| 14:44 | <annevk> | JakeA: HTML has limited use of Fetch at the moment |
| 14:44 | <annevk> | but converting HTML is going to be a pain already :-( |
| 14:46 | <JakeA> | annevk: For the body constructor arg, I'm still keen on https://github.com/slightlyoff/ServiceWorker/issues/192#issuecomment-40737493, which means handling body before headers in the construction steps |
| 14:47 | <JakeA> | annevk: I guess FormData should be supported too, although only really useful for request body |
| 14:49 | <JakeA> | annevk: Also, what do you think to constructed responses having a text/plain content type by default? Would that avoid the browser triggering downloads if the developer forgets to set it to something better? |
| 14:50 | <annevk> | JakeA: are we exposing a way to mutate a body? |
| 14:50 | <annevk> | JakeA: setting a Content-Type header based on the body makes sense, we should do that |
| 14:52 | <annevk> | JakeA: if we call it withCredentials in the API, you don't mind it not having the same type as XHR? |
| 14:52 | <annevk> | JakeA: maybe we should call it includeCredentials? |
| 14:54 | <JakeA> | annevk: I wondered about the type issue. useCredentials? |
| 14:57 | <JakeA> | annevk: stuck on mutating body. I guess it's as useful as mutating headers as they go through the fetch event, but then having it convert type would be weird |
| 14:58 | <JakeA> | annevk: request.body = interestingTransformStream(request.body) could be exciting |
| 14:58 | <JakeA> | annevk: I guess we don't have to decide until streams are ready |
| 15:00 | <JakeA> | annevk: Does fetch(new URL(url, base)) do the right thing (toString it)? |
| 15:00 | <JakeA> | (sorry, just going through my notes now) |
| 15:02 | <annevk> | JakeA: yes it should |
| 15:03 | <annevk> | JakeA: useCredentials = "same-origin" / "never" / "always" works I guess |
| 15:04 | <annevk> | JakeA: all I could think of was setBody or some such |
| 15:04 | <annevk> | JakeA: I guess we can wait for streams |
| 15:05 | <JakeA> | annevk: or throw on set if it's not a stream. Leave the flexibility to the constructor |
| 15:05 | <annevk> | well we don't have streams so that'd be pretty useless |
| 15:05 | <JakeA> | annevk: I'm still umming between fetch(url) vs new Request(url).send(), although the former is much shorter |
| 15:07 | <annevk> | the latter might be more web-compatible |
| 15:07 | <annevk> | I like the former as it matches the English prose :-) |
| 15:08 | <zewt> | the "people don't understand that you can set stuff synchronously before async stuff starts" problem? |
| 15:08 | <zewt> | ("web-author-compatible" heh) |
| 15:11 | <JakeA> | annevk: why does fetch() reject with TypeError rather than NetworkError? |
| 15:11 | <annevk> | JakeA: I tried to keep it ES-compatible |
| 15:11 | <annevk> | JakeA: not sure if that's a goal |
| 15:12 | <JakeA> | annevk: Feels weird, but don't know how important ES-compatibilitiy is |
| 15:13 | <annevk> | JakeA: note that NetworkError is really DOMException whose name is "NetworkError" |
| 15:13 | <JakeA> | annevk: Ahhh, I hadn't realised that |
| 15:13 | <annevk> | JakeA: and that DOMException is a somewhat frowned upon object by TC39 but they also not have given us something superior so far |
| 15:14 | <jgraham> | JS is somewhat frowned on by CSSWG, but they haven't given us anything superior so far |
| 15:15 | <JakeA> | annevk: If I get back an "opaque" response, how can I tell it's opaque? Wondering if .type could be "opaque" rather than "error" |
| 15:15 | <annevk> | JakeA: basically, the idea is that the filters take effect |
| 15:16 | <annevk> | JakeA: I guess we could expose what filter is being used |
| 15:16 | <annevk> | JakeA: http://fetch.spec.whatwg.org/#concept-filtered-response |
| 15:17 | <JakeA> | annevk: Could type be overloaded for this? "default" "cors" "opaque" "error"? |
| 15:19 | <annevk> | JakeA: yeah maybe, is there a use? |
| 15:19 | <JakeA> | annevk: Only to stop opaque responses looking like errors |
| 15:20 | <JakeA> | annevk: myResponse.type == 'error' when in fact it's a perfectly usable response |
| 15:20 | <annevk> | yeah, I guess we sorta expose that difference elsewhere already |
| 15:21 | annevk | is still working on checking whether renaming omit credentials mode can be done |
| 15:21 | <JakeA> | annevk: No rush, just braindumping before my evening turns into meeting |
| 15:21 | <JakeA> | s |
| 15:23 | <JakeA> | annevk: Thinking about myCache.add('//cdn.whatever/stuff.js') - that would fail without CORS headers. This is a case where returning opaque if CORS fails would be useful. I'll try and chase down the history of the Origin: stuff |
| 15:24 | <annevk> | JakeA: why can't you store an opaque in that case? |
| 15:24 | <annevk> | JakeA: that's what <script> does too |
| 15:24 | <JakeA> | annevk: Right, but cache.add uses fetch(), and the default is cors |
| 15:25 | <JakeA> | annevk: I'd have to myCache.add(new Request('//cdn.whatever/stuff.js', {mode: 'no-cors'})) |
| 15:25 | <annevk> | JakeA: how about .credentials = "omit" / "same-origin" / "include" |
| 15:26 | <annevk> | JakeA: hmm yeah dunno what to do there |
| 15:26 | <JakeA> | annevk: might have a better idea when I dig out the Origin: stuff |
| 15:26 | <JakeA> | annevk: .credentials etc sgtm |
| 16:32 | <annevk> | JakeA: I think the only thing that's still lacking is the response.type thingie |
| 16:32 | <annevk> | JakeA: I added some sketches around bodyAs() |
| 16:39 | <Hixie> | GPHemsley: test case? |
| 16:39 | <JakeA> | annevk: What do you think about "cors-force-preflight" vs "cors-with-forced-preflight" |
| 16:40 | <annevk> | JakeA: I'd like to get rid of that entirely somehow |
| 16:40 | <JakeA> | annevk: What uses it? |
| 16:40 | <annevk> | JakeA: the mode makes sense for XHR to request, but makes no sense for authors to request |
| 16:40 | <GPHemsley> | Hixie: Try this: http://128.175.170.176/site/ |
| 16:40 | <annevk> | JakeA: it's a way from XHR to say that there's upload event listeners attached and that therefore a preflight needs to be made |
| 16:41 | <Hixie> | hsivonen: validator.nu is down |
| 16:41 | <Hixie> | GPHemsley: hangs for me in chrome... |
| 16:42 | <IZh> | Hi Hixie. Did you get my messages? |
| 16:42 | <Hixie> | IZh: which? |
| 16:43 | <IZh> | Hixie: About imagemap's area. |
| 16:43 | <JakeA> | annevk: hm didn't realise that needed extra permissions. Will we hit that issue with fetch()? If you provide your own stream you'll see it being consumed. |
| 16:45 | <IZh> | Hixie: It was on 31st of May. |
| 16:45 | <Hixie> | IZh: on irc, e-mail, bug? |
| 16:46 | <IZh> | Hixie: IRC. |
| 16:46 | <Hixie> | IZh: don't think so |
| 16:46 | <Hixie> | IZh: best place to report minor bugs is using the form on the spec |
| 16:46 | <IZh> | Hixie: Okay. |
| 16:49 | <IZh> | Hixie: Should I repeat it in the form? |
| 16:49 | <Hixie> | yes please |
| 16:50 | <annevk> | JakeA: yeah we might have to require it for streams |
| 16:50 | <JakeA> | annevk: Is upload progress that much of a security leak? I can't figure out the issue |
| 16:51 | <annevk> | JakeA: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20322 has some background on this |
| 16:52 | <annevk> | JakeA: I gotta go, continue this tomorrow maybe? |
| 16:52 | <GPHemsley> | Hixie: Oh, really? *shrug* |
| 16:53 | <IZh> | Hixie: Done. #25964. |
| 16:53 | <JakeA> | annevk: certainly! Have a good evening |
| 16:53 | <annevk> | JakeA: you too, this was great |
| 16:54 | <JakeA> | annevk: I've learned a lot |
| 16:54 | <IZh> | Hixie: What you think about adding support for floating-point coordinates for image maps shapes? These coords would be in the interval of 0.0 to 1.0, and this will work for any resolution of image and any zoom level. |
| 17:00 | <Hixie> | IZh: image maps are a dead-end technology |
| 17:04 | <caitp> | but they gave us marvels of the world wide web, like the spacejam website |
| 17:05 | <caitp> | at least, I could have sworn it used to be an imagemap... looks like a table now. either way :> |
| 17:11 | <IZh> | Hixie: What's the purpose of allowing circles with zero radius that will be considered empty and eleminated at the later steps of parsing? |
| 17:13 | <Hixie> | IZh: no idea |
| 17:15 | <IZh> | Hixie: By the way, zero-sized rectangles are not allowed. But for circle's radius the spec says "must be non-negative". |
| 17:15 | <Hixie> | IZh: i have long forgotten anything i ever knew about image maps |
| 17:15 | <Hixie> | IZh: like i said, it's a dead-end technology |
| 18:40 | <hsivonen> | hmm. validator.nu doesn't come back when relaunching... |
| 19:20 | <hsivonen> | MikeSmith, Hixie: ack validator.nu brokenness. this is weird and will need more investigation tomorrow. :-( |
| 23:26 | <Hixie> | there's no use case for aggressively downloading something but then not using it until the last possible moment, right? |
| 23:26 | <Hixie> | like a script that would only be run immediately before any scripts depending on it are run |
| 23:26 | <Hixie> | but that is nonetheless downloaded asap |