01:49
<sideshowbarker>
sideshowbarker: version 3.0.4 published
Thanks much — that got me past the previous errors I was having with the Secure Context spec
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
but you need to know that the second throw is supported, right? ☹️
11:17
<Sam Sneddon [:gsnedders]>
(but more seriously this is a long-running thread: https://github.com/heycam/webidl/issues/107 )
oh hey apparently I already thumbed up that! 😆
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).
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.
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.
There is a long-standing HTML issue about making this better, so nothing very good. I have been doing the following handwaving: https://wicg.github.io/app-history/#finalize-with-an-aborted-navigation-error step 4
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 thenable like interop with AbortSignal implementing that (doesn't have to be Ron's protocol exactly) so that the language can provide syntactic assist.

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 thenables, 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 thenables 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 then like cancellation protocol proposal the web would be stuck with two similar but slightly different APIs and if it's like promises the API we'd end up with eventually is the language level one (i.e. CancelToken) with AbortSignal being eventually side-stepped and that API would be much harder to iterate or work on because the language moves slowly + it'd be confusing to developers?

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 EventTarget people have are still a big deal - EventTarget was a big part of the pushback against AbortSignal but now it seems all the platforms have it.

I am still not sure about composability (unfortunately I feel kind of stuck but we do need a .follow or a new AbortSignal(...signals) or similar API). It's also possible to iterate on EventTarget to add capabilities (like weak listeners) to enable it to compose.

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,
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
You’re right. To fix that, you could raise a PR at https://github.com/whatwg/html/ with patch the removes that reference.
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.