| 05:16 | <hemanth> | Cancelable functions...hrrm...looking for a use case... |
| 12:29 | <annevk> | JakeA: I don't understand why you keep bringing up WindowProxy |
| 12:29 | <annevk> | JakeA: I don't think it is what you think it is |
| 12:32 | <JakeA> | annevk: possibly not. I thought it was one window's insight into another. Like the return from window.open() |
| 12:33 | <annevk> | JakeA: no, it's basically a shield for the Window object (you never actually get to hold the Window object, instead you always have a reference to a WindowProxy object) |
| 12:33 | <annevk> | JakeA: so it's very much unrelated |
| 12:34 | <JakeA> | annevk: but it's the return of window.open, yeah? |
| 12:35 | <JakeA> | annevk: and you can't have them in workers because of threads |
| 12:37 | <jgraham> | window.open() does return a window proxy, as does window or frames[] or iframe.contentWindow, for example |
| 12:42 | <JakeA> | Ahh ok. So I see WindowClient as WindowProxy's worker-safe brother. Obviously it's very limited, and a state snapshot, but that's why I think windowClient.postMessage ends up in window.onmessage |
| 12:50 | <annevk> | JakeA: it's the return value of everything that exposes the Window object, because the Window object is not directly exposed... |
| 12:50 | <annevk> | JakeA: e.g. window.window also returns a WindowProxy |
| 12:54 | <annevk> | JakeA: the analogy doesn't really make much sense to me; window.onmessage and window.postMessage() is for window objects that can directly grab each other; in fact, the window object you invoke postMessage() on gets a message event |
| 12:54 | <annevk> | JakeA: that's completely different from sending messages between a document and a worker, which requires a message channel of sorts |
| 12:56 | <JakeA> | annevk: hm, so it's breaking the model to suggest windowClient.postMessage is a way of posting a message to a window? |
| 12:57 | <annevk> | JakeA: it seems quite different |
| 13:08 | hemanth | is collecting https://github.com/hemanth/coffeescript-equivalents-in-es6 |
| 13:44 | <JakeA> | annevk: spotted a couple of dragdrop bugs, dunno who best to bug about them (or will they just get picked up?) https://bugzilla.mozilla.org/show_bug.cgi?id=1124645 https://bugzilla.mozilla.org/show_bug.cgi?id=1124646 |
| 13:47 | <Ms2ger> | JakeA, fwiw, web-platform bugs almost always go in the Core product |
| 13:48 | <JakeA> | Ms2ger: thanks for updating those! |
| 13:49 | <Ms2ger> | Np |
| 14:02 | hemanth | Are you using packages with vulnerable dependencies? http://nmotw.in/nsp/ |
| 16:08 | <Ms2ger> | Did one of you Googlers try to get me hired? |
| 16:17 | <gsnedders> | Ms2ger: Did someone mistake the Ms2ger AI as being a real person again? :) |
| 16:17 | <Ms2ger> | Apparently |
| 16:24 | <jgraham> | I always assumed that Ms2ger was the Googlebot |
| 16:33 | <hemanth> | :) |
| 17:55 | <Ms2ger> | "there are also several new platform features we are thrilled to be releasing in the next preview:" |
| 17:55 | <Ms2ger> | "DOM L3 XPath" |
| 17:55 | Ms2ger | cries |
| 18:02 | <annevk> | Ms2ger: Microsoft is? |
| 18:03 | <Ms2ger> | Yep |
| 18:03 | <annevk> | o_O |
| 18:03 | <annevk> | I hope they implement the WHATWG edition |
| 18:29 | <jgraham> | Ms2ger: I just came to say the same thing :) |
| 18:57 | <Domenic> | http://glazkov.com/2004/04/06/xpath-unleashed/ |
| 19:00 | <jgraham> | I have always prefered http://glazkov.com/2004/02/22/html-css-and-other-curious-stuff/ |
| 19:01 | <jgraham> | Along with contemporary classics like http://ln.hixie.ch/?start=1042630901&count=1 |
| 19:03 | <Ms2ger> | "We (the CSS working group) sometimes let years pass between releasing drafts of our modules!" |
| 19:03 | <Ms2ger> | Some things never change |
| 19:04 | <TabAtkins> | Well, it would take years before we could release a new draft of our process, so... |
| 19:17 | <jamesr___> | TabAtkins: y'all need a better process process |
| 19:17 | <TabAtkins> | But then it would take years for us to release a new process process draft, so... |
| 19:42 | <Hixie> | man, medium.com is spammy |
| 19:42 | <Hixie> | don't ever post there |
| 21:23 | <TabAtkins> | Is DOM 3 an appropriate spec to reference? Need some place to point a MouseEvent reference to. |
| 21:26 | <Domenic> | That does seem to be the latest place it's found :-/ |
| 21:27 | <Domenic> | TabAtkins: HTML references it. So, probably. |
| 21:27 | <Domenic> | https://html.spec.whatwg.org/multipage/infrastructure.html#mouseevent |
| 21:27 | <TabAtkins> | Cool. |
| 21:27 | <TabAtkins> | Also: AAAAAHHHHH I HATE THE CSS2 SPEC SO MUCH |
| 21:28 | <TabAtkins> | They use, throughout the spec, <span class="index-def" title="margin edge"><a name="margin-edge"><strong>margin edge</strong></a></span> rather than <dfn id="margin-edge">margin edge</dfn> |
| 22:02 | <Domenic> | Interesting. Any good ideas for "innerHTML, but on text nodes"? The idea being that we want to preserve escapes. I guess maybe just htmlescape(textNode.textContent)? |
| 22:03 | <TabAtkins> | Wait, that's the opposite. .innerHTML does *not* preserve escapes, while .textContent does. |
| 22:03 | <TabAtkins> | Or wait, is this on reading or writing? |
| 22:03 | <Domenic> | reading |
| 22:03 | <TabAtkins> | Okay, opposite then. And yeah, just escape things yourself. |
| 22:04 | <gsnedders> | writing you could do container.innerHTML = s.replace("<", ">"); no? |
| 22:04 | <gsnedders> | would that not be safe? |
| 22:04 | <TabAtkins> | gsnedders: Have to replace & first, *then* <. |
| 22:05 | <TabAtkins> | But then you're safe, yes. |
| 22:05 | <gsnedders> | I thought we wanted escapes to be decoded |
| 22:05 | <gsnedders> | idk |
| 22:05 | <TabAtkins> | Domenic: Really, though, you shouldn't be escaping things early like that. Escape at the point of use; that makes it less likely you'll run into double-escaping bugs. |
| 22:06 | <Domenic> | https://github.com/bterlson/ecmarkup/issues/9 is the context |
| 22:06 | <TabAtkins> | And when done consistently (or when done with an API that enforces it), it makes it less likely to run into zero-escapign bugs. |
| 22:06 | <TabAtkins> | Domenic: Yeah, you have to write out an < in the output there, obviously. |
| 22:06 | <TabAtkins> | But do that as you're writing the strings, not when you read them. |
| 22:06 | <Domenic> | we are extracting text nodes and passing them through a tool that outputs HTML. But extracting the text nodes via .textContent doesn't work very well. |
| 22:07 | <Domenic> | (for these purposes) |
| 22:07 | <TabAtkins> | The tool that outputs HTML should be escaping & and < in text. If it's not, it's buggy. |
| 22:07 | <TabAtkins> | Because that's what "outputting HTML" means. |
| 22:08 | <TabAtkins> | (It should similarly escape & and the quote character in attributes.) |
| 22:08 | <TabAtkins> | (If it fills in attribute values from strings at any point.) |
| 22:09 | <Domenic> | Yeah, but currently the tool lets you use HTML tags in your input :-/ |
| 22:09 | <Domenic> | which is a useful feature |
| 22:09 | <Domenic> | but only works by accident |
| 22:09 | <Domenic> | it sounds like maybe i need to make it work on purpose. |
| 22:09 | <TabAtkins> | Sounds like it's very unhygeinic, then, and is currently just letting things escape or not willy-nilly. |
| 22:10 | <TabAtkins> | If it wants to allow <div> as an HTML element, then it needs to distinguish between an input "<" and an input "<". |
| 22:11 | <Domenic> | Yes. Well, the *tool* (Ecmarkdown) does. But the process of figuring out what to feed to the tool is currently using textNode.textContent |
| 22:14 | <TabAtkins> | Okay? textNodes don't contain HTML. I'm confused about the architecture here. :/ |
| 22:14 | <Domenic> | Yes. I just realized I am too. |
| 22:14 | <Domenic> | Maybe the pass-through html doesn't work in the instance where this is occuring. |
| 22:15 | <Domenic> | I will report back! |
| 22:15 | <TabAtkins> | Hahaha, ok. |