| 07:55 | <nox> | TabAtkins: When some spec says <foo> && <bar>, unless stated otherwise the serialisation by default should be <foo> <bar>, right? |
| 07:57 | <nox> | TabAtkins: Asking because https://drafts.fxtf.org/filters/#funcdef-filter-drop-shadow says <length>{2,3} <color>?, but every UA I tried serialises the colour first. |
| 09:12 | <MikeSmith> | TabAtkins: getting long delays for responses from https://drafts.csswg.org/ |
| 09:14 | <MikeSmith> | on the order of 20 seconds just to get the start of the response |
| 09:14 | <MikeSmith> | before the content even can begin loading |
| 09:21 | <MikeSmith> | wondering if maybe it has some rate limiting in place and I’m getting tarpitted |
| 14:51 | <TabAtkins> | nox: Yes to your first question. But to your second question, there's no && in there; putting a color first shouldn't even parse, per spec. |
| 14:51 | <nox> | TabAtkins: Oh right. |
| 14:51 | <TabAtkins> | MikeSmith: Hmm, dunno about that. plinss is the one to bug, tho. |
| 14:51 | <nox> | TabAtkins: What happens I think is that both UA probably just parse that stuff like box-shadow and then reject values with inset and spread. |
| 14:51 | <TabAtkins> | Probably, yeah. |
| 14:51 | <nox> | TabAtkins: But I think the spec should say '&&', because they both serialise the color first. |
| 14:52 | <nox> | TabAtkins: Should I file an issue? |
| 14:52 | <TabAtkins> | yes plz |
| 14:52 | <nox> | TabAtkins: Will do. |
| 14:52 | <nox> | TabAtkins: Another question: |
| 14:52 | <nox> | TabAtkins: with <number-percentage>, calc(10 + 10%) should be allowed, right? |
| 14:52 | <TabAtkins> | Yup. |
| 14:52 | <TabAtkins> | Oh wait. |
| 14:53 | <nox> | As opposed to <number> | <percentage>. |
| 14:53 | <TabAtkins> | No, we just disallowed that. I need to go edit some things. |
| 14:53 | <nox> | Ok. |
| 14:53 | <nox> | TabAtkins: Are all such mixing disallowed except for <length>, now? |
| 14:53 | <TabAtkins> | (Required to be disallowed to make calc unit algebra work sanely.) |
| 14:53 | <TabAtkins> | No, all units are fine. |
| 14:53 | <TabAtkins> | Just number+percent that's problematic. |
| 14:53 | <nox> | But no browsers care, right? |
| 14:54 | <TabAtkins> | Nobody implements a number+percent calc yet, no. |
| 14:54 | <nox> | I haven't seen anything allow calc(10s + 10%) or angles or whatever else but lengths. |
| 14:54 | <TabAtkins> | Uh, probably so. |
| 14:54 | <TabAtkins> | Don't remember any off the top of my head. |
| 20:33 | <jugglinmike> | Bikeshed question here: when I write `[=fetch/status=]`, Bikeshed complains: |
| 20:33 | <jugglinmike> | LINK ERROR: No 'dfn' refs found for 'status' with for='fetch'. |
| 20:33 | <jugglinmike> | <a data-link-type="dfn" data-lt="status" data-link-for="fetch">status</a> |
| 20:33 | <jugglinmike> | but when I run `bikeshed refs --spec fetch --text status` |
| 20:34 | <jugglinmike> | the results include: |
| 20:34 | <jugglinmike> | status: current |
| 20:34 | <jugglinmike> | for: [] |
| 20:34 | <jugglinmike> | level: 1 |
| 20:34 | <jugglinmike> | url: https://fetch.spec.whatwg.org/#concept-status |
| 20:34 | <jugglinmike> | type: dfn |
| 20:34 | <jugglinmike> | export: True |
| 20:34 | <jugglinmike> | text: status |
| 20:34 | <jugglinmike> | shortname: fetch |
| 20:34 | <jugglinmike> | normative: True |
| 20:34 | <jugglinmike> | spec: fetch |
| 20:34 | <jugglinmike> | TabAtkins: or maybe Domenic: do you know what I'm doing wrong there? ^ |
| 20:34 | <TabAtkins> | Yeah, that definition is "for" nothing. You're trying to specify the *spec* it's from, which can't be done in the shorthand. |
| 20:35 | <TabAtkins> | (In [=foo/bar=], it's equivalent to <a dfn for=foo>bar</a>.) |
| 20:36 | <jugglinmike> | Does that mean this patch is incorrect? https://github.com/w3c/ServiceWorker/pull/1144/files |
| 20:36 | <TabAtkins> | I don't understand the relevance of that patch. |
| 20:37 | <Domenic> | Isn't status supposed to be for a response, anyway? |
| 20:37 | <Domenic> | Not a fetch? |
| 20:38 | <jugglinmike> | Oh, sorry. That patch is using "WorkerGlobalScope", not the name of a spec |
| 20:38 | <TabAtkins> | Domenic: Yeah, I think that definition could do with a for value in the spec. A bare "status" is kinda hard to link to. |
| 20:39 | <Domenic> | I think it has one in the spec |
| 20:39 | <jugglinmike> | This is the text that was confusing me: https://github.com/w3c/ServiceWorker/blob/fa1f95c41523b7cc8de65d2ec24edb43bf9f5cc3/docs/index.bs#L2009 |
| 20:39 | <TabAtkins> | Domenic: It does not. |
| 20:39 | <Domenic> | Oh, well, it depends on if you're linking to the status *type* or the property of a response |
| 20:39 | <Domenic> | https://fetch.spec.whatwg.org/#concept-status vs. https://fetch.spec.whatwg.org/#concept-response-status |
| 20:40 | <jugglinmike> | It's the latter that I want, actually |
| 20:40 | <TabAtkins> | jugglinmike: Yeah, that's linking to the "terminate a fetch" definition, which is for=fetch. Unrelated to being in the Fetch spec. |
| 20:40 | <jugglinmike> | got it |
| 20:40 | <Domenic> | Yeah, then just [=response/status=] |
| 20:40 | <TabAtkins> | Domenic: The other status should still have a for value. Like for=http or something? |
| 20:41 | <jugglinmike> | Perfect! Thanks to you both |
| 20:41 | <Domenic> | Yeah, maybe. Unsure why disambiguating by spec is insufficient though |
| 20:41 | <TabAtkins> | It's sufficient, but it's hard to do so in Bikeshed's syntax. ^_^ |
| 20:41 | <TabAtkins> | (And then you'd still need to *also* disambiguate by for value, since there are multiple "status" dfns in the spec.) |
| 20:43 | <Domenic> | Well, not if you use the explicit for switch ^_^ |
| 20:43 | <TabAtkins> | Okay sure, but only you two weirdos use that. ^_^ |
| 20:54 | <aff23> | Hello. My script is running in context of webpage say http://xyz.com. I make an xhr request to http://media.xyz.com/a.mp4 but it fails. Why is that? |
| 20:54 | <TabAtkins> | That's a different domain. |
| 20:54 | <TabAtkins> | (And thus, CORS applies.) |
| 20:54 | <aff23> | I am trying to understand why that fails and why does <video src = http://media.xyz.com/a.mp4 > would work then? |
| 20:55 | <aff23> | TabAtkins: but the browser was able to download and play the video fine (ignoring my script). So how is browser allowed to get the video then? |
| 20:55 | <TabAtkins> | Because <video> was implemented *just* before we realized how good of an idea it was to be strict about same-origin restrictions. |
| 20:56 | <TabAtkins> | And then people were already using <video> cross-origin, and so changing it would have broken too much stuff. |
| 20:56 | <aff23> | so you're saying CORS applies to XHR but not to <video src= ../> ? |
| 20:58 | <TabAtkins> | Yup. It's a dumb inconsistency that we can't get rid of. |
| 20:59 | <aff23> | Argh I see. So then how can browser load and play a cross domain video but I can't get access to same video via XHR? |
| 21:00 | <aff23> | for e.g https://html5media.info serves the video from media.html5media.info |
| 21:00 | <TabAtkins> | Browsers have magic powers in many ways; this isn't something built into the internet, it's just how browsers expose the data to you. If you want to access it via XHR, you just need to set up proper CORS headers on the subdomain; there are plenty of tutorials that'll help you with that. |
| 21:01 | <aff23> | i can't control the subdomain..I am just injecting a script (chrome extension) to get video source and making XHR request |
| 21:04 | <TabAtkins> | Then you're out of luck. |
| 21:05 | <aff23> | so if I've understood it correctly, when browser renders page, it can access any url it wants. When I make an XHR request, it knows that origin is not the browser so it'll get the response, check headers and deny my XHR request? |
| 21:32 | <TabAtkins> | aff23: Yes. |
| 22:02 | <aff23> | TabAtkins: around? |
| 23:23 | <TabAtkins> | aff23: Yo? |
| 23:23 | <TabAtkins> | aff23: (Don't ask if you can ask: just ask, and allow people to be async in their communications.) |
| 23:23 | <aff23> | aff23: only you seemed active on channel so :p |
| 23:24 | <aff23> | TabAtkins: I was wondering..what if I send an XHR request to my own server, which performs GET request on cross-domain video and returns video data as response? |
| 23:25 | <TabAtkins> | Yeah, that's a pretty standard proxy setup. It works just fine, and is common in situations like this where you can't alter the other endpoint's headers. |
| 23:25 | <TabAtkins> | It's like money-laundering, but for security. ^_^ |
| 23:28 | <aff23> | haha okay..and can you point me to any spec/doc which explains how/why we can do <video src = "crossdomain.url"> ? |
| 23:29 | <TabAtkins> | You can do <video> because the spec *doesn't* mandate a same-origin restriction. |
| 23:30 | <TabAtkins> | (Tangent: the reason the proxy-thru-your-server approach is just fine, is because your server doesn't have any of the credentials that the user does. Cookies, in particular, tend to "go along for the ride" when you make cross-origin requests, possibly giving your page access to things that the user is signed into. Your server doesn't have any of that, so assuming basic security exists, it only has access to things that it's |
| 23:30 | <TabAtkins> | allowed to have access to.) |
| 23:35 | <aff23> | aha got it TabAtkins. Yeah valid point about tangent. I read about it as well. |
| 23:36 | <aff23> | I am just wondering, if my server is in c++, how do I allocate size for video data? I've no way of knowing the video size in advance |
| 23:36 | <TabAtkins> | No clue about any of that. ^_^ |
| 23:36 | <TabAtkins> | But dynamically-sized arrays do exist in c++ |
| 23:36 | <aff23> | okay thanks |
| 23:36 | <aff23> | yeah but since I am not doing range queries, I'd have to get all the data |