| 07:10 | <annevk> | rniwa: could you comment on https://github.com/whatwg/dom/pull/336 please? |
| 07:31 | <KiChjang> | oh, this is interesting |
| 07:31 | <KiChjang> | i always thought react's virtual DOM is something that they use on the standards |
| 07:32 | <KiChjang> | which brings up a question: should web standards support this virtual DOM concept in some way? |
| 07:33 | <annevk> | KiChjang: some parts of it might make sense to standardize |
| 07:34 | <annevk> | KiChjang: e.g., the patch format: https://github.com/whatwg/dom/issues/270 |
| 07:34 | <KiChjang> | yeah, that's what i was thinking |
| 07:34 | <KiChjang> | the diff thing is quite intriguing |
| 12:49 | <annevk> | jgraham_: you need async_test even when the events are sync, right? |
| 12:50 | <jgraham_> | annevk: You need async_test when the js stack is reset (whatever the word is), approximately |
| 12:50 | <annevk> | it's not reset really, it's just nesting |
| 12:51 | <annevk> | but I'm gonna take that as a yes |
| 12:52 | <jgraham> | I guess a more precise answer is whenever you want to assert somewhere that won't allow the stack to unwind up to the test() function |
| 12:52 | <jgraham> | when an exception is thrown |
| 12:53 | <annevk> | right, whenever "report an exception" is used, that makes sense |
| 13:00 | <annevk> | ta |
| 13:07 | <Domenic> | aghh no rniwa and no botie |
| 13:09 | <MikeSmith> | Domenic: hang on will get botie back |
| 13:10 | <MikeSmith> | voila |
| 13:33 | <Domenic> | \o/ |
| 13:33 | <Domenic> | botie: tell rniwa did you see my response to https://github.com/w3c/DOM-Parsing/issues/22 ? I'm not sure I got it right and would love your thoughts. |
| 13:33 | <botie> | will do |
| 13:50 | <Ms2ger> | Is Path2D intentionally still exposed in workers? |
| 13:54 | <Domenic> | Probably, given OffscreenCanvas |
| 13:55 | <annevk> | I think at the moment it's probably a mistake |
| 13:55 | <annevk> | Ms2ger: might be a good question for the OffscreenCanvas patch |
| 13:56 | <Domenic> | Yeah I guess maybe it should have been un-exposed during the interim between CanvasProxy and OffscreenCanvas |
| 13:56 | <annevk> | CanvasPath is also exposed |
| 13:57 | <annevk> | <canvas> IDL would really benefit from mixin annotation |
| 13:57 | <annevk> | NoInterfaceObject mess it has today is rather sad |
| 13:58 | <Domenic> | I'm a little worried that ES might end up defining mixins differently |
| 13:58 | <Domenic> | There's a pattern Dart and Ruby use where mixins create a class hierarchy |
| 13:59 | <Domenic> | And if Web IDL uses "mixin" as a word and then later ES uses it for something different, that's not great. |
| 13:59 | <Domenic> | On the other hand ES might be constrained since "mixin" is not a keyword currently |
| 13:59 | <Domenic> | It might have to use e.g. "mixin class" or something. |
| 13:59 | <Domenic> | Alternately Web IDL could use a more esoteric word |
| 13:59 | <annevk> | I'm happy to use a different word in IDL |
| 14:00 | <Ms2ger> | Maybe ES should look at the DOM in some other way than "our stuff should be as far removed from that as possible", just this once |
| 14:00 | <annevk> | IDL could call them "addon" |
| 14:01 | <annevk> | Ms2ger: what we have isn't really a language feature or exposed in any way |
| 14:02 | <annevk> | Ms2ger: so if they see value in some kind of mixin that is exposed in some way they should feel free to innovate a little bit there I think |
| 14:02 | <annevk> | Ms2ger: what we have is rather magical too in that it adds both public and private state to a class |
| 14:03 | <Domenic> | Yeah the thing is it's already easy to do the IDL/DOM pattern in ES (modulo magic private state business) |
| 14:03 | <Domenic> | Object.assign(X.prototype, Y.prototype) |
| 14:03 | <Domenic> | basically |
| 14:03 | <annevk> | internal slots \o/ |
| 14:03 | <Domenic> | No need for a syntactic pattern |
| 14:03 | <Domenic> | So if ES is going to have a first-class pattern with syntax, it'd do something more useful than that |
| 14:04 | <Domenic> | And Ruby and Dart and others (apparently both are based on an academic paper) have shown one path that people like |
| 14:04 | <annevk> | I've been using mixin in prose here and there, but that's easily fixed |
| 14:06 | <Domenic> | Yeah it's a good word, I'm kind of loathe to lose it |
| 14:07 | <Domenic> | Might be worth having a small discussion at next TC39 about whether they see a potential keyword conflict in the future |
| 14:07 | <Domenic> | If ES has "mixin classes" and IDL has "mixins" that'd work OK for me |
| 14:22 | <jgraham> | I don't suppose there's some way to just get a tarball of chrom[e|ium] e.g. canary is there? |
| 14:22 | <jgraham> | Rather than a deb or whatever |
| 14:26 | <MikeSmith> | jgraham: http://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html maybe |
| 14:26 | <MikeSmith> | though you have to wait for it load, and it loads slow |
| 14:26 | <MikeSmith> | http://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Linux_x64/ |
| 14:27 | <MikeSmith> | and you have to scroll to the bottom and the scroll control is conveniently a disappearing one |
| 14:29 | <jgraham> | OK, that seems like a thing to experiment with |
| 14:29 | <jgraham> | Thanks |
| 14:30 | <MikeSmith> | http://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Linux_x64/425016/ seems to be the current latest |
| 14:32 | <MikeSmith> | jgraham: it seems the only way to know what subdir/path to get it from is to look in https://www.googleapis.com/download/storage/v1/b/chromium-browser-snapshots/o/Linux_x64%2FLAST_CHANGE?generation=1476368813774000&alt=media |
| 14:36 | <annevk> | jgraham: https://github.com/w3c/web-platform-tests/pull/1381#issuecomment-222450124 |
| 14:37 | <jgraham> | annevk: sure, put it somewhere obvious maybe with a README |
| 14:38 | <annevk> | jgraham: you mean the current place is no good? |
| 14:38 | <annevk> | jgraham: I can add a comment at the top |
| 14:41 | annevk | adds a comment at the top |
| 14:41 | <jgraham> | annevk: I guess with a comment I don't have a strong opinion |
| 14:42 | <annevk> | almost nearing 2 years that PR |
| 14:42 | <annevk> | about time it lands |
| 17:18 | <annevk> | wanderview: I think you might be missing that sendBeacon() doesn't take Request objects, but maybe I'm missing something obvious |
| 17:18 | <wanderview> | annevk: ok... why are we exposing a keepalive attr on Request then? |
| 17:19 | <annevk> | wanderview: so you can do sendBeacon()-like things with fetch() and more? |
| 17:19 | <annevk> | wanderview: it's a more powerful replacement, effectively |
| 17:20 | <wanderview> | annevk: ok, back up... does "keepalive" mean keeping the Request object alive beyond the JS context? thats what the title of the PR and spec text changes imply |
| 17:20 | <annevk> | wanderview: it means keeping the fetch alive, sure |
| 17:20 | <annevk> | wanderview: can't really keep the object around that long if its environment is gone out of the window |
| 17:20 | <wanderview> | annevk: what is "the fetch"? the PR references "Request"... capital R implies the JS object to me |
| 17:21 | <annevk> | wanderview: I wouldn't pay attention to the title of the PR |
| 17:21 | <wanderview> | annevk: is this really saying don't cancel a fetch when the document goes away? |
| 17:21 | <annevk> | wanderview: yes |
| 17:24 | <wanderview> | annevk: well, the spec text in the PR also says "This can be used to allow the request to outlive the environment settings object"... which doesn't necessarily mean an ongoing fetch operation... but ok |
| 17:24 | <annevk> | wanderview: we could clarify the non-normative text, prolly best to open a new issue for that |
| 17:25 | <annevk> | wanderview: though it's also about requests of course, that's one part of a fetch |
| 17:26 | <wanderview> | I think tying the cancelation of the operation to the life of the request object is confusing to me |
| 17:26 | <wanderview> | and probably what I missed here |
| 17:26 | <annevk> | wanderview: the Request object isn't really involved with that, but the request is to some extent |
| 17:27 | <annevk> | wanderview: keepalive on Request is just some input for the eventual request |
| 17:30 | <wanderview> | ok, thanks |
| 17:32 | <JakeA> | If I'm inserting some JSON.stringified text into a <script>, is there anything else I need to escape, other than </script>? |
| 17:57 | <TabAtkins> | JakeA: Jake are you building pages via string concatenation again? Your mother and I raised you better than that, use a real DOM please. |
| 17:58 | <JakeA> | :D |
| 17:58 | <JakeA> | TabAtkins: I'm wanting to embed some JSON from the server for the JS to pick up when it runs |
| 17:59 | <JakeA> | might be safest to stick it in a data-attribute, since HTML escaping is covered |
| 17:59 | <TabAtkins> | Yes. |