Consideration of WebView APIs

[anawhj]

First of all, I try to casually say the definition of WebView which just renders a web page (html) inside native apps. In addition, it could be utilized as a window or frame like concept such as Chrome apps and Electron in which two or three webview elements can be rendered at the same time.

Regarding the second usage of WebView (probably the 1st one as well), we might need to a unified WebView interface (API) as a standard specification. You can refer to the relevant API sets as follows:

• chrome.webviewTag: https://developer.chrome.com/docs/extensions/reference/webviewTag/
• Electron webview API: https://www.electronjs.org/docs/latest/api/webview-tag

The API could take a role of managing a window (e.g. getTitle()) or communicating with the container platform (e.g. openDevTools()).
I wonder we could consider kinds of WebView APIs in this group, though I haven't considered it seriously before and not sure it makes sense or not. :)

[QingAn]

Regarding the second usage of WebView (probably the 1st one as well), we might need to a unified WebView interface (API) as a standard specification

FYI, MiniApp handles it by using JS worker to manage the multiple WebView pages. See here: https://www.w3.org/TR/mini-app-white-paper/#separate-the-view-layer-from-the-logic-layer

[QingAn]

Agree that a unified API handling communication between WebView and the Native can bring benefit.

@anawhj Is it possible that you rewrite the use case using our template? It would be better that the related use case and business scenarios, as well as the benefits and values to WebView vendors, can be further illustrated, which might increase the motivation that WebView vendors consider this possible exploration.