01:49 | <sideshowbarker> | sideshowbarker: version 3.0.4 published |
01:49 | <sideshowbarker> | …but now having new errors: https://github.com/w3c/webappsec-secure-contexts/runs/3582240315?check_suite_focus=true#step:3:607 |
01:49 | <sideshowbarker> | Copyright string does not match requirements |
01:50 | sideshowbarker | now tries to figure out from the the Copyright text is generated |
01:50 | sideshowbarker | finds bikeshed/boilerplate/webappsec/copyright.include |
01:54 | <TabAtkins> | Sigh, so many undocumented changes |
02:32 | <sideshowbarker> | TabAtkins: r? https://github.com/tabatkins/bikeshed/pull/2138 (with those changes, I can get a locally-generated CRD of Secure Contexts to pass pubrules/specberus) |
06:26 | <annevk> | tusf: it's a tree. Not aware of articles, but in the early days linked list vs array for representing children was a topic. |
06:52 | <annevk> | Jake Archibald: re https://github.com/WICG/app-history/issues/167; what about the example I gave is not possible? I.e., you have a sandboxed document that can execute script. It creates a blob URL and navigates to that. How are those not two documents that are same-origin? |
07:37 | <Jake Archibald> | annevk ah, I missed your reference to blob URLs there |
11:17 | <Sam Sneddon [:gsnedders]> | The second throw prevents the method from going through in browsers that don't support the API |
11:17 | <Sam Sneddon [:gsnedders]> | (but more seriously this is a long-running thread: https://github.com/heycam/webidl/issues/107 ) |
15:30 | <jgraham> | So if, in a spec, I have an exception and want to create a stack trace, what kind of handwaving do these days? I assume that js still pretends that's not a thing. |
15:37 | <Benjamin Gruenbaum> | Domenic: what would you think it would take for you to support a CancelToken like proposal (as in you personally - not as in Chrome/WHATWG or anyone else)? I'm asking because you have the most experience thinking about this problem (maybe Petka or Kris too? IDK). |
15:45 | <Benjamin Gruenbaum> | (Mainly interested because I'd love language-level sugar) |
15:52 | <Domenic> | Domenic: what would you think it would take for you to support a CancelToken like proposal (as in you personally - not as in Chrome/WHATWG or anyone else)? I'm asking because you have the most experience thinking about this problem (maybe Petka or Kris too? IDK). |
15:53 | <Domenic> | So if, in a spec, I have an exception and want to create a stack trace, what kind of handwaving do these days? I assume that js still pretends that's not a thing. |
15:59 | <Benjamin Gruenbaum> | I think it would be net harmful for there to be a protocol now that we have a cross-environment standard object. So I can't really think of anything. Syntax-level support for AbortSignal would be nice but it should be through host hooks not through a protocol that allows a proliferation of different types. Hey, thanks for the super-quick reply. I'm wondering if there can still be a What would host-hooks look like? If that gives the capability for language-level syntax support and debugging help that would totally address the things I care about (similarly to async/await being easy to debug compared to raw-promises because of browser tooling) |
16:00 | <Domenic> | I think the then protocol was a bit of a mistake; it wasn't as useful for the transition as anticipated, and in the long term it isn't good to have different thenables in the ecosystem at all. I strongly believe we should not do a general protocol for new things like AbortSignal; instead everyone should use and collaborate on the single thing (i.e. AbortSignal). |
16:02 | <Domenic> | Host hooks would look like: HostAddAbortListener(signal, listener), which the DOM spec would define to use "add an abort algorithm" in web browsers/Node/Deno/etc. Then the ES spec could call HostAddAbortListener whenever it gets an AbortSignal from a developer and wants to add some abort steps. |
16:02 | <Domenic> | So for example that would easily allow you to add AbortSignal support to import() |
16:03 | <Domenic> | For syntax-level support it depends on what you mean. So far I have seen no real proposals for syntactic aborting that people generally agree as being workable or good. But if they use AbortSignal then some kind of host hook to abstract over AbortSignal vs. theoretical other-host cancel tokens would be fine. |
16:05 | <Domenic> | https://github.com/tc39/proposal-cancelable-promises/blob/0e769fda8e16bff0feffe964fddc43dcd86668ba/Cancel%20Tokens.md#advanced-usage-within-async-functions-awaitcanceltoken was my idea back in the day but nobody liked it in committee and I haven't seen a lot of demand for it since. So, shrug. |
16:08 | <Benjamin Gruenbaum> | Yeah I remember that proposal - if you recall I was very much in favour and I think not having third-state cancellation (except in like 2-3 places but don't tell anyone about generators!) is one of the biggest mistakes in the (modern) language IMO. |
16:09 | <Benjamin Gruenbaum> | I tend to agree about then ables, I've added a "consider native promises" banner to bluebird ±3 years ago - hopefully it's slowly dying soon. I still can't wrap my head around twilio using the Q V2 beta in production :D |
16:11 | <Benjamin Gruenbaum> | And while mistakes were made around promises I think we can agree the value they brought to the language and the web ecosystem was/is tremendous and stuff like then ables and subclassable promises is somewhat unfortunate but negligible compared to the time saved. |
16:14 | <Benjamin Gruenbaum> | So if I understand correctly a possible concern is that if we have a With hooks on the other hand you'd still have the one API (AbortSignal) and we'd be able to iterate on it effectively in WHATWG and not TC39. |
16:15 | <jgraham> | Domenic: Thanks, that's a useful reference point. |
16:17 | <Benjamin Gruenbaum> | On a fun tangent - I recalled https://github.com/tc39/proposal-cancelable-promises/issues/14#issuecomment-227671239 when non-third-state cancellation woke me up a few weeks ago ^^ |
16:18 | <Domenic> | Benjamin Gruenbaum: the concern is a bit different than that. The core goal is that we should have exactly one cancel token primitive. 2 (AbortSignal + whatever TC39 comes up with) is bad. But N (AbortSignal + a bunch of userland stuff using Symbol.cancelToken) is also bad. |
16:19 | <Domenic> | Benjamin Gruenbaum: also it's just frustrating wasted effort that these people are busy fighting a turf war to get cancel tokens over in TC39 instead of working (like you!) to improve AbortSignal, which benefits all the same consumers (web, Node, Deno, anyone else who implements it, ...) |
16:23 | <Benjamin Gruenbaum> | Interesting, good points. I'm wondering if the concerns about I am still not sure about composability (unfortunately I feel kind of stuck but we do need a |
16:24 | <Benjamin Gruenbaum> | I think I am mostly convinced that host-hooks are a viable way forward without most of the downsides. Thanks! |
16:36 | <Marc Wensauer> | Here is suggested to use document.execCommand() API, https://html.spec.whatwg.org/multipage/interaction.html#editing-2 There shoudl be a note that it was deprecated https://developer.mozilla.org/en-US/docs/Web/API/Document/execCommand |
16:39 | <sideshowbarker> | Here is suggested to use document.execCommand() API, |
16:39 | <sideshowbarker> | or I can if you want |
16:39 | <Marc Wensauer> | 👍️ |
16:39 | <Marc Wensauer> | yeh please do |
16:39 | <sideshowbarker> | OK will do it right now |
16:40 | <Marc Wensauer> | perfect thank you you very much |
16:40 | <sideshowbarker> | cheers |
17:09 | <sideshowbarker> | Marc Wensauer: https://github.com/whatwg/html/pull/7064 |
17:09 | <sideshowbarker> | I guess it’s unlikely that PR will be merged |
17:11 | <sideshowbarker> | but regardless of whether it is not, we won’t be un-deprecating it in MDN — because what MDN has is consistent with what the execCommand spec itself says |
21:16 | <muffinkiller> | I think the process likt good and that in pattern, likt OP slicer ways from een 3d prindenter File. Lease Wait with Push of pull. The System is so massiv better then Yesterday. |