| 00:12 | <JonathanNeal> | Any way I’m able to read the November 2014 TC39 meeting notes? |
| 00:15 | <TabAtkins> | JonathanNeal: When they come out (they're posted on github) |
| 00:15 | <TabAtkins> | alex sexton takes them, I believe |
| 00:15 | <JonathanNeal> | I’ll ask him about it. Just saw Array|String#contains was renamed #includes https://github.com/tc39/Array.prototype.includes |
| 00:55 | <Domenic> | rwaldron is the note-taker actually |
| 00:55 | <Domenic> | For a list of ES6 changes at the last meeting follow Allen: https://twitter.com/awbjs |
| 01:57 | <rwaldron> | JonathanNeal they will be published tomorrow |
| 03:45 | <JonathanNeal> | rwaldron: swell, i wil file an issue with our polyfill repo at that time, and on any other repos who got in early |
| 08:01 | <hgl> | i was reading the es6 spec, and found out that how a y module is resolved in "import x from 'y';" is actually implementation defined. I wonder if a spec exists to define such resolution? |
| 08:10 | <Ms2ger> | jorendorff, ^ |
| 09:21 | <zcorpan> | are there specs using "serializer" in idl? |
| 09:27 | <annevk> | zcorpan: web performance maybe? |
| 09:28 | <Ms2ger> | zcorpan, that's toJSON, right? Webperf should have used it, but I don't know if they ever bothered |
| 09:28 | <annevk> | hgl: there's https://github.com/whatwg/loader |
| 09:31 | <zcorpan> | annevk: Ms2ger: i can't find "serializer" in any of these http://www.w3.org/wiki/Web_Performance/Publications |
| 09:31 | <hgl> | annevk, thanks. reading it right now. |
| 09:32 | <annevk> | zcorpan: http://w3c.github.io/navigation-error-logging/#sec-navigationerrorentry needs it |
| 09:32 | <annevk> | zcorpan: search for JSON in that document |
| 09:33 | <annevk> | oh they standardized on "ssl"? ugh |
| 09:46 | <zcorpan> | does an [ArrayClass] interface need a serializer? |
| 09:46 | <foolip> | Hixie, zcorpan, I wrote "SVN mirror only; no pull requests" on the assumption that pull requests would not be welcome. Feel free to change that. |
| 09:47 | <foolip> | just make sure to never accidentally merge a pull request, it'd require manual intervention to get the mirroring working again |
| 09:51 | <MikeSmith> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=27378#c9b-sides |
| 09:51 | <MikeSmith> | oops |
| 09:51 | <MikeSmith> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=27378#c9 |
| 09:52 | <MikeSmith> | the "effective script origin" document.domain thing |
| 09:52 | <MikeSmith> | We really don't have any tests for this? |
| 09:54 | <zcorpan> | we don't need tests, the web has shown that it is interoperable |
| 09:55 | <Ms2ger> | MikeSmith, you're surprised? |
| 09:56 | <MikeSmith> | heh |
| 09:57 | <MikeSmith> | I'm reading more of that comment thread now |
| 09:57 | <MikeSmith> | depressing |
| 10:16 | <annevk> | zcorpan: [ArrayClass] is ideally removed |
| 10:16 | <zcorpan> | annevk: yes but that doesn't help me :-) |
| 10:16 | <annevk> | MikeSmith: you can change that! |
| 10:17 | <annevk> | zcorpan: an interface with [ArrayClass] could also have a serializer, it doesn't need one though |
| 10:19 | <jgraham> | MikeSmith: You are forgetting the first law of testsuite dynamics. "A useful testsuite for feature X will not exist unless a browser vendor has attempted an implementation of that feature from the spec" |
| 10:19 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3315 |
| 10:19 | <Ms2ger> | Note that it's only one direction of implication :) |
| 10:20 | <zcorpan> | maybe webidl could serialize [ArrayClass] as arrays by default? |
| 10:20 | <annevk> | zcorpan: getClientRects() should really use iterable<> |
| 10:21 | <zcorpan> | annevk: is that compatible? |
| 10:21 | <annevk> | zcorpan: the plan is to try that for NodeList too |
| 10:21 | <annevk> | zcorpan: hopefully |
| 10:22 | <zcorpan> | cool |
| 10:22 | <jgraham> | (The second law is "When a browser vendor has implemented a feature the chance of a useful testsuite for that feature decreases with the number of preexisting behaviours of that feature", and the third law is "the more useful a testsuite is, the more likely it is to be stuck in a review queue") |
| 10:22 | <zcorpan> | if that works out i guess we can kill [ArrayClass] ? |
| 10:25 | <zcorpan> | annevk: i don't see item() in iterable<> |
| 10:25 | <annevk> | zcorpan: you'll still need to define the class |
| 10:25 | <annevk> | zcorpan: it just gives you Symbol.iterator and some extras |
| 10:25 | <zcorpan> | oh |
| 10:34 | <zcorpan> | annevk: so it's not a replacement for [ArrayClass] then |
| 10:35 | <annevk> | zcorpan: euhm, [ArrayClass] doesn't define item() for you either |
| 10:35 | <zcorpan> | i know |
| 10:39 | <zcorpan> | filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=27427 |
| 12:03 | <smaug____> | has anyone reviewed web animations spec? |
| 12:06 | <smaug____> | there is AnimationTimeline is bound to a document, AnimationPlayers are created using a ctor, and AnimationTimeline refers to AnimationPlayer instances... how is this all supposed to work in case of window.open() or document.open() (which break window<->document 1-1) |
| 12:06 | <smaug____> | TabAtkins: you might know |
| 12:12 | <smaug____> | oh, timeline is passed as a param.. |
| 12:12 | <smaug____> | nm then |
| 12:44 | <WesleyCrushed_> | hi. is the generic behavior of the "download" attribute of <a> defined somewhere? it looks to be a boolean attribute that is also a value attribute |
| 12:46 | <ondras> | https://html.spec.whatwg.org/multipage/semantics.html#the-a-element |
| 12:46 | <ondras> | The download attribute, if present, indicates that the author intends the hyperlink to be used for downloading a resource. The attribute may have a value; the value, if any, specifies the default file name that the author recommends for use in labeling the resource in a local file system. |
| 12:48 | <WesleyCrushed_> | so say i'm using xhtml5. how do i write it without specifying a filename? it looks that writing download="download" would make me download a file named "download" |
| 12:48 | <WesleyCrushed_> | maybe download="" ? |
| 12:51 | <ondras> | I would definitely try that |
| 12:52 | <Ms2ger> | download="" is correct |
| 12:52 | <Ms2ger> | See the section on boolean attributes |
| 13:21 | <darobin> | Domenic: I'm running the discourse update now, I reckon we can switch it to the beta channel too to get weekly upgrade |
| 13:21 | <darobin> | *upgrades |
| 13:22 | <darobin> | Domenic: also, since you're admin and all you should probably send me your public key so I can allow you to break the server too :) |
| 14:21 | <MikeSmith> | Ms2ger: download isn't defined as a boolean attribute, right? |
| 14:22 | <Ms2ger> | MikeSmith, I think that section is the only one that explains that `foo` and `foo=''` are equivalent |
| 14:22 | <darobin> | MikeSmith: it takes a file name |
| 14:22 | <Ms2ger> | (Except the parser, obviously) |
| 14:23 | <MikeSmith> | darobin: yeah but in the case where no value for it is specified, it behaves like a boolean |
| 14:24 | <darobin> | MikeSmith: ah, sorry, hadn't looked far enough upscroll |
| 14:27 | <annevk> | I think it behaves as a boolean is misleading |
| 14:27 | <annevk> | It just has special meaning for an empty string value |
| 14:28 | <annevk> | A boolean attribute can have its own attribute name as value, as in disabled=DISablED |
| 14:29 | <MikeSmith> | right, true, it's not a matter of "behave as a boolean" |
| 14:30 | <annevk> | E.g. if you want to specify a title with empty string you can do <var title>; doesn't make it a boolean attribute |
| 14:43 | <MikeSmith> | well that's not a great comparison, because title on var has no effect on UA behavior while the download attribute does, but I see your point |
| 14:46 | <annevk> | MikeSmith: <p title=test>test <var title=>test</var> test |
| 14:47 | <annevk> | MikeSmith: though that's not really cross-browser... |
| 14:50 | <MikeSmith> | oh |
| 15:04 | <iliakan> | Where is the most up2date version of DOM standard? http://w3c.github.io/dom/ ? |
| 15:04 | <iliakan> | or https://dom.spec.whatwg.org/ ? |
| 15:04 | <Ms2ger> | https://dom.spec.whatwg.org/ |
| 15:05 | <iliakan> | I got somewhat confused, why 2 places? |
| 15:05 | <iliakan> | the documents are quite different. |
| 15:05 | <Ms2ger> | Politics |
| 15:05 | <Ms2ger> | I don't want to talk about it |
| 15:05 | <iliakan> | sorry didn't want to hurt anyone's feelings. |
| 15:06 | <Ms2ger> | Oh, it not you that hurt them :) |
| 15:08 | <annevk> | iliakan: there's a bit of a thing going on with W3C copying WHATWG documents |
| 15:09 | <annevk> | iliakan: TL;DR is that if there's WHATWG document, it's more up to date |
| 15:09 | <iliakan> | is there any place to read about it? maybe a thread in a mailing list? |
| 15:10 | <iliakan> | just to get a glipse of knowing what's going on |
| 15:10 | <gsnedders> | if you want to read thousands of emails, there's plenty :) |
| 15:10 | <MikeSmith> | iliakan: you probably don't want to read those threads :) |
| 15:10 | <iliakan> | eh, I teach people JS/DOM stuff and I want to tell them |
| 15:11 | <annevk> | There's nothing really canonical on this |
| 15:11 | <annevk> | http://lists.w3.org/Archives/Public/www-archive/ has some http://lists.w3.org/Archives/Public/public-w3process/ has some too |
| 15:12 | <annevk> | comes up on http://lists.w3.org/Archives/Public/public-webapps/ now and then |
| 15:12 | <rubys> | iliakan: my summary is here: http://lists.w3.org/Archives/Public/www-archive/2014Nov/0039.html |
| 15:13 | <rubys> | my summary is specific to URL, but some of the points apply elsewhere |
| 15:13 | <rubys> | also relevant: http://lists.w3.org/Archives/Public/public-w3process/2014Nov/0169.html |
| 15:14 | <iliakan> | okay thanks, at least I'll have something to respond on their "why look here not there?" question |
| 15:16 | <annevk> | iliakan: https://github.com/servo/servo/wiki/Relevant-spec-links is pretty canonical I guess, though no "why" |
| 15:16 | <MikeSmith> | iliakan: if you're teaching people about where to look for information, arguably you don't want to tell them to be reading the specs directly but instead just using MDN, which is generally kept pretty well up to date and presents the information in much more web-developer-friendly way |
| 15:16 | <iliakan> | MikeSmith: consider Element.prototype.remove() as an example |
| 15:17 | <iliakan> | the method is convenient and is easily polifilled |
| 15:17 | <iliakan> | if it's going to be used in all browsers (be part of the standard) I should recommend to use it |
| 15:17 | <iliakan> | and no it's not on MDN |
| 15:18 | <MikeSmith> | what is that? |
| 15:19 | <MikeSmith> | I mean, where did it come from? |
| 15:19 | <iliakan> | https://dom.spec.whatwg.org/#dom-childnode-remove |
| 15:19 | <MikeSmith> | oh |
| 15:20 | <rubys> | If it is not on MDN, it probably isn't widely implemented yet; and possibly may change before the browser coalesce around an agreement. |
| 15:21 | <annevk> | it's in Firefox and Chrome |
| 15:21 | <annevk> | (at least) |
| 15:21 | <MikeSmith> | Ms2ger: do we even have test for that? |
| 15:22 | <Ms2ger> | Dunno |
| 15:23 | <darobin> | it's a bug that remove() isn't in MDN |
| 15:23 | <darobin> | it shoudl be |
| 15:23 | <darobin> | and yes there's a test for it, it even passes! |
| 15:23 | <MikeSmith> | I probably even reviewed it! |
| 15:23 | <Ms2ger> | Yep |
| 15:23 | <Ms2ger> | ChildNode-remove.js |
| 15:23 | <MikeSmith> | yeah I see it now |
| 15:24 | <MikeSmith> | now my faith in MDN is shaken |
| 15:25 | <caitp> | :O! |
| 15:25 | <rubys> | Does MDN take bug reports? |
| 15:25 | <darobin> | rubys: I think you just go ahead and edit the wiki :) |
| 15:26 | <rubys> | ah, so it is a case of community developed documentation sometimes lags implementations. |
| 15:26 | <darobin> | MikeSmith: don't let it shake your faith, even when wrong it is *still* better than going to anyone's specs, so your advice to iliakan was good |
| 15:26 | <darobin> | rubys: sometimes, but usually, as MikeSmith says, it's really good |
| 15:27 | rubys | nods |
| 15:27 | <annevk> | Usually bugs against Firefox get tagged "dev-doc-needed" to ensure MDN is updated |
| 15:27 | <annevk> | Perhaps that's still pending or someone forgot to tag the bug |
| 15:27 | <darobin> | rubys: so, MDN does take bug reports (https://bugzilla.mozilla.org/enter_bug.cgi?format=guided#h=dupes|Developer%20Documentation|) but the preferred option is to edit |
| 15:29 | <MikeSmith> | iliakan: to get back to your original question, remove() isn't in the W3C-publishe DOM spec version? (given the above about it being in Firefox and Chrome I'd be really surprised if it weren'T) |
| 15:30 | <iliakan> | it's there, under ChildNode interface as I see, but replace is not |
| 15:30 | <darobin> | MikeSmith: remove() is in, but (s)he was referring to the fact that the github version is woefully out of date |
| 15:30 | <MikeSmith> | ah ok |
| 15:31 | <darobin> | iliakan: replace() is not because it's not implemented (or wasn't back then) |
| 15:31 | <iliakan> | yeah, but it's going to be? |
| 15:31 | <Ms2ger> | I haven't heard objections yet |
| 15:31 | <MikeSmith> | iliakan: fwiw I guess one of the best things you could teach people is to tell them about #whatwg and suggest they come here to ask questions when they have them |
| 15:31 | <darobin> | the github version was supposed to be quite simply destroyed with the next udpate to the TR version, but that didn't happen |
| 15:31 | <Ms2ger> | Try if Gecko takes a patch :) |
| 15:31 | <Ms2ger> | Or write tests for it |
| 15:32 | <iliakan> | MikeSmith: let them learn something from the docs first :) and come here educated enough :) |
| 15:32 | <Ms2ger> | darobin, ha. haha. hahaha. |
| 15:32 | <MikeSmith> | iliakan: fair enough |
| 15:32 | <darobin> | actually, remove() is in MDN... https://bugzilla.mozilla.org/enter_bug.cgi?format=guided#h=dupes|Developer%20Documentation| |
| 15:33 | <iliakan> | umm sorry indeed so, I just didn't find it fast |
| 15:33 | <iliakan> | guess they may have problems w/ it too |
| 15:33 | <darobin> | iliakan: I find your lack of faith in MDN... disturbing |
| 15:33 | <darobin> | sorry, that was the wrong link |
| 15:33 | <darobin> | https://developer.mozilla.org/en-US/docs/Web/API/ChildNode.remove |
| 15:34 | <iliakan> | darobin: please consider that to be a lack of faith in my/their finding skills |
| 15:34 | <iliakan> | when I know there's a single "most recent" document, it's the 1st place to go for modern stuff |
| 15:34 | <darobin> | iliakan: no worries, but in general if it's for teaching MDN is better because it tells you about stuff that actually works |
| 15:34 | <darobin> | whereas pretty much all specs are fiction |
| 15:34 | <darobin> | to a point |
| 15:34 | <Ms2ger> | "pretty much"? |
| 15:38 | <darobin> | Ms2ger: I added that because I'm sure someone can find an old spec that is actually implemented :) |
| 15:38 | <Domenic> | iliakan: https://github.com/servo/servo/wiki/Relevant-spec-links is a good resource for spec links |
| 15:38 | <Domenic> | I personally am not a fan of MDN these days because I am used to reading specs and also MDN is often way outdated or inaccurate. |
| 15:39 | <Ms2ger> | Woo, Servo :) |
| 15:39 | <iliakan> | Domenic: thanks, and tend to agree about MDN. There should be only 1 source of truth. |
| 15:39 | <Domenic> | e.g. what is this stuff https://developer.mozilla.org/en-US/docs/Web/API/Window.frames "DOM Level 0. Not part of any standard." |
| 15:39 | <Domenic> | it's right there in html |
| 15:39 | <Ms2ger> | And we have always been at war wit Eurasia |
| 15:40 | <darobin> | Domenic: who cares about that? it tells you how it works which is what's needed |
| 15:40 | <annevk> | darobin: it means you might end up getting into bullshit arguments when using it |
| 15:41 | <Domenic> | darobin: it's not terribly accurate about that either |
| 15:41 | <Domenic> | and also that, people telling me window.frames is nonstandard and i shouldn't be using it |
| 15:41 | <darobin> | bullshit arguments? |
| 15:42 | <darobin> | Domenic: beats working from specs most of the time |
| 15:42 | <MikeSmith> | I'm sad for myself that I didn't even know there was a remove() for me to use. I've always just used removeChild and complained about how stupidly redundant/verbose it makes things. (assuming that remove() is the thing that cuts out that and expresses it the right way) |
| 15:42 | <darobin> | well, if people wish to make an argument from standards, they should look at standards |
| 15:42 | <darobin> | MikeSmith: you still need to use removeChild() for IE at this point |
| 15:42 | <MikeSmith> | OK |
| 15:43 | <aleray> | hi, does one know if there is a video format/codecs supported by all major modern browsers? |
| 15:43 | <darobin> | but if people need developer docs, they should use developer docs |
| 15:43 | <darobin> | GIF89a? |
| 15:43 | darobin | hides |
| 15:43 | <annevk> | darobin: I don't think it works to argue that one part of the docs are relevant and another should be ignored |
| 15:45 | <darobin> | annevk: actually it does, it's a pretty usual way of referring to documents... |
| 15:46 | <Domenic> | H.264 is everywhere now that Firefox fixed itself on Mac, right? |
| 15:46 | <MikeSmith> | Domenic: I think it's sad if your message to webdevs is that web-developer documentation sucks, so, sorry, you have to read the specs. Because the specs aren't generally super-approachable for a lot of devs, and regardless are generally written for UA implementors and not optimized for reading by normal people |
| 15:47 | <MikeSmith> | http://caniuse.com/#search=mpeg-4 |
| 15:48 | <Domenic> | MikeSmith: generally agreed. I guess I wouldn't say that's my message to devs in general ... but it's my message to most people who ask me directly, or people I work with. |
| 15:48 | <Domenic> | Oh interesting, a substantial difference between Chrome and Opera. |
| 15:48 | <MikeSmith> | Domenic: yeah, point taken (on that message) |
| 15:48 | <rubys> | It is almost as if there are as many opinions as there are people on this channel. |
| 15:49 | <MikeSmith> | heh |
| 15:49 | <Domenic> | "Browsers have trouble with more than one audio track in a video (for multi-language support): IE 11 supports it, Firefox plays the last track, Chrome plays the first track." bahahaha *cries* |
| 15:50 | <darobin> | that's an interesting use of the word "trouble" |
| 15:51 | <gsnedders> | darobin: well, it's a different sort of trouble to you |
| 15:52 | <annevk> | jgraham: anything on testing permission APIs yet? |
| 15:52 | <annevk> | jgraham: did I miss a reply? |
| 15:53 | <annevk> | oh you did reply |
| 15:53 | <annevk> | :-( |
| 15:54 | <annevk> | jgraham: note that I not just care about bypassing the dialog, I also want to know what that dialog ends up storing |
| 15:54 | <annevk> | jgraham: to make tests around document.domain / origins |
| 15:54 | <annevk> | but I'm not too enthusiastic about trying to pioneer this... |
| 15:57 | <aleray> | MikeSmith, thanks |
| 16:13 | <jgraham> | annevk: Neither is anyone else |
| 16:15 | <MikeSmith> | "pioneer this" = write soem test cases? |
| 16:16 | <annevk> | MikeSmith: setting up the supporting framework |
| 16:16 | <Ms2ger> | Automated |
| 16:16 | <MikeSmith> | gsnedders has no open PRs right now |
| 16:16 | <annevk> | MikeSmith: I think I'll end up writing some non-automated tests |
| 16:17 | <MikeSmith> | any tests at all would be nice at this point |
| 16:18 | <annevk> | The other problematic bit is that we don't really seem to have agreement on what is desirable behavior |
| 16:54 | <mathiasbynens> | Domenic: kudos for https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-11/nov-20.md#54-io-streams-as-part-of-the-es-standard-library |
| 16:54 | <Domenic> | mathiasbynens: meh, that was a disappointing conversation :-/ |
| 16:56 | <annevk> | The last line from Mark Miller is somewhat divisive and not really a fair summary |
| 17:00 | <annevk> | smaug____: what's the story with event listeners and microtasks again? |
| 17:02 | <Domenic> | Still kicking myself I forgot to say "CC0" in the meeting |
| 17:03 | <smaug____> | annevk: what about them? |
| 17:03 | <annevk> | Domenic: at some point someone asked about that on the mailing list, I wonder where they are with that now |
| 17:03 | <annevk> | Domenic: Ecma licensing is terrible |
| 17:03 | <smaug____> | microtask ends when the outermost event listener has been called in normal cases |
| 17:03 | <Domenic> | Yeah, unfortunately the person who asked was weird/rude, so they were easy to dismiss. |
| 17:04 | <annevk> | smaug____: "normal" being non-synchronous cases? |
| 17:04 | <annevk> | smaug____: as in it's not any different from end-of-task? |
| 17:04 | <smaug____> | I mean case like "users clicks and a click event is dispatched" |
| 17:05 | <annevk> | I see, so there's no relationship then |
| 17:05 | <smaug____> | but not cases like "timer runs and its callback dispatches click" |
| 17:05 | <annevk> | great, it's simpler than I thought then, good good |
| 17:06 | <annevk> | Domenic: how dare you break Allen's invariants |
| 17:06 | <Domenic> | ^_^ |
| 17:06 | <annevk> | Domenic: now ES6 can't explain HTML |
| 17:06 | <annevk> | :p |
| 17:06 | <Domenic> | I really didn't know what would happen with that test case actually |
| 17:07 | <annevk> | I wonder if this is in part due to the WindowProxy setup that ES6 still does not acknowledge |
| 17:07 | <gsnedders> | annevk, Domenic: the big problem with the licensing is it has to go all the way up to the Ecma general council :( |
| 17:07 | <annevk> | gsnedders: that's not the big problem |
| 17:08 | <Domenic> | annevk: yeah, the way in which self.x changed seems very WindowProxy-like... I wasn't sure that document.open and WindowProxy interacted though... |
| 17:08 | <gsnedders> | annevk: it means it's a hellish amount of work and fighting pushback to get it to happen |
| 17:08 | <Domenic> | the thing ES6 does not acknowledge is related to `this` though, right? So you sidestepped that by using `self` |
| 17:09 | <annevk> | Domenic: yeah I guess |
| 17:09 | <annevk> | Domenic: but self might return a WindowProxy |
| 17:09 | <annevk> | Domenic: not sure |
| 17:09 | <Domenic> | I think it does, right? |
| 17:09 | <Domenic> | self === window is a WindowProxy |
| 17:09 | <Domenic> | I don't remember what the issue was with ES6 vs. WindowProxy though |
| 17:10 | <annevk> | Domenic: mostly "this" |
| 17:10 | <annevk> | Domenic: the other problem with WindowProxy is that it's not defined in terms of ES operations (yet) |
| 17:11 | <annevk> | Domenic: so we don't know exactly how it proxies from the spec |
| 17:11 | <Domenic> | annevk: heh, yeah, I was looking at WebIDL's getter/setter/creator/deleter yesterday and thinking the same thing |
| 17:27 | <SteveF_> | TabAtkins: hi, need a little help with bikeshed; am trying to link to this http://www.w3.org/TR/wai-aria/host_languages#implicit_semantics from another spec, is there an automethod or do I need to use a regular link? |
| 17:30 | <TabAtkins> | SteveF_: At the doctor right now, I'll answer you when I get into the office. |
| 17:33 | <SteveF_> | TabAtknins: thanks no rush! |
| 18:06 | <annevk> | Domenic: I'm not sure what Allen's reply to me means |
| 18:46 | <JonathanNeal> | maybe we need a polyfill standards group |
| 18:56 | <Domenic> | rubys: I don't understand which part of my message you disagree with. |
| 19:26 | <wanderview> | JakeA: annevk: once cache is expanded beyond SW, do we know what it should do on data URI workers? there is no origin there, right? |
| 19:30 | <annevk> | wanderview: there's an origin, you can just never get same-origin with it |
| 19:30 | <annevk> | wanderview: what happens with localStorage? |
| 19:31 | <wanderview> | annevk: is the origin for data uri spec'd somewhere? |
| 19:31 | <annevk> | wanderview: https://url.spec.whatwg.org/#origin |
| 19:32 | <wanderview> | annevk: ah... globally unique identifier... thanks! |
| 19:41 | <annevk> | Domenic: https://esdiscuss.org/topic/realm-api-and-this-global btw |
| 19:41 | <annevk> | Domenic: no replies |
| 19:42 | <annevk> | Domenic: bug is also still open |
| 19:42 | <Domenic> | annevk: yeah, was too lazy to dig up the link, but i remember :-/ |
| 19:56 | <Domenic> | annevk: ha! Movement! |
| 19:58 | <annevk> | I should probably not have expressed disappointment, but really, the amount of time it takes to get something fixed... |
| 20:00 | <annevk> | Hmm, ecmascript.org doesn't work over HTTPS |
| 20:12 | <iliakan> | I have a question regarding append/prepend/before/after |
| 20:13 | <iliakan> | these methods were in w3c version of DOM4, but were removed 12 June 2014 |
| 20:13 | <iliakan> | they are still in WhatWG version though |
| 20:13 | <iliakan> | no browser implemented those yet |
| 20:14 | <iliakan> | are these methods going to be supported eventually? what's the current state? |
| 20:15 | <zcorpan> | iliakan: my guess is that they were removed from the w3c version because no browser implement them yet |
| 20:15 | <iliakan> | https://bugzilla.mozilla.org/show_bug.cgi?id=911477 hanging |
| 20:16 | <zcorpan> | iliakan: i'm haven't seen anyone saying these shouldn't exist, so they're just not implemented yet |
| 20:16 | <iliakan> | https://code.google.com/p/chromium/issues/detail?id=255482 |
| 20:16 | <iliakan> | these 2 don't say "no" |
| 20:17 | <TabAtkins> | SteveF_: If the ARIA spec has decent metadata for its definitions, we can add it to Shepherd's system and it'll be available for anyone to autolink. If it doesn't, you can add custom anchor definitions to your spec for Bikeshed to use, so you can still use the easy auto-linking syntax. This is documented in the docs, but I'm about to change the syntax, so |
| 20:17 | <TabAtkins> | if you use it, let me know so I can give you a heads-up. ^_^ |
| 20:18 | <iliakan> | webkit too |
| 20:18 | <zcorpan> | iliakan: i guess https://code.google.com/p/chromium/issues/detail?id=255482#c3 sums up the current status |
| 20:19 | <iliakan> | yes |
| 20:19 | <iliakan> | guess, es6 still blocking |
| 20:19 | <iliakan> | some stuff may be still in flux |
| 20:20 | <iliakan> | (or just not important enough), but eventually will be supported |
| 20:20 | <SteveF_> | TabAtkins: thanks |
| 20:22 | <annevk> | iliakan: ify ou look at the open bugs against dom.spec.whatwg.org you'll find something similar |
| 20:24 | <annevk> | Ooh, there's been movement there: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23202 Guess I should look into that tomorrow |
| 20:44 | <annevk> | Ended up fixing it now... |
| 20:46 | <iliakan> | btw where I can read more about that @unscopable? :) |
| 20:46 | <annevk> | iliakan: http://people.mozilla.org/~jorendorff/es6-draft.html |
| 20:53 | <iliakan> | annevk: thanks |
| 20:55 | <zcorpan> | annevk: does remove() need it? |
| 21:08 | <annevk> | zcorpan: we have at least one case that we broke |
| 21:08 | <zcorpan> | annevk: ok |
| 21:21 | <JonathanNeal> | rwaldron: would you link me to the published tc39 notes? not sure where to find them. |
| 21:22 | <Domenic> | JonathanNeal: github.com/tc39 |
| 21:24 | <JonathanNeal> | Domenic: thanks! |
| 21:39 | <TabAtkins> | Domenic: What happens right now if two consumers both call .read() on a stream? |
| 21:39 | <Domenic> | TabAtkins: they each get a chunk (assuming two chunks are available) |
| 21:40 | <TabAtkins> | Oh, each .read() call consumes one chunk? Gotcha. |
| 21:40 | TabAtkins | is trying to bootstrap enough Streams knowledge to help out. |
| 21:40 | <Domenic> | ^_^ |
| 21:43 | <TabAtkins> | In that case, I'm leaning toward some form of special-casing piping being the best - piping is a fundamentally different sort of reading behavior that implicitly lays claim to all chunks until the piping stops. |
| 21:45 | <TabAtkins> | It changes the stream into a push model, no? |
| 21:45 | <Domenic> | Yeah, I was leaning toward that until 5 minutes ago when I remembered that httpRequest.json() also wants exclusive access to the body stream (i.e. httpRequest.body.read() should probably not work) |
| 21:45 | <TabAtkins> | Right. |
| 21:45 | <TabAtkins> | .json() is definitely a pipe consumer that only emits a single output chunk, once it's finished reading all the input chunks. |
| 21:45 | <Domenic> | Hmm just saying those words does make it sound better... |
| 21:46 | <Domenic> | It felt a bit awkard to say ".json() must use pipe" even though the destination stream is kinda synthetic |
| 21:46 | <Domenic> | But saying ".json() is a pipe consumer" is nice. |
| 21:47 | <TabAtkins> | Yeah, the API of JSON hides the stream-ness from you, so you don't have to call .read() yourself, but it's still there under the covers. |
| 21:48 | <TabAtkins> | A "spread pipe" that can be read by multiple consumers is just a pipe consumer that then acts more like a normal stream again. |
| 21:53 | <TabAtkins> | Is it super-important that .state/etc not be accessible to anyone but the pipe target? |
| 21:53 | <TabAtkins> | I presume it is, so that impls can optimize simple cases and do everything in the C++ layer? |
| 21:55 | <Domenic> | Yeah. I'm unsure about .state and .ready but yukata seems to think they should also be censored |
| 21:55 | <Domenic> | You could get away with censoring them instead of making them throw I think |
| 21:55 | <Domenic> | e.g. always return "waiting" |
| 21:56 | <TabAtkins> | Yeah. Does the pipe consumer need them? |
| 21:56 | <Domenic> | what do you mean? |
| 21:56 | <TabAtkins> | I'm implementing .json(). I need access to .read() from the pipe, but do I need .state from it? |
| 21:57 | <Domenic> | ah, yeah, you need all three |
| 21:58 | <Domenic> | the other two tell you when to call .read() |
| 21:58 | <TabAtkins> | Okay, so even if you censor them on the stream, you still need some way for the pipe-holder to get at it. |
| 21:58 | <Domenic> | right |
| 21:59 | <Domenic> | we could either make readableStream.pipeTo(dest) use its internal powers to access internal state |
| 21:59 | <Domenic> | or we could introduce a StreamReader-type object that has access to the internal state, and give that only to the consumer. |
| 21:59 | <Domenic> | The latter allows people to create their own pipeTo-like abstractions |
| 21:59 | <Domenic> | e.g. .json() |
| 22:00 | <Domenic> | whereas the former requires implementing .json() in terms of .pipeTo() in order to reuse its internal powers |
| 22:01 | <TabAtkins> | I'm actually liking the "duplicate the API on ExclusiveReadableStream". That's basically your "crazy idea", but with convenience API on the Stream itself for when you're not doing anything fancy. |
| 22:01 | <Domenic> | hmm |
| 22:02 | <Domenic> | i guess it might be nicer for consumers |
| 22:02 | <Domenic> | authors, i mean |
| 22:02 | <Domenic> | even if it makes me uncomfortable |
| 22:02 | <TabAtkins> | Rephrased: Per your crazy idea, make Streams solely a piping object, with a ReadableFoo object that can consume it and manually expose the stream data. Then duplicate the ReadableFoo API back onto Stream for convenience. |
| 22:02 | <Domenic> | heh, yeah, that's one way to look at it |
| 22:03 | <TabAtkins> | The convenience API would use internal state to shut itself off if the Stream ever starts piping for real. |
| 22:03 | <TabAtkins> | (Including to a manually-created ReadableFoo object.) |
| 22:03 | <Domenic> | yepyep: https://github.com/whatwg/streams/blob/lock/reference-implementation/lib/experimental/exclusive-stream-reader.js#L132-L152 |
| 22:03 | <TabAtkins> | Need to think about how that would affect mikeal's "I override .read() a lot" case. |
| 22:04 | <TabAtkins> | Maybe you'd just override .pipeTo()? Dunno. |
| 22:04 | <Domenic> | You'd have to override getExclusiveReader() in my current design |
| 22:05 | <Domenic> | I had another design that relied on weakmap and try { .. } finally { } hackery to be less code for implementers |
| 22:05 | <Domenic> | https://gist.github.com/domenic/d421643d95cdec9a9b5b#file-readable-stream-locks-2-md |
| 22:05 | <Domenic> | predates me realizing that .ready and .state were also important, but the general idea is there |
| 22:06 | <Domenic> | it works with anything with a .read() method (and presumably anything with .ready/.state too) |
| 22:07 | <TabAtkins> | Remind me how foo.pipeTo(bar) works on the bar side? How does bar respond to that? |
| 22:08 | <Domenic> | it doesn't right now |
| 22:08 | <Domenic> | pipeTo just calls bar.write(chunk) a lot |
| 22:08 | <Domenic> | at appropriate times which it figures out by paying attention to backpressure |
| 22:08 | <TabAtkins> | Oh, kk. So I was right that piping turns the stream into a push structure rather than pull. Cool. |
| 22:09 | <Domenic> | i'm not sure i would phrase it that way though |
| 22:09 | <Domenic> | what if foo.pipeTo(bar) just called bar.pipeFrom(foo) |
| 22:09 | <Domenic> | and i moved the algorithm over to WritableStream.prototype.pipeFrom |
| 22:09 | <Domenic> | would you then call it pull? |
| 22:09 | <TabAtkins> | Yeah, that's possible, and maintains the pull nature. |
| 22:09 | <TabAtkins> | Yeah, because "bar" is then the one dictating when things write, not "foo" |
| 22:10 | <TabAtkins> | Question is which end fo the pipe data pools at when you're not doing anything explicit. |
| 22:10 | <TabAtkins> | At the source end, it's pull. At the target end, it's push. |
| 22:10 | <TabAtkins> | The target may itself then still be a pull stream, buffering all the data beign pushed into it. |
| 22:10 | <Domenic> | it's really neither that is dictating; it's the pipeTo algorithm. Which since it only uses public APIs (for now), could live anywhere |
| 22:10 | <TabAtkins> | (And using backpressure to force upstream to buffer instead.) |
| 22:11 | <TabAtkins> | Yeah, the algorithm matters. This isn't an intrinsic property of the producer/consumer relationship, it's a property of the exact way they communicate. |
| 22:11 | <Domenic> | right |
| 22:11 | <Domenic> | I am 90% sure the current algorithm pools at the source |
| 22:12 | <TabAtkins> | Well, it doesn't if foo.pipeTo(bar) calls bar.write(data) a lot (rather than bar calling foo.read() a lot) |
| 22:12 | <Domenic> | it calls both, sorry :P |
| 22:13 | <Domenic> | i was answering specifically "how it works on the bar side" |
| 22:13 | <TabAtkins> | man what |
| 22:13 | <TabAtkins> | Okay, gonna read some of this and get back to you. |
| 22:13 | <Domenic> | https://github.com/whatwg/streams/blob/master/reference-implementation/lib/readable-stream.js#L88-L159 |
| 22:14 | <Domenic> | basically pipeTo is a loop that does `var chunk = source.read(); dest.write(chunk);` a lot |
| 22:14 | <Domenic> | except it only does that when source has stuff to read and chunk is not signalling backpressure |
| 22:14 | <Domenic> | and also it handles errors |
| 22:16 | <TabAtkins> | Yeah, I'm confused about what structures are reified here and in what way. Also: I'm hungry. Gonna grab lunch and think about this a bit. |
| 22:16 | <zcorpan> | http://www.w3.org/mid/BY2SR01MB608C5CB8B8C2BDE0432255F9B730⊙Bnsec seems useful |