| 00:00 | <JonathanNeal> | jgraham: so I take it no? |
| 00:01 | <JonathanNeal> | I’m looking for a method that would return a promise that resolves as soon as one of the promises in the iterable resolves, or that rejects once all of the promises in the iterable rejects, with the value or reason from that promise. |
| 00:02 | <JonathanNeal> | Oh good, I’m not the first person to notice this http://www.effectiveui.com/blog/2014/11/11/promise-any-a-missing-use-case/ |
| 00:50 | MikeSmith | does http://dev.w3.org/csswg/ -> https://drafts.csswg.org/ on a bunch of links in https://github.com/servo/servo/wiki/Relevant-spec-links |
| 00:50 | <MikeSmith> | wanderview: https://platform.html5.org/ attempts to provide links to the right versions of specs |
| 00:51 | <MikeSmith> | wanderview: following, e.g., the "Prefer WHATWG specifications over W3C ones" rule and the "Always use the Editor's Draft" rule, etc. |
| 00:51 | <MikeSmith> | Domenic: 👆 |
| 00:52 | <MikeSmith> | in any cases where it doesn't, that's a bug and should get an issue report or PR at https://github.com/whatwg/platform.html5.org |
| 01:45 | <JonathanNeal> | Where can I learn the most about the “system” font? |
| 02:08 | <TabAtkins> | JonathanNeal: There is no such function (we only had real use-cases for .all() and .race()), but you can make one yourself by flipping the input promises, calling .all() on them, then flipping the result promise. |
| 02:08 | <TabAtkins> | Flipping a promise is just throwing the success value and returning the error value. |
| 02:09 | <TabAtkins> | p.then(x=>throw x, x=>x) |
| 02:15 | <JonathanNeal> | TabAtkins: that’s a fun hack, but wouldn’t actual errors end up throwing an ultimate resolve? |
| 02:15 | <TabAtkins> | ? |
| 02:16 | <JonathanNeal> | If something in a promise throws, is the Promise rejected? |
| 02:16 | <TabAtkins> | Yes. |
| 02:17 | <JonathanNeal> | So, if something actually errored in the Promise, it wouldn’t know the difference between that error and my flipping of the Promise? |
| 02:18 | <TabAtkins> | I'm confused. I think your mental model is a little bit broken, and so you're asking a weird question? |
| 02:18 | <JonathanNeal> | That’s very possible. |
| 02:18 | <TabAtkins> | Why are you making a distinction between "throws an error" and "rejects (in some normal way)"? |
| 02:18 | <TabAtkins> | Rejection is the promise equivalent of error-throwing, anyway. |
| 02:19 | <JonathanNeal> | I thought you were saying I should use Promise.all, but reject when I mean to resolve and resolve when I mean to reject. |
| 02:19 | <TabAtkins> | I said flip all the input promises, then use Promise.all, then flip the result promise, and return that. |
| 02:20 | <TabAtkins> | The initial flips means the Promise.all() will either accept (if all of the input promises rejected) or reject (if a single input promise accepted). |
| 02:20 | <TabAtkins> | Then you flip it again so the promise you end up returning actually accepts or rejects in the expected manner. |
| 02:20 | <JonathanNeal> | Right, so the initial Promise works as intended, but it’s result gets flipped before being passed to Promise.all? |
| 02:21 | <JonathanNeal> | And then the result of Promise all gets flipped and that’s my Promise.any? |
| 02:21 | <TabAtkins> | Yeah. "Promise.any = function(...inputs) { return promiseFlip(Promise.all(...inputs.map(promiseFlip))); };" |
| 02:22 | <TabAtkins> | Where "function promiseFlip(p) { return p.then(function(x){throw x;}, function(x){return x;}); };" |
| 02:24 | <JonathanNeal> | My error in thinking was neglecting to consider the inner promiseFlip. |
| 02:25 | <JonathanNeal> | That’s a very clever way to do it, but one would still end up abstracting it to something like Promise.any. Would you say your method is better than these forEach’ing over the iterables? Like https://github.com/andyjansson/promise-any/blob/master/index.js |
| 02:25 | <TabAtkins> | I suddenly want to do much more functional code: Promise.any = compose(promiseFlip, Promise.all, map(promiseFlip)); |
| 02:26 | <TabAtkins> | forEach'ing is just a straightforward translation of a Promise.all() impl into .any(). |
| 02:26 | <TabAtkins> | Which is easier depends on how well you handle more functional stuff, I guess? |
| 02:26 | <TabAtkins> | In general I vastly prefer working with promises directly if at all possible, and avoiding promise constructors entirely. |
| 02:27 | <TabAtkins> | (I think Domenic prefers that pattern as well.) |
| 02:29 | <JonathanNeal> | I follow, but I did not learn enough about functional programming to really grasp it. |
| 02:30 | <TabAtkins> | http://drboolean.gitbooks.io/mostly-adequate-guide/ |
| 02:31 | <JonathanNeal> | Is compose a real thing? Or an abstraction? Or like f => g => (...xs) => f(g.apply(this, xs)) ? |
| 02:31 | <TabAtkins> | Well, like, it's a function you can write yourself. |
| 02:32 | <TabAtkins> | function compose(...funcs) { return function(...args) { var ret = funcs[0](...args); for(var i = 1; i < funcs.length; i++) { ret = funcs[i](ret); } return ret; };}; |
| 02:33 | <TabAtkins> | (You don't mess around with `this` when writing functional style code, `this` is for OO.) |
| 02:35 | <TabAtkins> | Sorry, have to run funcs in reverse, duh. |
| 02:36 | <JonathanNeal> | And it would not be classy to var ret = funcs.splice(0)[0](...args); ? |
| 02:36 | <JonathanNeal> | So that one could for (func of funcs) ret = func(ret); |
| 02:37 | <TabAtkins> | I mean, whatevs, you're writing a for loop, do whatever you want. |
| 02:37 | <TabAtkins> | I never remember how splice() works, so I just did it manually. |
| 02:39 | <JonathanNeal> | And I can’t do like compose(ret, …funcs) {} ? |
| 02:40 | <TabAtkins> | Are you calling (in which case, why the {}) or defining (in which case, where the "function")? |
| 02:40 | <JonathanNeal> | You know, at some point you shouldn’t forgive me knowing neither functional programming or proper ES6. Thank you for being so patient. |
| 02:41 | <JonathanNeal> | I’m just learning by dissecting your compose method based on what you shared about Promise.any. |
| 02:42 | <TabAtkins> | Yeah, but when you says `compose(ret, ...funcs) {}`, were you trying to reference *calling* the compose() function, or *defining* it? |
| 02:42 | <JonathanNeal> | defining it |
| 02:42 | <TabAtkins> | Ok. |
| 02:43 | <TabAtkins> | Yeah, you can put arguments before the rest param. But that won't help here, because you have to reverse the list of funcs first (you run the last one with args, then pass its result to the next to last, etc). ^_^ |
| 02:43 | <TabAtkins> | In my dfn, pretend the first line of compose() was "funcs.reverse();", followed by the return statement as I specified it. |
| 02:43 | <JonathanNeal> | I’m doing more than pretend. I’m writing it in Sublime. Studying it. Then responding :) |
| 02:45 | <JonathanNeal> | And double checking that .reverse does in fact modify the instance rather than just returning the reordered array. |
| 02:45 | <TabAtkins> | Yes, it does both. |
| 02:45 | <JonathanNeal> | Because I forgot. |
| 02:46 | <TabAtkins> | (Which is annoying.) |
| 02:46 | <TabAtkins> | (Most of the time.) |
| 02:46 | <TabAtkins> | My Promise.any() up there won't actually work, btw, because Promise.all() expects to receive multiple args, not an array. Gotta use some helper function to make that work. |
| 02:47 | <TabAtkins> | Like function argsToArray(func) { return function(arrayOfArgs) { return func(...arrayOfArgs); };}; |
| 02:48 | <TabAtkins> | And function arrayToArgs(func) { return function(...args) { return func(args); };}; |
| 02:49 | <TabAtkins> | So then Promise.any = arrayToArgs(compose(promiseFlip, argsToArray(Promise.all), map(promiseFlip))); |
| 02:50 | <TabAtkins> | Oh, and function map(func) { return function(obj) { return obj.map(func); };}; |
| 02:50 | <JonathanNeal> | I follow, though the number of methods required to write that one beautiful line seemed a bit much. |
| 02:50 | <TabAtkins> | I highly recommend reading the DrBoolean's guide I linked above, it's a super newb-friendly intro to FP in JS. |
| 02:51 | <TabAtkins> | Well, most of those are helpers that would be prewritten, and the array<->arg converters wouldn't be necessary if the functions accepted arrays all the time. FP doesn't like variadic functions very much. |
| 02:51 | <JonathanNeal> | I have read two “page”. I don’t know if I’m a newb or not, but it’s definitely me-friendly. |
| 02:51 | <JonathanNeal> | pages |
| 02:52 | <TabAtkins> | (Back in Lisp, where you can name functions nice ASCII things, they were named <> and ><, to represent whether they "spread" the function (changing it from accepting a single array to accepting multiple args) or "squished" it (vice versa). |
| 02:53 | <TabAtkins> | So (>< Promise.any) was easier to read. ^_^ |
| 02:55 | <hgl> | sorry to chime in with a different topic, but i have some thoughts on cancelable promises, is it appropriate to discuss here? |
| 02:55 | <TabAtkins> | hgl: Yeah. Ping Domenic for it. |
| 02:56 | <hgl> | great, here are my thoughts on cancelable promises https://gist.github.com/hgl/fa6432904ddcf29ecafe |
| 02:56 | <hgl> | i'm going to cc annevk too |
| 03:04 | <JonathanNeal> | Haha reading chapter 3 and it’s telling me about the impurity of splice. Thank you again, Tab. |
| 03:12 | <TabAtkins> | hehehe |
| 03:40 | <JonathanNeal> | Chapter 5, midway, is a good place or me to stop and digest. :) |
| 05:04 | <JonathanNeal> | This might seem really stupid to people, but I put together a collection of @font-face rules that might form the “system” font https://gist.github.com/jonathantneal/32fdf75b26fd12c7c7db |
| 05:36 | <JonathanNeal> | Formalized it a little https://github.com/jonathantneal/system-font-face |
| 07:33 | <terinjokes> | JonathanNeal: in my version of similar, I also have Roboto, Liberation Sans and Arimo |
| 07:34 | <terinjokes> | I don't have San Francisco, and it seems I've also included the office font of "Calibri" for some reason |
| 07:53 | <howdoi> | I found a bug in npmjs.com, where can I find the code so that I can send a fix? `newww` repo? |
| 07:53 | <howdoi> | never mind... |
| 07:57 | <howdoi> | It's more related to doc, in https://github.com/npm/docs/tree/master/content I find everything except the md related to https://docs.npmjs.com/files/package.json |
| 08:02 | <howdoi> | https://github.com/npm/docs/issues/131 hmm |
| 08:31 | <annevk> | hgl: really want either JakeA or Domenic |
| 08:31 | <annevk> | hgl: I'm staying out of it |
| 09:06 | <smaug____> | annevk: apparently webkit/blink has some rather specialized unbind hook for certain things, https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/Document.cpp&q=nodeWillBeRemoved&sq=package:chromium&dr=CSs&l=3728 |
| 09:08 | <smaug____> | called in https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/ContainerNode.cpp&sq=package:chromium&dr=CSs&l=664&rcl=1438193817 |
| 09:11 | <smaug____> | oh well |
| 09:17 | <JakeA> | hgl: the plan is for .cancel to signal disinterest for that promise. If all child promises signal disinterest, the initiator is notified and may take action, eg cancel the request or stream |
| 09:18 | <JakeA> | Any promise may cancel itself, but only a special subclass may be signalled for disinterest (CancelablePromise). If an API returns a cancelable, and you don't want that, you can Promise.resolve it |
| 09:27 | <hgl> | JakeA, but that makes promises a two-way communication mechanism. it greatly complicates promise objects. I think promise consumers should simply be observers. observing and signaling shouldn't be multiplexed, it will make promises very hard to reason about. |
| 09:30 | <JakeA> | hgl: var p = fetch(url).then(r => r.json()), then later p.cancel() seems pretty simple to reason about. How would you do that? |
| 09:31 | <hgl> | should the r => r.json function also be notified that p has canceled? |
| 09:32 | <hgl> | or only the initiator get the canceling signal? |
| 09:37 | <hgl> | JakeA, also, if all consumers are disinterested in the result of fetching, it doesn't necessarily mean the fetching should be canceled, what if a new consumer is attached later that want to get the result? does a canceled promise mean a rejected promise? can a new consumer get the resolved value from a canceled promise? |
| 09:39 | <JakeA> | hgl: the pending promise gets the "all disinterested" signal |
| 09:39 | <hgl> | the cancel method seems to be doing two things at once: abort the action, signal disinterest. i think this is bad, these two intentions should be expressed by two different apis. |
| 09:39 | <JakeA> | A cancelled promise neither rejects or resolves, but it will "finally" |
| 09:40 | <JakeA> | hgl: the cancel method signals disinterested, but the pending promise may react to total disinterest. |
| 09:40 | <JakeA> | How would you do it? |
| 09:40 | <JakeA> | (given the example above) |
| 09:43 | <hgl> | JakeA, i gave the code examples in that gist, if you want to abort, expose the abort method with a controller or on the request or something, if you want to show disinterest, "deregister" the callback added by then() |
| 09:44 | <JakeA> | hgl: that doesn't cover the example above where I want to cancel the request and/or the response. Can you show how *that* would work? |
| 09:47 | <hgl> | i don't understand. by "cancel the request", you mean abort the request? that's done by the separate abort method. by "cancel the response", you deregister then(), so the promise is never resolved. what it doesn't cover? |
| 09:50 | <JakeA> | hgl: can you gist it? Something that will abort the request, if it's pending, or abort the stream read to JSON, if that's pending. |
| 09:52 | <hallvors> | annevk: I guess https://github.com/whatwg/fetch/issues/37 requires some followup-changes in the XHR test suite. Can you report an issue on syncing tests with your spec changes, and I'll try to get to it? :) |
| 09:54 | <annevk> | hallvors: https://github.com/w3c/web-platform-tests/issues/2042 |
| 09:54 | <hallvors> | annevk: thanks :) |
| 09:55 | <hgl> | JakeA, sure, i can try. but my point is that promise should not be used to transfer signals back up. you can always rely on a separate api to cancel the action, i think both initiating the request and read stream are actionss performed by an initiator that can be aborted. i will send you the gist soon. |
| 09:56 | <JakeA> | hgl: yeah, if we're going to speak in terms of what's easy to "reason about", I'd like to see code |
| 10:04 | <hgl> | JakeA, i think this is one way: https://gist.github.com/hgl/6778051c1386dde04ecc |
| 10:04 | <JoWie> | How are static interface members defined in IDL? such as Node.ELEMENT_NODE |
| 10:06 | <Ms2ger> | JoWie, `const` |
| 10:06 | <Ms2ger> | interface Node |
| 10:06 | <Ms2ger> | : EventTarget { |
| 10:06 | <Ms2ger> | const unsigned short ELEMENT_NODE = 1; |
| 10:07 | <JoWie> | ah thanks |
| 10:09 | <JakeA> | hgl: so request.abort would abort either the request or body stream? |
| 10:11 | <hgl> | JakeA, request.abort should only abort the request, once the request is aborted, fetch().then(callback), callback shouldn't not be called, since the promise is now rejected. |
| 10:12 | <JakeA> | hgl: so how do I cancel req.json() |
| 10:13 | <hgl> | you mean res.json()? |
| 10:13 | <annevk> | JoWie: they are deprecated |
| 10:13 | <annevk> | JoWie: so please don't invent new ones |
| 10:13 | <annevk> | JoWie: really needs to be legacyconst |
| 10:13 | <JoWie> | annevk: yes i just saw that |
| 10:14 | <annevk> | JoWie: when in doubt, use enum |
| 10:14 | <JoWie> | i assume anything "static" is a no go? |
| 10:15 | <Ms2ger> | No, static methods/attributes are fine |
| 10:15 | <annevk> | JoWie: no, there's static properties and methods |
| 10:15 | <hgl> | JakeA, i'm sorry i never used res.json(), what does it do? get json from request? what does that mean? |
| 10:15 | <hgl> | *req.json() |
| 10:15 | <JoWie> | ah, that is great |
| 10:15 | <annevk> | JoWie: e.g., https://notifications.spec.whatwg.org/#notification |
| 10:19 | <JoWie> | what is the process for suggesting a new feature (DOM) ? just open an issue on github? |
| 10:19 | <hgl> | JakeA, can we use some general example? i don't use fetch extensively, don't understand all its details. but with the ability to abort the action with a separating api and the ability to deregister the callbacks added to a promise. what usages do you think are still not covered but needed? |
| 10:20 | <hgl> | s/usage/use cases/ |
| 10:26 | <annevk> | JoWie: yeah, though be sure to read the WHATWG FAQ entry on new features too, if you haven't |
| 10:29 | <JakeA> | hgl: res.json reads the body stream, parses as json, and resolves with a JS object representing the JSON response |
| 10:29 | <hgl> | JakeA, oh, i see, req.json reads POST data. then req.abortData() to abort stream and req.abort() to abort request, I don't think the abort apis matter here. |
| 10:29 | <JakeA> | I did mean res.json |
| 10:30 | <hgl> | as long as they are separate from the promise, and only exposed by the initiator. |
| 10:30 | <JakeA> | So fetch(url).then(r => r.json()) returns a promise that resolves with the JS object |
| 10:30 | <JakeA> | hgl: so I'd have to call two methods to cancel that? |
| 10:31 | <hgl> | JakeA, i probably missed something. you want to do two different things, abort the request, and abort the reading of post data, what's wrong with two methods for two different things? |
| 10:32 | <JakeA> | hgl: no it's reading the response data, not the request data |
| 10:32 | <JakeA> | req.json() is reading request data, res.json() is reading response data |
| 10:33 | <JakeA> | So fetch(url).then(r => r.json()) is "make a request to url, then read the response body as JSON" |
| 10:33 | <hgl> | yes, so what do you want to abort? |
| 10:35 | <hgl> | request data is post data right? |
| 10:35 | <hgl> | having meal, brb. |
| 10:35 | <JakeA> | hgl: the request data is irrelevant here. I want to abort the request or reading the response, whatever's still happening. |
| 10:36 | <hgl> | JakeA, request.abort()/ response.abort() |
| 10:38 | <JoWie> | annevk: i will |
| 10:38 | <JakeA> | hgl: ah, so I'd have to call both? |
| 10:40 | <hgl> | JakeA, if you want to abort both, maybe, but i think abort the request makes fetch return a rejected promised, so you won't have access to response i think. |
| 10:41 | <hgl> | brb |
| 10:43 | <annevk> | https://twitter.com/codinghorror/status/626638134617485312 reminds me more of Theme Hospital than anything else |
| 11:08 | <hgl> | JakeA, i might be wrong about returning a rejected promise. the request can be aborted later than the fetch is returned. but what about exposing a method like request.deepAbort() that when called, aborts the corresponding response too if it's still pending. However, my point is that work should not be done to investigate how promise.cancel() should work, but to design apis to abort the initiator's action directly. |
| 11:16 | <hgl> | however, i think promise.cancel is actually a pretty good name to deregister callbacks. promise.cancel(res, rej) returns nothing, and won't call res and rej when promise is either resolved or rejected. maybe a corresponding .uncatch() too? |
| 11:20 | <hgl> | i mean promise.then(res, rej); promise.cancel(res, rej); works like promise.then(res, rej) never happened. although you can create child promises with promise.then(res, rej).then(); promise.cancel(res, rej), but they will never be resolved / rejected. |
| 11:20 | <JakeA> | hgl: gotta run, but thanks for the feedback. Will ping you when we have something further to show. Another possibility is go make promise cancelability opt-in via fetch options |
| 11:21 | <hgl> | JakeA, great, nice talking to you. :) |
| 11:44 | <JonathanNeal> | terinjokes: |
| 11:44 | <JonathanNeal> | would you share your version? |
| 12:34 | <annevk> | https://twitter.com/reybango/status/626540556630540288 o_O |
| 12:35 | <annevk> | Apple and Microsoft folks having some kind of pissing context on Twitter |
| 12:35 | <annevk> | Ah, over prefixes, joy |
| 12:38 | <jgraham> | Yeah, what could possibly go wrong, discussing a inflammatory topic on the worst communication medium yet invented |
| 13:13 | <beverloo> | oh fancy annevk |
| 13:13 | <beverloo> | yay for promises :) |
| 13:13 | <beverloo> | let me make that change in Blink |
| 13:14 | <annevk> | beverloo: it's basically identical to https://storage.spec.whatwg.org/#dom-storagemanager-requestpersistent except for deprecatedCallback (and therefore the task queueing) |
| 14:02 | <wanderview> | JakeA: it seems res.json() aborting might also interact with res.body.cancel() once streams land? not sure you can do res.body.cancel() if the stream is already locked by .json() |
| 14:02 | <wanderview> | Domenic: ^^^ |
| 14:36 | <SimonSapin> | annevk: Do you know which part of IDNA is supposed to add the xn-- prefix? Neither Punycode or UTS46#ToASCII seem to do it |
| 14:36 | annevk | looks |
| 14:38 | <annevk> | SimonSapin: o_O |
| 14:38 | <SimonSapin> | looks to me like possibly a bug in ToASCII |
| 14:39 | <annevk> | SimonSapin: use the form at the bottom of http://www.unicode.org/reporting.html and record the URL you get back |
| 14:39 | <annevk> | SimonSapin: you might want to file an issue against URL too just so we track it until it's fixed there |
| 14:39 | <TabAtkins> | JoWie: Re: how are static interface members defined in IDL, it's by doing the API right and not using statics for constants (use enums instead) |
| 14:40 | <SimonSapin> | annevk: http://www.unicode.org/reports/tr46/#Processing decodes punycode when it finds a xn-- prefix |
| 14:40 | <JoWie> | TabAtkins: |
| 14:40 | <JoWie> | TabAtkins: yea it was not intended for an enum |
| 14:40 | <JoWie> | the reason why i was asking i mean |
| 14:40 | <SimonSapin> | annevk: will do |
| 14:42 | <beverloo> | annevk, "It is much nicer and has no side effects, such as playing sounds or vibrating the device again." depends on the renotify flag |
| 14:43 | <annevk> | beverloo: hmm good point, file a bug? |
| 14:43 | <beverloo> | I'll send a PR |
| 14:43 | <annevk> | beverloo: I guess renotify is not actually defined then |
| 14:44 | <beverloo> | I think renotify is fairly clear on what it does |
| 14:44 | <beverloo> | "When set indicates that the end user should be alerted after the replace steps have run." |
| 14:44 | <beverloo> | it's just that sentence that should clarify that said behavior may be changed |
| 14:45 | <annevk> | well ideally replace steps say something about it too |
| 14:45 | <annevk> | e.g. invoke some algorithm that the display steps use too |
| 14:45 | <annevk> | and that algorithm takes care of sounds, vibration, etc. |
| 14:45 | <annevk> | and for the replace steps the algorithm is conditional |
| 14:46 | <beverloo> | hmm, yes. I guess the UA doesn't have to fetch the "sound" resource for replacements if renotify=false |
| 14:47 | <beverloo> | (assuming it knows something's about to be replaced) |
| 14:48 | <annevk> | hmm yeah |
| 14:49 | <SimonSapin> | annevk: I’m on http://www.unicode.org/cgi-bin/processErratum.pl , it doesn’t give anoher URL |
| 14:49 | <SimonSapin> | It just says "Your message has been posted to the Unicode office staff." |
| 14:50 | <annevk> | oh |
| 14:50 | <annevk> | I thought last time I got some URL where my feedback was located |
| 14:50 | <annevk> | but perhaps that's after they email you back and say your feedback has been recorded |
| 14:50 | <annevk> | it's been a while |
| 14:51 | <SimonSapin> | I used "Type of Message: Error Report (Standard, Data files, etc)" |
| 14:52 | <annevk> | seems correct |
| 14:53 | <annevk> | SimonSapin: https://github.com/whatwg/url/issues/53 |
| 14:54 | <annevk> | would have been nice if that was issue 46 |
| 14:54 | <SimonSapin> | eh :) |
| 14:55 | <beverloo> | annevk, #50. I have some time to work on a PR. |
| 14:55 | <annevk> | beverloo: ta |
| 15:09 | <philipj> | annevk: would element.setAttribute("ontouchmove", "event.preventDefault()") also throw? setting attributes never throws... |
| 15:23 | <annevk> | philipj: that's a good point, I guess we'd have to make adding the listener a no-op though |
| 15:23 | <annevk> | philipj: would make for a somewhat funky attribute... |
| 15:24 | <philipj> | this mayCancel thing is harder than it first seemed :) |
| 15:24 | <philipj> | gotta go home! |
| 15:26 | <annevk> | philipj: mayCancel -> passive |
| 15:26 | <annevk> | philipj: but yeah, it's far from trivial |
| 15:27 | <annevk> | philipj: for new event APIs btw, https://github.com/zenparsing/es-observable/blob/master/dom-event-dispatch.md seems promising |
| 15:37 | <smaug____> | annevk: any feedback to w3c Bug 28920? |
| 15:38 | smaug____ | also wonders how to get any fixes to HTML spec atm |
| 16:03 | <smaug____> | does anyone recall if wpt has any good consistent testing for structure clone use in various cases |
| 16:03 | <smaug____> | I assume no |
| 16:09 | <jgraham> | smaug____: There are a few things https://github.com/w3c/web-platform-tests/tree/e5e8fb9ebc4d5b2220abff5679fa0781c01f2c05/workers/semantics/structured-clone |
| 16:10 | <jgraham> | https://github.com/w3c/web-platform-tests/blob/e5e8fb9ebc4d5b2220abff5679fa0781c01f2c05/old-tests/submission/Microsoft/structuredclone/structuredclone_0.html |
| 16:14 | <smaug____> | both seem to be only about worker + SC |
| 16:14 | <smaug____> | but there is also window<->window messaging |
| 16:14 | <smaug____> | and push/replaceState etc |
| 16:30 | <Domenic> | wanderview: can you file that question on GitHub so I don't forget it? TC39 week this week. |
| 17:12 | <wanderview> | Domenic: https://github.com/yutakahirano/fetch-with-streams/issues/51 |
| 19:13 | <Domenic> | wanderview: thanks for taking up that whatwg/streams video issue, it seems really interesting from skimming during the meeting and i'm sad i haven't been able to really get into it |
| 19:24 | <gsnedders> | is there any implementation of the legacy colour parsing rules in Python? |
| 19:35 | <wanderview> | Domenic: I don't think I understand what that guy wants... going to wait until you can read it |
| 19:40 | <jyasskin_w> | annevk or others: Do we have a convention for algorithms that take a lot of parameters? I have a couple candidate formats at https://rawgit.com/jyasskin/web-bluetooth-1/removed-attributes/index.html#dom-bluetoothgattservice-getcharacteristic. |
| 19:41 | <jyasskin_w> | I'm leaning toward the function call/blockquote style. |
| 19:42 | <annevk> | jyasskin_w: I suspect we haven't really established a winning convention yet |
| 19:42 | <annevk> | jyasskin_w: well I know, not suspect |
| 19:43 | <jyasskin_w> | Do you have a preference? :) |
| 19:43 | <annevk> | jyasskin_w: what I suspect is that some future iteration of the style in https://streams.spec.whatwg.org/ will be dictated by IDL |
| 19:44 | <annevk> | jyasskin_w: which I guess argues for your second example, minus the named parameters |
| 19:44 | <Domenic> | annevk: meh... no IDL types there, so not as applicable to jyasskin_w's question |
| 19:44 | <annevk> | (respec has kind of terrible FOUC btw) |
| 19:45 | <jyasskin_w> | Re FOUC: yeah, I'm probably going to switch to Bikeshed next week. |
| 19:45 | <annevk> | \o/ |
| 19:45 | <annevk> | Domenic: nevertheless, still seems like the most likely style that we can adopt for IDL |
| 19:46 | <annevk> | Domenic: but I guess time will tell |
| 19:46 | <jyasskin_w> | Streams doesn't have many functions with >2 parameters either, so maybe I can argue that we should allow named parameters. :) |
| 19:47 | <jyasskin_w> | It is the names that push for the multi-line format. I can remove them if folks prefer it. |
| 19:48 | <annevk> | jyasskin_w: extreme example would be Fetch I guess, which requires passing in an object |
| 19:49 | <annevk> | jyasskin_w: and then the object consists of dozens of members |
| 19:54 | <jyasskin_w> | Yeah. This is weird again because some of the arguments in this BT algorithm are not JS objects. I guess I'll go with the Streams style + named parameters for now, and I can change it if IDL converges to something else. |
| 19:55 | <jyasskin_w> | Thanks |
| 20:09 | <Lorin> | Hi all~ |
| 20:10 | <Lorin> | Since background-position-x / y isn't heavily supported are there talks re: allowing inherit/initial in background-position when mixed with specific measurements? |
| 20:10 | <Lorin> | eg. background-position:-32px inherit; |
| 22:32 | <rcombs> | not quite WhatWG material, but does anyone know who I should talk to to try to advance this? https://datatracker.ietf.org/doc/draft-combs-http-indeterminate-range/ |
| 22:42 | <gsnedders> | rcombs: find out if it's been discussed on any IETF WG mailing list for a start (there's a search list function now!) |
| 22:43 | <gsnedders> | rcombs: try and at least skim what's gone on |
| 22:43 | <rcombs> | gsnedders: I've had some conversation about it on the HTTP WG list, but it's kinda just sat there since April |