T?
>
> Best,
>
> Alex
>
> On Mon, Jun 24, 2024, 1:47 PM 'Francis McCabe' via blink-dev <
> blin...@chromium.org> wrote:
>
>> I am 'ok' with a shorter extension. I asked for 6 months because I
>> foresee a reasonable risk of needing
I am 'ok' with a shorter extension. I asked for 6 months because I foresee
a reasonable risk of needing more than 3 milestones.
I am not 'ok' with shipping without the imprimatur of progress in the
standardization. We recently did ship a phase 3 standard -- exceptions --
that turned out to be a
I can live with that. However, the bureaucracy is overwhelming. To get an
extension, the documentation I saw stated that I have to create a new OT.
On Tuesday, February 20, 2024 at 10:02:44 AM UTC-8 rby...@chromium.org
wrote:
> Sorry I missed this question! No, I did not notice that the entry
In fact, there are several potential partners for evaluating/experimenting
with JSPI: the Google Earth team, Figma, Adobe to name a few. It should be
emphasized that there are no formal agreements in place here; and that the
primary use case for these partners is actually dynamic loading of code
Contact emails...@chromium.org
Explainer
https://github.com/WebAssembly/js-promise-integration/blob/main/proposals/js-promise-integration/Overview.md
Specification
https://github.com/WebAssembly/js-promise-integration/blob/main/proposals/js-promise-integration/Overview.md
Summary
Stack Switchin
Confirming: there is no current plan to modify how extensions would work.
I was alluding to semi-solid thoughts on how a possible wasm-src policy
would work. But, in any case, wasm-unsafe-eval would continue even without
any new wasm-src.
Also, currently, extensions (and only extensions and chro
Note: this was pointed out to me by mkwst@ ...
The scenario is that a web site publishes a script-src policy (without
otherwise mentioning webassembly), not expecting it to enable any wasm
execution. Extending the coverage of script-src would extend the footprint
of files accessible from that d
