WHATWG
2023-04-28
plaintext logs
prev next
source on github
05:28
<annevk>
jugglinmike: maybe share it here first? I don't really see how that thread won't continue to generate noise if we reopen it
05:28
<annevk>
And it's not like we really govern file: fetching to begin with, it's pretty explicitly undefined
06:10
<Domenic>
annevk: any further thoughts on naming for https://github.com/WICG/navigation-api/issues/225#issuecomment-1527039396 ? sourceElement vs. triggerElement vs. triggeringElement is my current set of favorites.
06:42
<annevk>
Domenic: I added my not-naming thoughts from the offline conversation, but also commented on naming
11:06
<sideshowbarker>
Does the Chromium project have a position on Audio Session?
13:12
<Dominic Farolino>
In spec land, is it possible to call a callback with an infra struct, as opposed to a [=new=] WebIDL object, and have WebIDL [=convert=] that to an appropriate ES object for consumption by JS? Or do you actually have to pass in a [=new=]ly constructed WebIDL interface, since WebIDL only knows how to convert those to appropriate ES objects?
13:15
<Domenic>
In spec land, is it possible to call a callback with an infra struct, as opposed to a [=new=] WebIDL object, and have WebIDL [=convert=] that to an appropriate ES object for consumption by JS? Or do you actually have to pass in a [=new=]ly constructed WebIDL interface, since WebIDL only knows how to convert those to appropriate ES objects?
You are supposed to call a callback with a Web IDL object, which could be an infra map representing a dictionary, but if it's an interface you want, yeah there's no way to get an interface without [=new=]ing one.
13:17
<Dominic Farolino>
Thanks, I think in the spec I'm reviewing passing an infra map should suffice, provided the values are mutable (JS can change them and we can read them after the callback is done) though I'm not sure how common that pattern is
13:30
<Domenic>
The values are not mutable; the conversion process performs a copy when constructing the ES object, and you do not have a handle to that ES object
13:31
<Dominic Farolino>
OK that makes sense.
13:31
<Domenic>
If you get an arbitrary ES object back, you can try to convert it to a dictionary (or record) again, and that will handle all the pathological cases like what if the author installed a throwing getter on a property you care about or some property with the wrong type value or similar
13:35
<Dominic Farolino>
"get an arbitrary ES object back" > what mechanism would I get one back by, something like a callback that lets the user invoke a function with a dictionary of populated values?
13:39
<Dominic Farolino>
Can you even pass a callback fn (for JS to invoke) as an argument to a callback fn (that specs invoke to run JS)?
13:39
<Domenic>
I mean I don't know, I thought you were reviewing an existing API. What does code that uses the existing API look like/how is it supposed to work?
13:40
<Domenic>
(Like, example JS code)
13:44
<Dominic Farolino>

New spec/new API. It's not pretty, I'm trying to land on something sensible.

function generateBid(foo, bar, baz) { // This will get invoked by the browser
  const bidValue = [compute a value based on foo/bar/baz];
  setBid(bidValue);

  const priorityValue = [compute priority based on foo/bar/baz];
  setPriority(priorityValue);
}

Caveat is: setBid and setPriority functions should only ever exist inside that generateBid() user-supplied fn

13:45
<Dominic Farolino>
So I'd like to pass in a setBid() and setPriority() function directly as an argument alongside foo/bar/baz, so that those fns can literally only be called inside generateBid()
13:45
<Dominic Farolino>
But I'm not sure how to pass in "a function that does THIS" (called setBid()), and so on.
13:45
<Dominic Farolino>
Personally I'd like to pass (to generateBid()) in an interface that has a setBid() and setPriority() methods
13:45
<Domenic>
Got it. You can do that either with callback functions, or if you want to put those two callback functions on an interface that would also work.
13:46
<Domenic>
To create callback functions that have specific behavior, let me find an example...
13:46
<Dominic Farolino>
Yeah that's what I've been looking for on WebDex but I only see them go the other way: callbacks that JS passes into spec code, that specs invoke later
13:47
<Domenic>
Pretty sure onxyz's are an example
13:47
<Domenic>
Yeah. It's not pretty, you manually construct a JS Function object and then wrap it. https://html.spec.whatwg.org/#getting-the-current-value-of-the-event-handler
13:48
<Domenic>
Steps 3.8-12
13:48
<Domenic>
Step 3.11 is probably not necessary in your case
13:49
<Dominic Farolino>
I agree with all of that. Thanks a lot for the example, it is exactly as I feared :)
13:49
<Dominic Farolino>
interface with methods would be much nicer
13:49
<Domenic>
But creating an interface might be easier and perhaps nicer for authors, as a signature of (foo, bar, baz, setBid, setPriority) feels a bit more confusing than (foo, bar, baz, controller) or ([foo, bar, baz], controller)
13:49
<Dominic Farolino>
I fear that ship has sailed though
13:52
<Domenic>
Hmm that example is likely not exactly what you want because OrdinaryFunctionCreate is for parsed source code
13:53
<Domenic>
Ah yeah you want https://tc39.es/ecma262/multipage/ordinary-and-exotic-objects-behaviours.html#sec-createbuiltinfunction
13:53
<Domenic>
As used often in Web IDL
13:56
<Dominic Farolino>
And behavior is just a "set of spec steps" basically, in that case?
13:56
<Dominic Farolino>
Yeah looks like it: https://webidl.spec.whatwg.org/#dfn-perform-steps-once-promise-is-settled