Meeting minutes
Sam: Explainer by Aaron (https://
This is implemented in Edge
I wanted to talk to the Edge team, how it's going and what the feedback from partners was. Also, I wanted to ask if there's general interest to make that a web platform thing.
(Quick introductions)
Bytedance wants to creates widgets in spatial OS
<scheib> Intros
<scheib> One interest in use case is in VR displays
Folks from edge joining who can demo, were around during implementation
Sam: Purpose of the API is to create widgets, and send data to widgets via a Service Worker.
Lu: The API is implemented in Edge. The explainer is more or less in sync with the implementation.
(Widget demo)
In Windows, there's a widgets view. Normally, you can add new widgets through the store.
PWA Widgets can also be displayed, and you can control your PWA from the widget.
Sam: It also has Periodic Background Sync specified.
Any feedback from partners that implemented this?
Lu: Facebook was the main partner, it's been around for a while.
Sam: Want to open the floor - deep-dive into the explainer, should we push this to WebApps, why are people interested?
<diekus> https://
diekus: We were discussing this similar proposal a while ago.
But we didn't get the necessary support.
But, there's applications that need similar things, for example, the OneDrive app that opens a web UI when clicking on its system status icon.
That received more support, so it may make sense to pursue this approach.
dmurph: So would this be a separate thing?
diekus: Widgets would probably be separate, but you could certainly use the companion structure for them as well.
Snugug: What do people think about widgets?
diekus: I’m here to support! Remember, Windows restricted the potential widgets to a certain format.
Snugug: There are two ways in the Explainer, the OS-templated widget, and the free-form widget.
Would like to start with OS-templated widgets, and then move on to the more free-form ones.
Talked to Android people before this session, and running web-view widgets on an Android phone may have performance implications. So that would have to be taken into account.
dmurph: How static is the current proposal?
Snugug: The current Edge implementation is very Microsoft ActiveCard-specific, but the spec doesn’t define it.
First step of specification could be that we identify 5…10 common use cases
(calendar, etc.)
And then we define whatever the standard calendar object is, and Windows/Android/… can use the platform-specific things to display that info.
Yoshisato: Something that is not clear to me, is this applicable to every platform? Edge only? Or is it regardless of the platform?
Snugug: This explainer is only launched in Edge. The templates that are available are ms-prefixed for Edge
It’s done so that it can be flexible per OS
On Android we would have to do some work to make this available, and on macOS as well
For me the goal for this would be not to have an ms-calendar, android-calendar, but only "calendar"
And then you only fill in the template—basic configuration that gets most of the developers most of the way there
That’s my proposal for a potential Rev.0
Lu: Worried about how developers can do customization, it’s possible in Edge right now
Snugug: Correct, due to the use of ActiveCards, but I would like to make it more generic to make it available on other platform as well
Lu: Like that, but how can we make this "developer-progressive"—next steps?
Worried about if it’s too common that it would find adopters
Snugug: It would be good if we could find people to define that set of properties, happy to talk to Office teams or other people
dmurph: Sounds like a great next step, are there risks to this? I don’t see any red flags.
Yoshisato: Are there WPT tests?
Lu: None that I know of
dmurph: Somebody know how easy it is to add it to WPT?
Lu: It’s not that hard.
xiaoqian: Can’t speak for members, but we see a lot of common use cases in combination with the 360 browser, happy to connect you with them. Have you requested a TAG review for it?
Lu: Not sure
xiaoqian: What other APIs are required?
Snugug: Service Workers, Periodic Background Sync
Looking at the sample code, that was the two primary ones
Apart from that, it builds on top of them
dmurph: Did you put any more thought into ???
start_urls, service worker etc.
Kagami: We have a negative standards position on Perodic Background Sync, we are worried about potential tracking when scripts run in the background
Snugug: I’m not sure if Periodic Background Sync is a hard dependency.
The API is used to periodically update the data in the background.
???: Don’t understand why template is enough
On our vision OS, I need to have some layout. Apple uses custom AI.
Within some constraints.
Snugug: That's why I think the template should only be in v0
Think this is a good quick win, as the rest is harder to specify across platforms
And then we extend from there, and provide deeper customization
???: We could parse it and render it on our platform-specific surfaces.
Siyaman: We look at the code in your extension, extract it out and render a native UI.
You could have 3D models, and we can render them in a native application.
dmurph: Is this running in the web view?
Siyaman: Hybrid approach, you can have your model in a web view, or render it outside of it.
Snugug: Android team says that running WebViews in Android would not be an option. So starting like that would hinder broader adoption.
But we do want to get to a point where we get fully customized widgets.
Want to hit the 60…70 percent use case.
Do you have documentation that you can throw on IRC?
Siyaman: Sure.
???: We get material, etc. from the browser and render it natively in visionOS
Snugug: Can see a potential path in defining Web Components and translating that to native code.
Kagami: Discussed this with web widgets as iframes on the "new tab" page, but we don't like untrusted UI in browser UI.
So if you go ahead with this, rather with the v0 option.
<Siyaman> We built https://
Snugug: Quick poll on IRC?
Was this a compelling enough conversation that you think we should bring this to the web platform? (options: yes, ask me later…)
Kagami: why not?
dmurph: seems not bad?
<Yoshisato> sounds reasonable to discuss there.
scheib: Widgets have been come up so many times, they have all failed.
christianliebel: I don't hear this as a thing that developers need. I'm sure they want to do it, but for majority of devs I'm sure it's not so interesting
christianliebel: there might be other more important things to solve
Sam: So it might be a good action item to get feedback from devs.
christianliebel: I think this API is for facebook, pinterest, and that class of application, but maybe not others
Sam: yes, those applications are asking me for this, so yes
christianliebel: Yes it's probably very important for them
<Siyaman> Yes
overall: why not?
Sam: ok, action item for what types of developer might need this, then moving from edge explainer to webapps wg or incubation. Also what types of templates
(and what is missing from the other standards, and this explainer)
(Static/dynamic widgets)