(Missing reviewer, punt)

• Decentralized Identifiers - Hadley

(Missing reviewer, punt)

• Web Speech API - Hadley, Travis

Travis: We were curious whether we should move this into incubation or do something else. Will have to read the notes.

ACTION: Travis to follow-up.

• Transform Streams - Sangwhan, Alex, David

Sangwhan: Nothing from me. :-(

Peter: Chrome has a I2S. Note here for Alex to write more feedback.

ACTION: Revisit next week.

• import.meta.url and import.meta - Alex

(Missing reviewer, punt)

(Missing reviewers, punt)

Alex: There's a graph of resources you want to request off the network. May or may not be traversable. Want to load them as modules (with appropriate request parameters). This is about preloading a graph of requested resources as opposed to a single resource. There was a conversation about whether this makes sense to expand... e.g., grabbing @imports or fonts from a style sheet... but don't necessarily want to grab the fonts. modulepreload sort of hints in that direction; not sure where we ended up in that conversation.

Travis: specific to module scripts?

Alex: modules of all sorts... there are puns with other features.

Andrew: The main motivation for modulepreload was that due... you mentioned the dependency thing... CSS has same situation (e.g., dependencies via @imports); that's the thing we were waiting for feedback on. Anne also commented about fetch not doing recursive fetch; this isn't something you can easily layer in; not usre how to explain it.

Andrew: Theres' difficiltlty in the nuance of the semantics here. We were unconvinced it needed a different name from preload. If the difference is that it traverses dependency tree, maybe deeppreload or recursivepreload; modulepreload seems targeted towards a single use case.

Travis: That's the first thing I tripped over as well.

Travis: Does fetch get involved.. like a service worker... for the preload contents.

Alex: You sholud receive the fetch event. You want the SW to get an early start at handing back those resources if they were in cache.

Travis: And a preload request would get them naturally if they were as well.

Travis: And this would be useful for HTML modules down the road.

Alex: That's the idea. I can write something back to Anne.

Travis: Definitely.

[ Alex leaves ]

Bumped for the 18th, need Travis' feedback

Travis: looked at the updated explainer--seemed an improvement over the last one.

Travis: satisified with Domenic's response on diff between it and import maps.

David: Good topic to try and close out at F2F?

Sangwhan: I think we can close this?

Tess: We've been waiting to hear back since early 2019... coming up on a year pending feedback. Don't think we should keep it open indefinitely.

Sangwhan: That's my take as well.

David: I think that's reasonable. Do we want to express any opinion on the issue before we close it?

Sanwhan: We should report the two feature requests somewhere.

... I filed a comment asking where to file the two feature requests.

Alice: I also filed an issue on our process repo about what to do in cases like this.

David: I think maybe an issue against fetch, and an issue against HTML.

All: this issue has been open since 2017. Yikes.

David: Has this shipped in Chrome?

Tess: since Chrome 66

David: Recursive fetching makes sense if you have a type-specific API, but a fetching API for fetching a generic resource doesn't feel like recursive fetching makes sense, really.

Peter: Can you do preload off HTTP headers? Or rather modulepreload...

David: I think so?

... Seems like we may as well close this... if we'd filed feedback sooner it might have been useful, but at this stage it seems unlikely to be so.

Rossen: Should we wait for the WHATWG issue to be resolved?

David: Might be a moot point at this point.

Rossen: Close?

Peter: Yep, let's tentatively close and confirm at the plenary.

David: I'll write a comment