| 00:38 | <jyasskin> | tobie: Quick mention: https://github.com/w3c/webappsec-credential-management/pull/100#discussion_r142558995 is also considering using callback functions to hold references to platform functions, as mentioned in the issue under https://heycam.github.io/webidl/#idl-callback-functions. I didn't see a github issue to mention this in. |
| 02:24 | <Domenic> | That seems OK? |
| 02:26 | <jyasskin> | Domenic: I think I agree we should allow it. WebIDL currently says "An identifier that identifies a callback function is used to refer to a type whose values are references to objects that are functions with the given signature.", but a platform function isn't a reference to an object. |
| 02:26 | <Domenic> | It isn't? |
| 02:28 | <jyasskin> | Domenic: Hm. Well, if it is, it's a Javascript object, and then calling the function involves conversions to and from JS. Isn't that slower than a direct call to an algorithm? |
| 02:28 | <Domenic> | Oh, yeah, for sure, are you not trying to call the platform function? |
| 02:28 | <Domenic> | If you're trying to just invoke the algorithm, you should do that instead of indirecting through the callback function type |
| 02:29 | <jyasskin> | (I have to run off for 30 minutes, sorry.) |
| 02:55 | <jyasskin> | Domenic: Ok, son's in bed. Right now, we're having implementations of Credential.[[Create]] return an algorithm that Credential's algorithms queue onto the main thread. It seemed like it might have been cleaner to say that was a callback function, but I think you're saying we should just say it's an algorithm. Or possibly we should choose another way to express it entirely. |
| 02:56 | <Domenic> | Yeah, it seems cleaner to have it be an algorithm, unless you actually need the JS engine involved in some way. |
| 02:56 | <Domenic> | I mean, do you anticipate implementers actually going through their Web IDL bindings? If not, then don't use a Web IDL type. |
| 03:04 | <jyasskin> | Domenic: That sounds like a good rule of thumb; thanks. |
| 05:31 | <annevk> | We should really make it so that invoking JS or IDL end points requires some kind of review |
| 10:12 | <zcorpan> | MikeSmith: would be nice to have conformance-checker/ tests for the utf-8 change also |
| 10:14 | zcorpan | will write tests for chocolate :-P |
| 10:26 | annevk | wonders what EU law states around companies refusing to remove former addresses from accounts |
| 10:33 | <zcorpan> | http://www.datainspektionen.se/lagar-och-regler/eus-dataskyddsreform/ (in Swedish; this reform doesn't apply until May 2018. Currently for Sweden there's http://www.datainspektionen.se/lagar-och-regler/personuppgiftslagen/ which the reform will replace; not sure what the deal is for other countries) |
| 11:15 | <annevk> | zcorpan: does that cover this? I tried to skim through the one published on the EU site, but it was rather dense |
| 13:26 | <annevk> | Given text/html;charset=gbk;charset=utf-8 what's the encoding going to be? |
| 13:51 | <annevk> | It is hard to believe that no normative text on MIME type parameters even discusses the possibility of duplicates |
| 13:56 | <Ms2ger> | Not all that hard... |
| 14:18 | <gsnedders> | annevk: depends on the type of company, and why they want to keep the former address? |
| 14:18 | <tobie> | foolip: sorry, you're having such a bad time with the different pieces of software I built. Thing is, they've all been built on a shoestring budget (essentially my own free time) and no one wants to invest in them, so… |
| 14:19 | <foolip> | tobie: specref has been great, really |
| 14:19 | <foolip> | tobie: it's not your fault the upstream DB isn't proactively maintained |
| 14:19 | <foolip> | tobie: and the PR reviewer assigner is also great |
| 14:20 | <tobie> | foolip: at least, now that Heroku stepped up, I no longer have to pay for hosting those. |
| 14:20 | <annevk> | gsnedders: do you have a reference? |
| 14:20 | <gsnedders> | annevk: no :) |
| 14:21 | <tobie> | foolip: yeah, PR preview was a lot easier: clear scope upfront. |
| 14:21 | <gsnedders> | annevk: but, e.g., financial companies and companies who've had large transactions with you are likely obliged due to money laundring regulation |
| 14:22 | <tobie> | foolip: specref + wpt-pr-bot were just duct taped as we moved along. |
| 14:22 | <gsnedders> | tobie: did we not spray some WD-40 in there at some point? |
| 14:23 | <tobie> | gsnedders: probably, which is why everything is now slippery |
| 15:47 | <wanderview> | JakeA: I know you are traveling today, but when you get a chance can you sanity check something for me? does it make any sense that this should expect .workerStart on a performance timeline entry for an intercepted <script> request? https://github.com/w3c/web-platform-tests/blob/master/service-workers/service-worker/resource-timing.https.html#L13 |
| 15:57 | <wanderview> | JakeA: oh, I think MDN confused me... looking at the spec this is specifically to capture the service worker start time |
| 15:57 | <wanderview> | nm |
| 16:10 | <annevk> | Domenic: I think I found some more <script> follow-up, <script language> executes too |
| 16:13 | <Domenic> | hmm and the spec doesn't support this? |
| 16:15 | <annevk> | Domenic: processing model does, but there's some inconsistency in the obsolete-but-conforming section |
| 16:19 | <annevk> | Domenic: also https://github.com/bmeck/I-D/issues/2#issuecomment-334207482 |
| 16:21 | <Domenic> | Not sure what the action is there, you mean we should change HTML to recommend something for servers? |
| 16:21 | <annevk> | Domenic: yeah |
| 16:21 | <annevk> | Domenic: there's no normative statement corresponding to the MIME type summary of everything but text/javascript being obsolete |
| 16:22 | <Domenic> | Hmm ok |
| 16:22 | <Domenic> | Makes sense, please file both so I don't lose track, as I'm still feeling kinda behind after BlinkOn and TC39 |
| 16:22 | <annevk> | Domenic: will do, looking into a PR for the former |
| 16:23 | <annevk> | I no longer think the former is a problem, since the requirement is subtly different from type |
| 17:30 | <annevk> | Domenic: I haven't seen much come out regarding either so far |
| 17:30 | <annevk> | Domenic: I did read some TC39 minutes, but not all the days yet |
| 17:31 | <Domenic> | Either what? |
| 17:34 | <annevk> | Domenic: BlinkOn or TC39 in terms of announcements or stuff to watch |
| 17:34 | <annevk> | I see now that import.meta is pretty close to done though |
| 17:37 | <Domenic> | Ah yeah |
| 17:37 | <annevk> | Float16 Typed Arrays, hmm, I wonder if the high definition color folks might want to reconsider using that |
| 18:07 | <TabAtkins> | annevk: What do you mean? |
| 18:33 | <Domenic> | I think they were currently considering using Float32Arrays in some strange format? |
| 18:33 | <Domenic> | "ImageData uses float32, which is inefficient due to memory consumption and necessary conversion operations. Float32 was chosen because it is convenient for manipulation (e.g. image processing) due to its native support in JavaScript (and current CPUs). A possible extension would be to add and option for rec-2020 content to be encoded as float16s packed into Uint16 values. " |
| 18:33 | <Domenic> | from https://wiki.whatwg.org/wiki/CanvasColorSpace |
| 18:42 | <TabAtkins> | Float32 doesn't have native support in JS? JS is all float64. |
| 18:47 | <jyasskin> | TabAtkins: It converts back and forth: https://tc39.github.io/ecma262/#sec-numbertorawbytes |
| 18:48 | <TabAtkins> | Ah, by "native support" they just mean "in Typed Array"? |
| 18:48 | <TabAtkins> | We just need to add Float16 to Typed Arrays, honestly. |
| 19:02 | <Domenic> | that is literally what the discussion was about :) |
| 20:20 | <tobie> | TabAtkins: given the below DFNs, how would you organize them in Bikeshed (when/how would you use the "for" attribute and why)? |
| 20:20 | <tobie> | https://www.irccloud.com/pastebin/tda6zUq1/ |
| 20:22 | <tobie> | TabAtkins: here's the relevant PR for context: https://github.com/heycam/webidl/pull/433 |
| 20:23 | <tobie> | TabAtkins: (Which doesn't include dictionary mixins) |
| 20:28 | <jyasskin> | tobie: In cases like that, if I'm happy writing out "partial dictionary mixin" wherever it's used, I'd just make that the <dfn> with no [for]. If not, I'd probably make "mixin" or "member" the [lt] with "*interface", "*dictionary" or "mixin" the [for]. |
| 20:28 | <jyasskin> | But that's just me. |
| 20:30 | <tobie> | jyasskin: so convenience over system. |
| 20:31 | <tobie> | (or should I say "convenience as a system"?) |
| 20:39 | <TabAtkins> | Domenic: Yeah, I (eventually) got that; annevk's comment came out of nowhere and didn't have the context for me to understand the convo. ^_^ |
| 20:41 | <TabAtkins> | tobie: "for" is a namespacing mechanism. Interfaces and dictionaries live in the same namespace; partials are the same. Presumably mixins are the in the same namespace too? (I don't think they *have* to be, but it would be convenient to have that guarantee.) |
| 20:41 | <TabAtkins> | members are all namespaced to their interface/dictionary/whatever, because you can have multiple members with the same name if they're in different interfaces. |
| 21:44 | <tobie> | TabAtkins: so the term "interface member" would reside in the same (global) namespace as "interface"? |
| 21:44 | <TabAtkins> | Oh, the *terms*? |
| 21:45 | <TabAtkins> | Sorry, I completely misunderstood the question. |
| 21:45 | <TabAtkins> | They're all independent dfns, no for. |
| 21:48 | <tobie> | TabAtkins: gotcha, thanks! |
| 21:51 | <TabAtkins> | Ugh, I wish I'd actually thought about the namespacing of IDL before I made all the IDL dfn types. |
| 21:52 | <TabAtkins> | Interfaces/dictionaries/callbacks/typedefs all live together, and attr/methods/constructors live together. They should have just been two types, not 7. |
| 21:53 | <MikeSmith> | noticing *Enabled File and Directory Entries API* in https://developer.apple.com/safari/technology-preview/release-notes/ |
| 21:56 | <MikeSmith> | https://wicg.github.io/entries-api/ |
| 21:56 | <MikeSmith> | so we now have three shipping implementations of that |
| 21:58 | <MikeSmith> | jsbell: are there WPT tests for it? |
| 21:58 | <tobie> | TabAtkins: it's always easier in hindsight. |
| 22:22 | <jsbell> | MikeSmith: Sorry, was at the dentist... |
| 22:22 | <jsbell> | MikeSmith: https://github.com/w3c/web-platform-tests/pull/6142 |
| 22:22 | <jsbell> | MikeSmith: Want to review? :) |
| 22:23 | <jsbell> | Sadly, mostly .manual |
| 22:23 | <jsbell> | Wait WAT? That'd be 4 implementations |
| 22:26 | <jsbell> | MikeSmith: Curious how you counted 3 implementations, though. |
| 22:37 | <MikeSmith> | jsbell: I was counting Blink, Gecko, and WebKit |
| 22:37 | <MikeSmith> | what are you counting? |
| 22:37 | <jsbell> | MikeSmith: Edge has it too |
| 22:39 | <MikeSmith> | oh wow great |
| 22:39 | <MikeSmith> | well that’s a pretty nice success story |
| 22:40 | <jsbell> | MikeSmith: Well, Edge added directory upload support to be compatible with Chrome, Firefox dropped an alternate proposal and just went with compatibility. |
| 22:40 | <MikeSmith> | jsbell: is there a Chrome developer advocate responsible for this API? |
| 22:41 | <MikeSmith> | ah OK |
| 22:41 | <MikeSmith> | well I’m kinda surprised we haven’t been getting the word out about this more |
| 22:41 | <MikeSmith> | I think there are a lot of web developers who don’t know about this |
| 22:42 | <jsbell> | MikeSmith: A bit of sordid history because there was a cleaner API proposal, but this de facto one codifies the webkit prefixes and crufty API. |
| 22:42 | <MikeSmith> | anyway, I’ll review the tests today, and get them merged |
| 22:42 | <jsbell> | But that's life. |
| 22:42 | <jsbell> | MikeSmith: thanks! |
| 22:42 | <MikeSmith> | ah yeah I now start to remember the history a bit more |
| 22:42 | <MikeSmith> | it’s been a while |
| 22:43 | <jsbell> | MikeSmith: I'm on point as much as anyone is for them on the Chrome side. I can point one of my MDN editor friends at it if we need to doc 'em more |
| 22:43 | <jsbell> | There are old html5rocks articles from back when we (Chrome) thought the whole FileSystem API was going to be the hot new thing. |
| 22:43 | <MikeSmith> | yeah those I remember |
| 22:44 | <jsbell> | So... we didn't evangelize more since there wasn't uptake elsewhere until recently. |
| 22:44 | <MikeSmith> | OK well we can change that |
| 22:44 | <MikeSmith> | and as far as the MDN docs, I could help with those |
| 22:46 | <MikeSmith> | jsbell: oh wait why are these all manual tests? just because of the user interaction needed around granted permission? |
| 22:46 | <jsbell> | MikeSmith: yah |
| 22:46 | <MikeSmith> | OK |
| 22:46 | <jsbell> | MikeSmith: The only way to trigger most of the API is dragging a file/directory in |
| 22:46 | <jsbell> | If there's fancy webdriver magic that can do that, great. |
| 22:46 | <MikeSmith> | yeah, makes sense |
| 22:47 | <MikeSmith> | I think we can get it automated with webdriver eventually |
| 22:47 | <MikeSmith> | gsnedders has been working on it |
| 22:47 | <MikeSmith> | working on the general problem of automating WPT tests using webdriver that are currently manual |
| 22:47 | <jsbell> | ossm |
| 22:48 | <MikeSmith> | there’s no test yet for the IDL conformance? |
| 22:48 | <MikeSmith> | you know what I mean? |
| 22:48 | <jsbell> | I'll be curious to see how Safari did on the edge cases, and whether they matched Chrome's behavior or the slightly more aspirational version in the spec... |
| 22:48 | <jsbell> | MikeSmith; there should be two, hrm... |
| 22:49 | <MikeSmith> | ah nm |
| 22:49 | <jsbell> | MikeSmith: interfaces.html and interfaces-manual.html |
| 22:49 | <MikeSmith> | yeah, github UI was spinning while loading the tests |
| 22:49 | <MikeSmith> | still spinning |
| 22:50 | <MikeSmith> | anyway I should just go ahead and check them out locally |
| 22:50 | <jsbell> | yay, thanks for your help/interest/encouragement! |
| 22:50 | <MikeSmith> | thank you for doing all the hard work! :) |
| 22:52 | <MikeSmith> | jsbell: oh btw have these tests already had any Chrome-team review? |
| 22:53 | <jsbell> | MikeSmith: good question, let me see... I did them outside our repo so maybe I didn't... |
| 22:56 | <jsbell> | MikeSmith: let's go with "no"; I can rope someone into that if it helps. We're NOT running these as part of our CI yet. (We have a suite of non-WPT tests) |
| 22:56 | <MikeSmith> | OK |
| 22:56 | <MikeSmith> | no need to rope in anybody else |
| 22:58 | <jsbell> | MikeSmith: off to a mtg now; if you comment here I'll see it eventually tho |
| 22:58 | <MikeSmith> | hai |
| 23:05 | <MikeSmith> | jsbell: (when you’re back) can you please make your branch writeable by WPT maintainers so I can rebase it against current WPT master and push? |
| 23:06 | <MikeSmith> | and also so I can fix some minor lint errors myself |