| 07:29 | <AxaliaN> | Hi all |
| 07:29 | <AxaliaN> | any autoconfirmed member active? |
| 07:31 | <AxaliaN> | annevk? |
| 07:39 | <AxaliaN> | zcorpan is a confirmed member, right? |
| 07:40 | <zcorpan> | member of what? |
| 07:40 | <AxaliaN> | thwe wiki :P |
| 07:40 | <AxaliaN> | the* |
| 07:40 | <zcorpan> | no idea :-) |
| 07:40 | <AxaliaN> | :P |
| 07:41 | <AxaliaN> | The wiki says it to be so! |
| 07:41 | <zcorpan> | then i guess so. how can i hlep? |
| 07:42 | <AxaliaN> | Anyhoo; there's a meta extension that needs to be added to the wiki |
| 07:42 | <AxaliaN> | hwo does one go about doing that? |
| 07:42 | <AxaliaN> | how* |
| 07:43 | zcorpan | looks at http://wiki.whatwg.org/wiki/WHATWG_Wiki:How_to_create_a_user_account |
| 07:44 | <AxaliaN> | Ah, I just saw you needed to come on IRC and ask :P |
| 07:44 | <zcorpan> | AxaliaN: username? email? (pm if you like) |
| 07:44 | <AxaliaN> | Problem 1, I am not an autoconfirmed member :P |
| 07:44 | <AxaliaN> | ok |
| 07:48 | <zcorpan> | ok created |
| 07:48 | <AxaliaN> | Awesome, thanks :) |
| 07:48 | <zcorpan> | np |
| 09:24 | <annevk> | zcorpan: does Chrome workers deal with data URLs? |
| 09:24 | <annevk> | s/does/do/ |
| 09:25 | <zcorpan> | seems not http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3046 |
| 09:25 | <zcorpan> | i think blob works though |
| 09:26 | <zcorpan> | at least for dedicated, dunno about shared |
| 09:38 | <annevk> | blob is fine as they have an origin |
| 09:38 | <zcorpan> | do you want to drop data url for workers? |
| 09:40 | <annevk> | yes |
| 09:41 | <annevk> | zcorpan: see WHATWG list |
| 09:41 | <annevk> | zcorpan: we want to make data URLs an opt-in |
| 09:43 | <zcorpan> | ok cool, would love to get interop on data urls :-) |
| 09:43 | <annevk> | I think we have a plan that works now |
| 09:44 | <zcorpan> | i think workers support data urls because blob didn't exist back then |
| 09:45 | <annevk> | well back then we didn't have a plan for data URLs that everyone agreed upon |
| 09:45 | <annevk> | I wish Google pushed their concerns with regards to them a bit harder at the time |
| 09:45 | <annevk> | oh well |
| 09:45 | <zcorpan> | do everyone agree on a plan now? |
| 09:46 | <annevk> | zcorpan: we're aligning with Chrome on <iframe> and hopefully workers |
| 09:47 | <annevk> | zcorpan: I guess I'm hopeful that's the case, haven't actually seen it confirmed |
| 09:47 | <zcorpan> | annevk: what about <track>? |
| 09:48 | <annevk> | zcorpan: seems like that can work as there are no side effects, right? |
| 09:49 | <zcorpan> | annevk: webvtt seems safe enough, but i'm not confident we can keep it to webvtt-only :-( |
| 09:49 | <annevk> | bah |
| 09:50 | <zcorpan> | there are some tests that use data: for <track> but that's easy to fix |
| 09:50 | <annevk> | zcorpan: yeah dunno, it's safe for XHR and <img> |
| 09:50 | <annevk> | zcorpan: I would say it should be safe for <track> |
| 09:51 | <annevk> | zcorpan: otherwise we might have some issues with that going forward |
| 09:51 | <annevk> | zcorpan: whether data URLs are allowed or not |
| 09:53 | <zcorpan> | i think chrome doesn't allow data: for <track> but i don't know if that's just a result of the default policy or if it's deliberate |
| 09:54 | <annevk> | I'm gonna add a flag to Fetch tomorrow or so and also change the text around data URLs |
| 09:57 | <tobie> | annevk: was wondering whether you were aware of https://code.google.com/p/chromium/issues/detail?id=362214 and https://sites.google.com/a/chromium.org/dev/Home/chromium-security/security-faq?pli=1#TOC-Which-origins-are-secure |
| 09:58 | <tobie> | annevk: and whether that's something you were considering to add to Url. |
| 09:58 | <tobie> | annevk: given there seems to be interest to implement something similar at Mozilla. |
| 10:01 | <annevk> | tobie: I have some vague plans on taking over the remaining bits of the Web Origin RFC and stick 'm in some existing spec |
| 10:01 | <tobie> | I see. |
| 10:01 | <annevk> | tobie: Origin header is already obsoleted by Fetch, URL could define some of the origin serialization algorithms |
| 10:05 | <tobie> | makes sense. |
| 10:08 | <annevk> | tobie: oh btw, https://w3c.github.io/webappsec/specs/mixedcontent/ will define the secure origin thing most likely |
| 10:09 | <annevk> | tobie: Mike West and I have discussed on how to add hooks to Fetch for that and such |
| 10:09 | <annevk> | tobie: so that e.g. https to http will return a network error, and other such goodies |
| 10:09 | <tobie> | I'll have a look at that. Thanks for the pointer. |
| 10:32 | <annevk> | zcorpan: where does <object> pay attention to response's status? |
| 10:32 | <annevk> | zcorpan: are you confused with Content-Type? |
| 10:33 | <annevk> | zcorpan: although <img> pays attention to that, so maybe I'm missing something |
| 10:33 | <zcorpan> | annevk: the spec's default is to pay attention to it (since http requires it) |
| 10:33 | <zcorpan> | annevk: <img> opts out |
| 10:34 | <annevk> | "HTTP requires it"? What does that even mean? |
| 10:34 | <zcorpan> | it's possible that all other features but <object> should be like <img>, i don't know |
| 10:36 | <annevk> | E.g. currently 401 requires an authentication dialog for features that opt-in (which due to legacy is all of them, except for a couple new ones) |
| 10:36 | <annevk> | But I don't think we've established a list of codes that a response has to treat as if it received a network error unless it opts in/out of that |
| 10:36 | <annevk> | s/codes/statuses/ |
| 10:37 | <zcorpan> | i dunno. i mean the spec in general treats 404 like network error rather than like 200 OK |
| 10:37 | <zcorpan> | lunch |
| 10:42 | <annevk> | zcorpan: but is that actually true in implementations? |
| 10:42 | <annevk> | zcorpan: I seriously doubt it |
| 10:48 | <caitp> | it doesn't seem to be true in chromium |
| 11:12 | <zcorpan> | caitp: what did you test? |
| 11:13 | <beverloo_> | annevk, image is public domain/cc0, go for it :-) (can't find my bugzilla details) |
| 11:16 | <caitp> | zcorpan: if you try to load a document which results in a network error, you won't actually have the document opene, instead the browser will render some data:text/html,... to tell you about the network error |
| 11:17 | <caitp> | which is not true of 404 |
| 11:18 | <zcorpan> | caitp: so you tested navigating top-level browsing context? |
| 11:18 | <caitp> | yes |
| 11:18 | <zcorpan> | ok, well that's not so interesting |
| 11:19 | <annevk> | beverloo_: cool |
| 11:19 | <zcorpan> | more interesting is what does <embed src> do, what does <link rel=stylesheet href> do, what does <video src> do, what does <script src> do, etc |
| 11:19 | <caitp> | i'm interested in an example where a 404 would be treated as a network error, with the exception of weird behaviour of webviews on certain mobile platforms |
| 11:20 | <caitp> | or file:// scheme requests |
| 11:20 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3047 |
| 11:24 | <caitp> | > If the load failed (e.g. there was an HTTP 404 error, there was a DNS error), fire a simple event named error at the element, then jump to the step below labeled fallback. |
| 11:25 | <caitp> | so that part of the spec is saying treat 404 as the same as a particular network error |
| 11:25 | <caitp> | but that's not "http" |
| 11:26 | <caitp> | it's a particular behaviour of a particular html tag |
| 11:28 | <annevk> | zcorpan: interesting |
| 11:28 | <zcorpan> | caitp: yeah |
| 11:31 | <zcorpan> | seems <embed> is like <img> per spec |
| 11:31 | <annevk> | zcorpan: it would be interesting to know what status codes that was triggered with |
| 11:32 | <caitp> | in the cases of these elements it might make sense, because you probably don't want to render some domain's particular fancy 404 response |
| 11:32 | <caitp> | but it's not the same as saying "in http, 404 is a network error" |
| 11:33 | <caitp> | that's the point I'm making, that's all :> |
| 11:33 | <zcorpan> | i said "in html" not "in http" :-P |
| 11:33 | <caitp> | i could have sworn you said in http |
| 11:33 | <zcorpan> | i said "the spec" but i was referring to the html spec, not the http spec |
| 11:34 | <caitp> | <zcorpan> annevk: the spec's default is to pay attention to it (since http requires it) ... ] <annevk> "HTTP requires it"? What does that even mean? |
| 11:34 | <caitp> | it is very early in the morning here, though |
| 11:34 | <caitp> | no coffee yet =) |
| 11:37 | <caitp> | <zcorpan> i dunno. i mean the spec in general treats 404 like network error rather than like 200 OK |
| 11:37 | <caitp> | ok I see what you're saying |
| 11:38 | <caitp> | conflated that with the earlier mention of "http requires it" |
| 11:40 | <annevk> | Hmm, I find HTML very vague on this subject. Somewhat clear for 404, but there's a ton of other response codes |
| 11:43 | <caitp> | it would probably apply to all of the non-200s (with the exception of things like 302) |
| 11:43 | <caitp> | and probably not 204 either |
| 11:44 | <annevk> | At that point 3xx are already handled |
| 11:44 | <annevk> | Maybe not 304, that depends a bit |
| 11:44 | <annevk> | But yes, I think that's the approach CORS takes. |
| 11:45 | <annevk> | http://fetch.spec.whatwg.org/#cors-preflight-fetch This does not even consider 304 |
| 11:45 | <annevk> | I guess we should consider that flattened at that point since it's an HTTP cache lookup |
| 14:08 | <darobin> | does anyone implement document.origin? |
| 14:17 | <annevk> | dunno |
| 14:17 | <annevk> | they should |
| 14:20 | <darobin> | annevk: apparently, no one at this point |
| 14:20 | <darobin> | though I'll admit I haven't checked Servo |
| 14:20 | <annevk> | file bugs |
| 14:21 | <annevk> | or create a test |
| 14:40 | <Ms2ger> | darobin, not Servo either, patch welcome ;) |
| 16:45 | <dglazkov> | good morning, Whatwg! |
| 19:51 | <zewt> | fascinating bug title: "Specify the Event Loop integration for various non-deprecated events" |
| 21:13 | <IZh> | The bug needs to be Hixied. ;-) |
| 21:15 | <caitp> | that could be interpreted in so many different ways, hmm |
| 21:15 | <IZh> | Fixed :-) |
| 21:17 | <caitp> | oscar wilde would have a field day |
| 22:46 | <zewt> | does that mean "specify the things that need to be specified and not just the ones I like" |
| 23:54 | <slightlyoff> | hey annevk, wanted to chat about fetch API |
| 23:54 | <slightlyoff> | specifically about isSynchronous in the API |
| 23:54 | <slightlyoff> | and the body property |
| 23:55 | <slightlyoff> | we'd talked about a toBlob() on the response to hand back a promise or similar so that we can get out of the contract that requires synchronous reification |