| 02:07 | <wanderview> | Domenic: is the streams reference implementation in npm anywhere? I'm thinking about converting some of my old stream modules to the new spec as an experiment |
| 02:08 | <wanderview> | I see some whatwg-stream stuff in npm... but it seems old |
| 02:10 | <wanderview> | I guess maybe this one is what I want... but only updated once it appears... a month ago: https://github.com/h13i32maru/eo.whatwg-streams |
| 03:35 | <frewsxcv> | "To be invited, just send an email or ask us on IRC" can i take anyone up on this offer? :) |
| 03:35 | frewsxcv | is 'frewsxcv' on github if so |
| 03:46 | <caitp-> | hang around for a few hours, someone will probably wake up or come back from a night of drinking soon |
| 03:48 | <frewsxcv> | a room full of users who write standards drinking on a wednesday night. i think i'm going to like it in here |
| 03:51 | <caitp-> | if you're going to write standards, what better way to do it |
| 06:03 | <annevk> | roc: ah thanks! |
| 06:03 | <annevk> | I knew there was someone |
| 06:22 | <Domenic> | wanderview: yeah I don't think I've published. File a bug and I'll do so as soon as I get some free time (either today if TC39 ratholes on something boring, or Monday) |
| 06:34 | <annevk> | frewsxcv: invited to what? |
| 06:34 | annevk | is missing context |
| 08:11 | <MikeSmith> | annevk: whatwg github |
| 08:12 | <MikeSmith> | I did the invite thing for frewsxcv after he inquired here earlier |
| 08:12 | <MikeSmith> | or at least I think I did |
| 08:12 | <MikeSmith> | I pushed some button |
| 08:36 | <annevk> | MikeSmith: I'm not sure we should just give anyone access there though |
| 08:36 | <MikeSmith> | annevk: I checked and frewsxcv seems to be working on rust |
| 08:37 | <MikeSmith> | and otherwise seems clueful |
| 08:37 | <annevk> | ok |
| 08:37 | <MikeSmith> | and also I didn't add him to any teams because I don't know what he's interested in helping with |
| 08:38 | <annevk> | Oh I see, I thought it was about Owners |
| 08:39 | <MikeSmith> | ah |
| 08:39 | <MikeSmith> | yeah I wouldn't add anybody to Owners |
| 08:40 | <MikeSmith> | actually frewsxcv also seems to be contributing to servo too https://github.com/frewsxcv?tab=activity |
| 08:49 | <annevk> | cool cool |
| 09:09 | <annevk> | JakeA: I created https://github.com/whatwg/fetch/issues/27 for all aborting a fetch stuff to come together |
| 09:16 | <annevk> | Domenic: ^^ |
| 09:16 | <Domenic> | yeah |
| 09:18 | <hsivonen> | annevk: cool to see XML5 implemented |
| 09:30 | <JakeA> | annevk: cheers, going through it now. Probably the highest priority thing we have |
| 09:35 | <hsivonen> | MikeSmith: why is the saxtree subtree of the htmlparser hg repo imported into a git repo of its own under github.com/validator? |
| 09:39 | <JakeA> | annevk: fetch(url, controller(c => c.abort())) should be fetch(url, {controller(c) { c.abort() }}) I think |
| 09:39 | <MikeSmith> | hsivonen: oh I thought I had removed that |
| 09:39 | <MikeSmith> | hsivonen: was experimenting |
| 09:39 | <MikeSmith> | will delete it now |
| 09:40 | <JakeA> | annevk: or fetch(url, {controller: c => c.abort()}); |
| 09:46 | <hsivonen> | MikeSmith: I see |
| 09:53 | <annevk> | JakeA: I like that last one, will correct, thanks |
| 09:54 | <hsivonen> | MikeSmith: the SNI patch has now been deployed on validator.nu. Thank you. |
| 09:54 | <hsivonen> | (Still running old Java without new TLS) |
| 09:54 | <MikeSmith> | ah cool! |
| 09:54 | <annevk> | JakeA: done |
| 09:55 | <hsivonen> | I still have a hard time believing that Ubuntu 14.04 doesn't have OpenJDK 8 in backports |
| 09:56 | <MikeSmith> | hsivonen: the Apache HTTP Commons docs are inscrutable. If it weren't for stackoverflow I don't think I ever would have figured out how to migrate to the new API |
| 09:56 | <hsivonen> | MikeSmith: did you ask or was there already an answer there? |
| 09:57 | <MikeSmith> | hsivonen: there was an answer there alreadyーone of those where the person who submitted it basically said, This is based on several hours of frustration, trial-and-error, etc. |
| 09:58 | hsivonen | can imagine several hours of frustration with HttpClient |
| 09:58 | <MikeSmith> | yeah |
| 09:58 | <MikeSmith> | hsivonen: anyway given the track record of the maintainers of that library, it seems likely they're going to change the API again. They did in a breaking way even between, the 4.36 release and the 4.4 release, apparently |
| 09:59 | <hsivonen> | well, at least way back when it was better than the JDK's built-in HTTP client |
| 09:59 | <MikeSmith> | yup |
| 09:59 | <MikeSmith> | I did some looking around for possible alternatives but I couldn't find anything that looked superior and well-documented |
| 10:07 | <annevk> | hsivonen: not just implemented, he's also actively patching the specification |
| 10:07 | annevk | was impressed |
| 10:11 | <hsivonen> | It'll be interesting to see how much code internal subset handling is going to be (even if it ends up being just skipping over it) |
| 10:12 | <MikeSmith> | does the spec (yet) say anything about what do with namespaces? |
| 10:14 | <annevk> | MikeSmith: they're parsed and supported, from what I remember |
| 10:14 | <JakeA> | annevk: crazy thought while I'm reconsuming the various threads. Have we considered request.abort? As in var r = new Request(url); fetch(r); r.abort() |
| 10:15 | <annevk> | JakeA: yeah we have |
| 10:15 | <JakeA> | hah, ok *gets back to reading* |
| 10:15 | <annevk> | JakeA: the problem is that fetch() copies /r/ and mutates it a fair bit |
| 10:15 | <annevk> | JakeA: the copy that is |
| 10:16 | <annevk> | JakeA: it would also get weird with the cache API as wanderview pointed out |
| 10:17 | <JakeA> | hah, just got to that bit of the thread. Tell you what, I'll read it all before having any more "ideas" |
| 10:22 | <annevk> | Oh also, I'm going to moderate that particular issue if this will take a while. Cleaning up stuff and simply deleting off-topic rants if any appear |
| 10:35 | <Domenic> | yes please -_- |
| 10:41 | <annevk> | First comment already seems to have missed part of the post but I'll let it slide... |
| 10:42 | <Domenic> | moderate him harshly, he has already lost all goodwill |
| 10:54 | <annevk> | zcorpan: I guess the relevant Mozilla people for that DOMQuad question are on public-fx? |
| 10:55 | <zcorpan> | annevk: bz is cc-ed at least |
| 10:55 | <zcorpan> | roc: https://lists.w3.org/Archives/Public/public-fx/2015JanMar/0129.html |
| 10:56 | <annevk> | if we haven't shipped I'd say r+ |
| 10:56 | <zcorpan> | you have shipped |
| 10:56 | <annevk> | that is pretty sad |
| 10:57 | <annevk> | zcorpan: also these complicated constructors? |
| 10:57 | <annevk> | zcorpan: that are impossible per IDL? |
| 10:57 | <annevk> | seems hard |
| 10:57 | <zcorpan> | annevk: yeah, webidl designed dictionaries for a single settings argument, not for this sort of overloading |
| 10:58 | <zcorpan> | we could change webidl, but it might still be ugly to have overloading |
| 10:58 | <annevk> | zcorpan: no I mean, did Gecko ship with the weird design? |
| 10:58 | <Domenic> | always remain skeptical of overloading :P |
| 10:59 | <zcorpan> | annevk: ah no i think it requires an actual DOMRect. but can check |
| 10:59 | <annevk> | zcorpan: or do we only return instances of these objects from certain methods? |
| 11:01 | <annevk> | http://lxr.mozilla.org/mozilla-central/source/dom/webidl/DOMPoint.webidl looks like it has overloading |
| 11:01 | <annevk> | zcorpan: ^^ |
| 11:01 | <annevk> | same for http://lxr.mozilla.org/mozilla-central/source/dom/webidl/DOMQuad.webidl |
| 11:01 | <annevk> | only http://lxr.mozilla.org/mozilla-central/source/dom/webidl/DOMRect.webidl is cleanish |
| 11:02 | <zcorpan> | annevk: yeah but the DOMQuad doesn't accept a dictionary as a rect |
| 11:03 | <annevk> | yeah so we should use-counter that |
| 11:03 | <annevk> | and some of the other stuff too |
| 11:03 | <annevk> | :-( |
| 11:44 | <annevk> | So there's URL.createObjectURL(...) and a proposed URL.createFor(...). I was thinking URL.from(...) would be more JavaScripty but it returns a string, so maybe not... |
| 12:18 | <annevk> | JakeA: from your post I can't quite make out what happens when the promise is already fulfilled but the fetch is not |
| 12:19 | <annevk> | JakeA: e.g. there's no example demonstrating what .abort() does within .then() |
| 12:20 | <annevk> | JakeA: which per the goals is something I'd like to see addressed |
| 12:20 | <annevk> | JakeA: and is something that I don't see a general cancelable-promises design addressing |
| 12:20 | <JakeA> | annevk: var p = fetch(url); p.abort() - if headers have arrived, it does nothing. var p2 = fetch(url).then(r => r.text()); p2.abort(); - this would cancel either the request or the stream |
| 12:23 | <annevk> | hmm |
| 12:25 | <JakeA> | annevk: I thought about a design where onCancel would fire even if the promise was settled, but it doesn't really make sense, and I don't think it's needed |
| 12:28 | <JakeA> | annevk: have clarified on github |
| 12:30 | <annevk> | JakeA: when chained it seems okay, and I guess once you have the stream it's okay too... yeah |
| 12:33 | <annevk> | JakeA: not triggering .catch but triggering .finally is also novel, rather nice design I have to say |
| 12:34 | <annevk> | JakeA: I guess that does lead us into promise-subclass land if we want to control other things, e.g. a fetch in-flight |
| 12:34 | <annevk> | JakeA: or maybe the rather ugly controller approach makes a comeback then? |
| 12:48 | <frewsxcv> | MikeSmith: for what it's worth, i never got an invite to the github organization. i would have chimed into that conversation last night but i was asleep :) |
| 13:00 | <MikeSmith> | frewsxcv: ok is there a particular spec you want to help with? |
| 13:00 | <MikeSmith> | frewsxcv: as I think you know, github sorta forces orgs to put contributors into particular teams |
| 13:01 | <MikeSmith> | and we don't have a general team |
| 13:01 | <MikeSmith> | except for the Owners team |
| 13:01 | <frewsxcv> | ah, hm |
| 13:02 | <frewsxcv> | 'dom' seems most relevant |
| 13:02 | <frewsxcv> | or possibly 'fetch' |
| 13:03 | <MikeSmith> | yeah so we don't have teams for those yet |
| 13:03 | <MikeSmith> | so you probably want to ask annevk |
| 13:03 | <MikeSmith> | he's editor for both of those |
| 13:04 | <frewsxcv> | alright |
| 13:04 | <MikeSmith> | the only teams we have so far are for the (now-defunkt) loader spec, "media-keys", notifications, serial spec, streams, and url |
| 13:05 | <frewsxcv> | is there a url repo? |
| 13:05 | <MikeSmith> | yeah |
| 13:05 | <frewsxcv> | that's weird, can't see it on github.com/whatwg bug i can navigate to it manually |
| 13:05 | frewsxcv | *but |
| 13:06 | <MikeSmith> | ah https://github.com/whatwg/url but I think there's another one too maybe |
| 13:06 | <MikeSmith> | https://github.com/webspecs/url |
| 13:07 | <MikeSmith> | I can't remember now if both of the repos are active or if the 2nd one's meant to replace the first |
| 13:10 | <MikeSmith> | frewsxcv: so for now I made a new team called "contributors" and invited you to that |
| 13:10 | <frewsxcv> | :) |
| 13:11 | <frewsxcv> | thanks! |
| 13:11 | <JakeA> | annevk: yeah, I don't want to do the controller thing unless we really have to |
| 13:38 | <annevk> | frewsxcv: I recommend just watching the individual repositories |
| 13:38 | <annevk> | frewsxcv: feel free to fix issues too as you see fit |
| 13:39 | <frewsxcv> | sounds good |
| 13:39 | <annevk> | frewsxcv: once you fix enough issues, we can talk about commit access I guess |
| 13:39 | <frewsxcv> | yeah, working on some stuff now with servo that will probably result in pull requests for some repos |
| 14:32 | <annevk> | JakeA: about getting feedback, https://github.com/whatwg/fetch/issues/24 pretty please? |
| 14:41 | <JakeA> | annevk: thanks for the nudge. I'm still in inbox hell so feel free to bug me about anything urgent like this. Will reply today. |
| 14:46 | annevk | is down to seven tricky threads he isn't quite sure how to tackle |
| 14:46 | <annevk> | well, and presumably over a hundred open issues on various standards |
| 14:47 | <annevk> | oh well, better than this morning |
| 14:57 | <JakeA> | annevk: say we work out the cancellable promise thing… any reason that stuff shouldn't just be added to Promise rather than having a subclass? |
| 15:11 | <bradleymeck> | is there an actual thread about cancellation yet? every time I search for one its just tons of people talking in different places |
| 15:12 | <annevk> | JakeA: hmm, talk to Domenic and TC39? The cancellable promise thing does seem like kind of an uphill battle given the strong feelings |
| 15:13 | <annevk> | bradleymeck: well that hasn't changed |
| 15:13 | <annevk> | biab |
| 15:14 | <bradleymeck> | ive started using generators :-/ they have .return I am using as a cancellation method |
| 15:14 | <bradleymeck> | but its kinda a dirty hack |
| 15:55 | <annevk> | bradleymeck: JakeA's suggestion is here btw: https://github.com/whatwg/fetch/issues/27#issuecomment-86484678 |
| 15:59 | <bradleymeck> | seems sane, not sure I like the { onCancel } arg to new Promise, but w/e |
| 16:02 | <Domenic> | Don't think I like cancellation as a third channel |
| 16:03 | <annevk> | It makes sense... |
| 16:03 | <bradleymeck> | would you treat cancellation as an error? |
| 16:04 | <annevk> | I agree that the constructor reads a bit ugly though |
| 16:04 | <annevk> | This is great: http://youmightnotneedjquery.com/ |
| 16:04 | <caitp> | what does cancelling a promise even mean |
| 16:05 | <annevk> | mu |
| 16:06 | <Domenic> | It doesn't fit with return value/thrown exception |
| 16:06 | <Domenic> | it isn't analogous to fulfilled or rejected |
| 16:06 | <Domenic> | in that it isn't a type of resolution |
| 16:06 | <Domenic> | it's not a state or a fate really |
| 16:07 | <caitp> | you're either saying "cancel my subscription to finding out what happened" or "stop doing the thing that will cause a resolution" --- but it could be either one |
| 16:07 | <caitp> | and the former is problematic for promise chaining |
| 16:08 | <caitp> | latter is too, probably |
| 16:08 | <Domenic> | cancellation token seems more robust in the face of such existential questioning |
| 16:08 | <Domenic> | since you could do it today |
| 16:09 | <Domenic> | although it kind of punts on the question of how/whether consumers observe |
| 16:10 | <darobin> | annevk: if anything that page makes me want to use jQuery more |
| 16:10 | <jgraham> | annevk: The inconsistent use of semicolons in the examples is maddening |
| 16:11 | <jgraham> | darobin: Well it gets better for !jQuery after the ajax stuff |
| 16:11 | <darobin> | jgraham: some parts yes, then it gets worse and better on and off |
| 16:12 | <darobin> | and if you switch to IE8, it mostly gets worse |
| 16:12 | <wanderview> | Domenic: are the node.js/io.js folks considering implementing whatwg-streams? wondered after this issue: https://github.com/whatwg/streams/issues/304 |
| 16:12 | <caitp> | but it's only looking at ie compatibility |
| 16:12 | <Domenic> | wanderview: yeah, there's definite interest |
| 16:12 | <caitp> | it's not like webkit/blink/gecko are perfect and non-buggy |
| 16:13 | <wanderview> | Domenic: but they have not started working on it yet? |
| 16:13 | <annevk> | Domenic: I guess the other thing you could do is embrace async is a little different |
| 16:13 | <Domenic> | wanderview: no, probably just going to lift the implementation from v8 |
| 16:13 | <jgraham> | caitp: I imagine they are more or less compatible on the things listed there. It's mostly not rocket science. |
| 16:13 | <Domenic> | annevk: meaning what? |
| 16:13 | <jgraham> | But testsneeded if you know of any bugs :) |
| 16:14 | <wanderview> | Domenic: hmm... can you explain why streams is a language (v8) feature and not more of a DOM/js hosted thing? |
| 16:14 | <caitp> | well, it depends how much new stuff you want to use |
| 16:14 | <bradleymeck> | wanderview: there is a lot of talk / concern about needing data before daing things |
| 16:14 | <Domenic> | wanderview: they're like promises |
| 16:14 | <bradleymeck> | doing* |
| 16:14 | <annevk> | Domenic: meaning you might need more than return and throw |
| 16:14 | <Domenic> | wanderview: implemented as a v8 extension probably since blink team owns it |
| 16:14 | <Domenic> | annevk: sure, but i'm saying that cancel isn't even in the same category |
| 16:14 | <caitp> | qsa works inconsistently between different browsers when it comes to xml crap |
| 16:14 | <Domenic> | it affects the ongoing operation; it's not a result of it |
| 16:15 | <caitp> | cloneNode is broken for template elements in webkit (until january afaik) |
| 16:15 | <caitp> | lots of other stuff |
| 16:15 | <caitp> | the web is ridiculously complicated, and probably impossible to simplify, so stuff is gonna be wrong |
| 16:15 | <wanderview> | Domenic: ok... but its just some properties on the global essentially... not actual language primitives introduced, right? |
| 16:15 | <Domenic> | wanderview: i mean i guess so, in the same way as Promise is just a property on the global |
| 16:17 | <bradleymeck> | wanderview: it will need to have hooks in the VM somehow for implementations to allow better chaining etc that we can't see from the ref impl if we want to optimize them. |
| 16:18 | <bradleymeck> | which is one of the things we are curious about, as well as some of the usage of getters/setters |
| 16:18 | <wanderview> | right... I guess my confusion stems from stuff like Promise being implemented under "DOM" in gecko |
| 16:18 | <bradleymeck> | but we have lots of questions, just no data to do much |
| 16:19 | <Domenic> | bradleymeck: you keep saying "we" but you mean "I" |
| 16:19 | <caitp> | surprised they didn't put it in the spidermonkey part of the tree |
| 16:20 | <bradleymeck> | Domenic: I have trevnorris and others from NS |
| 16:20 | <bradleymeck> | I am not alone |
| 16:20 | <Domenic> | yes, they are much more understanding than you are |
| 16:20 | <bradleymeck> | as long as it is not frozen for eternity its not that big of a deal for us, but it sounds like it is being frozen before it gets userland testing |
| 16:21 | <bradleymeck> | promises were in userland for a while before they landed |
| 16:21 | <wanderview> | caitp: maybe there is a SM part too... this is the binding part I'm familiar with: https://dxr.mozilla.org/mozilla-central/source/dom/promise |
| 16:21 | <caitp> | i don't see it with the other self-hosted JS stuff in sm |
| 16:22 | <bradleymeck> | I don't understand the freezing; but I'm backing off and letting others poke around at it. now I'm just kinda curious/concerned if there does show up a problem but it is frozen |
| 16:23 | <wanderview> | bradleymeck: do you mean freezing the spec or locking a stream? (sorry, missed the context) |
| 16:23 | <bradleymeck> | the spec |
| 16:24 | <wanderview> | it seems like every spec continues to evolve over time... its just how much you need to pay attention to backward compatibility |
| 16:25 | <bradleymeck> | it will evolve but it would ease my mind to have some testing out there to make sure nothing nefarious is hiding |
| 16:26 | <bradleymeck> | node's crypto calling .nextTick is pretty heinous how many times it ends up being called |
| 16:27 | <annevk> | wanderview: Promise being in DOM is meant as a "temporary" hack |
| 16:27 | <wanderview> | bradleymeck: are your spec concerns written up any where? I have to run now, but would be interested in learning more later |
| 16:28 | <annevk> | wanderview: leads us to violate the specification in some edge cases |
| 16:28 | <wanderview> | annevk: awesome |
| 16:28 | <bradleymeck> | wanderview: ping trevnorris hes got the things |
| 16:28 | <wanderview> | thanks |
| 16:31 | <annevk> | wanderview: it seems better than https://code.google.com/p/v8/issues/detail?id=3237 |
| 16:41 | <annevk> | Domenic: I don't know. To me it makes sense. Return/throw is me controlling the flow. Cancel is the outside controlling the flow. In synchronous context cancel just makes no sense. |
| 16:41 | <caitp> | "break" statements are usually considered to be a part of flow control |
| 16:41 | <annevk> | Domenic: but I guess you've had this argument a 1000 times already, no need to indulge me :-) |
| 16:41 | <caitp> | but breaking a promise is just too tacky |
| 18:02 | <Domenic> | still kinda sad we didn't get more puns, keep and break are a lot more fun than fulfill and reject |
| 19:59 | <Domenic> | oh wow the cancelable promise thread got getify'd, this'll be fun |
| 20:00 | <Domenic> | wow i think he does not know what backpressure means |
| 20:05 | <bradleymeck> | Domenic: he went from 0-60 on spec knowledge in like 2 years @-o, not sure I always agree but he has changed a lot |
| 20:06 | <bradleymeck> | has same nature to freak out as I do though |
| 20:08 | <roc> | annevk: see my email in public-fx ... we shipped a Constructor(DOMRectReadOnly), which is what the spec said at the time, and doesn't have problems AFAIK |
| 20:09 | <Domenic> | sigh i shouldn't be mean |
| 20:17 | <caitp> | what does backpressure mean? |
| 20:17 | <caitp> | for those of us who don't know how to spell good and want to do other stuff good too |
| 20:18 | <annevk> | roc: it's mostly the overloading that would be problematic, and it seems passing a DOMRect is not the most useful, but I'll let you guys sort it out :-) |
| 20:20 | <bradleymeck> | having a stream pushing data to another stream that is consuming; the stream that is consuming being being able to halt the pushing stream while it processes stuff is back pressure. Generally this is accomplished by using pull streams (so the consumer controls when new data comes in) |
| 20:21 | <roc> | I don't think overloading DOMRectReadOnly and DOMPointInit is problematic |
| 20:27 | <caitp> | Domenic: do you know who would be good to ping about something that needs to be checked into blink on the next v8 roll? sherrifs or somethin? |
| 20:31 | <caitp> | actually, it may not be needed at all |
| 21:02 | <zcorpan> | roc: thanks. replied |
| 21:04 | <zcorpan> | roc: any opinion on introducing DOMMatrixInit (other thread on public-fx)? |
| 21:05 | <IZh> | Hi! Getting 403 error on https://html.spec.whatwg.org/ |
| 21:06 | <IZh> | On https://whatwg.org/ too. |
| 21:06 | <zcorpan> | Hixie: ^ |
| 21:20 | <IZh_> | Channel logs' site is not working too. |
| 21:21 | <IZh_> | Upd: WHATWG's sites now works. |
| 21:21 | <caitp> | it's a miracle |
| 22:24 | <wilhelm> | "RDFa Working Group now Closed". And there was much rejoicing. |
| 22:34 | <tantek> | wow for reals? (I mean on the closed, not the rejoicing) |
| 22:41 | <jgraham> | ere actually was much rejoying |
| 22:41 | <jgraham> | *rejoycing |
| 22:41 | <jgraham> | A parade just went past my window |
| 22:45 | <tantek> | next up: who around here is using JSON-LD, for anything? |
| 22:52 | <gavinc> | tantek: me! ... but I'm not that normal ;) |