| 03:28 | <jtcranmer> | win move 5 |
| 04:39 | <mildlettuce> | whats whatwg? |
| 07:48 | <MikeSmith> | http://stackoverflow.com/questions/39343303/why-does-the-sharedworker-onconnect-event-have-a-ports-array |
| 07:58 | <annevk> | MikeSmith: posted a reply |
| 08:09 | <MikeSmith> | annevk: thanks |
| 08:45 | <annevk> | beverloo: if that notification image thing isn't merged mid next week ping me |
| 11:02 | <beverloo> | annevk, will do. I'll give it a review as well |
| 12:50 | <mounir> | smaug____: it seems that I missed your reply, I'm a bit familliar with chromecast, what do you want to know? |
| 12:58 | <smaug____> | mounir: so, Chrome is now shipping some API to it? |
| 12:58 | <smaug____> | is that Presentation API? |
| 12:58 | <mounir> | smaug____: correct |
| 12:59 | <mounir> | smaug____: we are also working on Remote Playback API |
| 12:59 | <mounir> | smaug____: Firefox OS is shipping Presentation API too |
| 12:59 | <smaug____> | mounir: so chromecast doesn't use .chrome.* APIs? |
| 12:59 | <smaug____> | (that is what I found when searching, but perhaps documentation hasn't been updated) |
| 13:00 | <mounir> | smaug____: if you use a recent version of Chrome, the Cast SDK will use the Presentation API indeed |
| 13:00 | <smaug____> | ok. |
| 13:00 | <smaug____> | mounir: is the protocol to chromecast opened? |
| 13:00 | <smaug____> | or is it still proprietary |
| 13:00 | <mounir> | still proprietary unfortunately :( |
| 13:01 | <smaug____> | mounir: any chance it will be opened? not very nice to add proprietary stuff to the web |
| 13:01 | <mounir> | smaug____: Presentation API isn't proprietary |
| 13:01 | <smaug____> | the protocol is |
| 13:02 | <mounir> | smaug____: the protocol isn't defined by the spec |
| 13:02 | <mounir> | there is some work that started on this |
| 13:02 | <mounir> | mfoltz had a presentation at the last second screen wg |
| 13:02 | <mounir> | let me find some links |
| 13:03 | <mounir> | smaug____: https://webscreens.github.io/cg-charter/ |
| 13:03 | <smaug____> | (ok, rather disappointed that blink folks allow shipping proprietary stuff.) |
| 13:03 | <smaug____> | mounir: will Chrome still update its Presentation API |
| 13:04 | <smaug____> | since that API is still somewhat in flux I'd say |
| 13:04 | <mounir> | smaug____: the Second Screen CG will work on an open protocol |
| 13:04 | <mounir> | smaug____: the Presentation API is protocol agnostic |
| 13:04 | <smaug____> | I mean, I've been reviewing patches for that in Gecko and the spec tends to have some quite some bugs |
| 13:05 | <mounir> | smaug____: if you have bugs, file them because I believe the spec went to CRC |
| 13:05 | <mounir> | CR |
| 13:05 | <smaug____> | mounir: shipping API which requires backend, and when backed in proprietary makes the whole thing rather proprietary |
| 13:05 | <smaug____> | uh, CR |
| 13:05 | <smaug____> | ok, someone needs to review it |
| 13:05 | <mounir> | smaug____: the backend doesn't have to be proprietary |
| 13:05 | <smaug____> | sure. but that is what Chrome is shipping |
| 13:08 | <mounir> | smaug____: FWIW, on some platforms, one can implement the same thing as Chrome |
| 13:09 | <mounir> | smaug____: Chrome Android implementation is based on Android APIs and is entirely public |
| 13:09 | <mounir> | s/public/open source/ |
| 13:10 | <mounir> | smaug____: on desktop, it's more complicated |
| 13:10 | <smaug____> | ahaa, so one could clone Android implementation to desktop. interesting |
| 13:10 | <smaug____> | maybe |
| 13:10 | <mounir> | smaug____: if you can clone the Android APIs :) |
| 13:11 | <mounir> | smaug____: I wouldn't be surprised that there are reverse engineered Cast SDK out there -- the SDK is in JS |
| 13:11 | <mounir> | I'm not a lawyer but it might not be legal |
| 13:11 | <smaug____> | mounir: I'm just wondering how other browsers can implement the same stuff what Chrome is now shipping to the web |
| 13:12 | <mounir> | smaug____: maybe we can discuss over email |
| 13:12 | <smaug____> | sure |
| 13:12 | <smaug____> | mounir: are you planning to come to tpac? |
| 13:13 | <mounir> | smaug____: mlamouri@ mfoltz@ and avayvod@ (all google.com) |
| 13:13 | <mounir> | smaug____: the three of us will be at TPAC |
| 13:13 | <mounir> | avayvod@ and I only the last two days |
| 13:13 | <smaug____> | I guess we can discuss there |
| 13:13 | <mounir> | the CG/WG are meeting at TPAC too |
| 13:14 | <mounir> | smaug____: it might help if you share your plans before TPAC as in we can see what we can do earlier rather than later |
| 13:15 | <smaug____> | I'll need to ask schien and others. I'm mostly worried about the overall health of the web |
| 13:17 | <mounir> | smaug____: this is something we care about too |
| 13:18 | <mounir> | smaug____: and I think we are doing progress: websites no longer have behaviour depending on a Chrome extension being installed which is a step in the right direction |
| 13:18 | <mounir> | and with 1UA mode, the Presentation API should be fully compatible |
| 13:18 | <mounir> | unfortunately, Chrome doesn't implement it yet but we are working on it |
| 13:19 | <smaug____> | well, it really needs backend protocol to be spec'ed |
| 13:19 | <mounir> | that's what the CG is doing |
| 13:20 | <smaug____> | sure. But why shipping proprietary backend. ok...we're not going to agree on this stuff :) |
| 13:22 | <mounir> | smaug____: it's not my decision |
| 17:21 | <MikeSmith> | annevk: http://stackoverflow.com/questions/39354408/safari-rejects-redirected-cors-request-due-to-browser-set-headers |
| 17:27 | <annevk> | replied |
| 17:29 | <MikeSmith> | danke |
| 17:59 | <TabAtkins> | tobie: Uh, what are you talking about re: <dfn> and `for`? |
| 18:00 | <TabAtkins> | tobie: It's stretching, but "void" fits the category of "interface", same as "long" and friends. |
| 18:03 | <tobie> | TabAtkins: I misunderstood how for was used. annevk explained it to me. |
| 18:04 | <TabAtkins> | I'm not certain they did? At least, I didn't understand anne's explanation. |
| 18:04 | <tobie> | Oh. |
| 18:04 | <TabAtkins> | It sounded like Anne had said that, to use <dfn for=foo>bar</dfn>, you need a <dfn>foo</dfn> somewhere. Which is def wrong. |
| 18:05 | <TabAtkins> | At some point I want to start actually checking `for` values for some types, but right now it's literally justan opaque disambiguator string. Any meaning you assign is purely for human-readability, Bikeshed doesn't care. |
| 18:05 | <tobie> | I didn't understand it that way, but I can see how you can read it like that. |
| 18:07 | <tobie> | Yeah. I assumed you were checking for types already and disallowing custom strings. |
| 18:07 | <tobie> | Wrongly assumed, that is. |
| 18:07 | <TabAtkins> | I definitely wouldn't be doing so for "dfn" types anyway. I'm mainly aiming for the IDL and HTML types. |
| 18:16 | <Mek> | especially for method arguments it would be nice if there was some cleverness in parsing the for= value (also something must have changed somewhere for that at some point, as https://github.com/w3c/FileAPI/commit/0ca0d71f813ba98bf8f5a6a7becbc89cc60c0fde was needed to make a spec that used to build correctly build correctly again with current bikeshed) |
| 18:17 | <Mek> | but probably the before wasn't supposed to be working correctly if for= really is just an opaque string... |
| 18:24 | <TabAtkins> | Mek: Yes, there's something funky going on with argument references that I haven't spent the time to tease out yet. Got two open bugs on it, I think. Being smarter about `for` values for IDL (that is, actually parsing them so you can be more flexible with how you type out things like a method reference) would be great, and I'll address eventually. |
| 18:37 | <tobie> | TabAtkins: from reading the docs (https://github.com/tabatkins/bikeshed/blob/master/docs/definitions-autolinks.md#specifying-what-a-definition-is-for): "Some types of definitions are defined relative to a higher construct, such as values for a particularly property, or attributes of a particular IDL interface. [...]," I imagined the for attribute was |
| 18:37 | <tobie> | reserved for the higher-construct relationships only (i.e. WebIDL, possibly some CSS stuff, etc.), but not for DFNs at all. |
| 18:38 | <TabAtkins> | Hm, could improve that. Some things *require* a `for` value, the rest just *allow* one. |
| 18:42 | <tobie> | +1 |
| 20:44 | <jyasskin> | TabAtkins: Respec documents still need explicit 'id's in their source in order to be indexed by Shepherd, right? |
| 20:45 | <TabAtkins> | Yeah. It needs an ID in whatever HTML you actually load from the network. |
| 20:46 | <TabAtkins> | If you send source+ReSpec over the wire and compile it on-the-fly on user's computers (LIKE A MONSTER), then you'd better have the IDs (and all dfn-contract attributes) in the actual source. |
| 20:55 | <jyasskin> | Thanks. |