Open NiklasMerz opened 2 years ago
As discussed in 2022-07-06 meeting, it would be helpful to elaborate the detailed different features of WebViews @NiklasMerz
Name | Platforms | Description | Features | Limitations | UX flexibility | Usage Example | State shared |
---|---|---|---|---|---|---|---|
Android Webview | Android | Default WebView implementation on Android | Rich API with JS and CSS interaction, Tie WebView and native APIs together | Features equal to current Chrime but some Web APIs are not supported | Allows you to mix native content with the WebView and to resize it | Hybrid Frameworks (Cordova, Capacitor) | |
Custom Tabs | Android | API for opening browser-like WebViews on Android | Browser navigation and conveniance features like password fill | App has no access to Web content | Covers the entire application with some minimal top bar customization | Link preview in social media apps | |
SFSafariViewController | iOS, iPadOS | API for opening browser-like WebViews on iOS | Browser navigation and conveniance features like password fill | App has no access to Web content | Covers the entire application with some minimal top bar customization | Link preview in social media apps | |
UIWebView (deprecated) | iOS, iPadOS, macOS | Soon-to-be-removed WebView API of iOS | Rich API with JS and CSS interaction, Tie WebView and native APIs together | Some current Web standards not implemented. Performance and security wise inferior to WKWebView, deprecated | Allows you to mix native content with the WebView and to resize it | Hybrid Frameworks (Cordova, Capacitor) | |
WKWebView | iOS, iPadOS, macOS | Default WebView implementation on iOS | Rich API with JS and CSS interaction, Tie WebView and native APIs together | Features similar to current Safari but some Web APIs are not supported | Allows you to mix native content with the WebView and to resize it | Hybrid Frameworks (Cordova, Capacitor) | |
WebView2 | Windows | Default WebView implementation on Windows | Rich API with JS and CSS interaction |
This is the first draft of WebViews from my memory and experience with mobile platforms.
Feel free to add more information and WebViews
There is also WebView2 by Microsoft that deserves a separate row in this table.
Thanks for the table @NiklasMerz !
I think it would benefit from adding a UX flexibility
column, since that is also a major consideration when choosing an appropriate embedding technology. For example, Android WebView allows you to mix native content with the WebView and to resize it, whereas Custom Tabs cover the entire application with some minimal top bar customization.
I would also rename Chrome Custom Tabs
to Custom Tabs
, since Chrome just provides an implementation of the Android API.
Would it be useful to add some examples of apps using each of those technologies? It could turn out vague, but might also reveal some clear use-case areas
see also https://www.w3.org/2021/Talks/dhm-tpac-webviews/?full#8 and https://www.w3.org/2021/Talks/dhm-tpac-webviews/?full#9 for another perspective on this
I slightly updated the table above. The slides from @dontcallmedom are already perfect in comparing the actual WebViews available today.
Is the table really needed? We could make the table a file in the repo and accept PRs to update it. Doing this in comments is quite cumbersome. What do you think?
The main thing I was thinking about when I filed this use case is that we could try to find names and definitions for different types of WebViews. I had Android WebView and WKWebView as "full-fledged WebViews" and Custom Tabs and SFSafariViewcontrollers as "WebViews for a browser-like experience in apps" in mind. The names are not really good for these different categories. Also there might be more types or the lines between types are actually blurry.
If I think this further I think it would be great to have standards for different kinds of WebViews with each of their own use cases. This could mean WebView providers could build more specific APIs to better suit these use cases. For example the browser like APIs can be really secure and optimized for general web content. The more generic WebView could focus more on developer flexibility and tailor the security and UX more around use cases for app developers using web technologies differently than "normal web content".
The slides from @dontcallmedom are already perfect in comparing the actual WebViews available today.
@NiklasMerz - As a Windows/Desktop representative here I disagree 😂 (no offense @dontcallmedom). I'm happy to add some details on Windows WebViews, notably - WebView2, WebBrowser, WebView, CEF, and Electron. I like the idea of checking in a comparison table and I can go put a PR out to add some Windows context.
If I think this further I think it would be great to have standards for different kinds of WebViews with each of their own use cases.
Definitely agree. In my head there's three fairly distinct buckets with some overlap between each:
@slightlyoff wrote a good post and did a talk on the use of WebViews for generic content that users would likely prefer to be handled in their default browser. In the vein of this issue, it'd be valuable for us to have a stance on the right way to approach the use of WebViews.
Are we open to adding discouraged use-cases like using a "normal" WebView for browser-like experiences? Custom Tabs or launching the user's preferred browser being the correct technology for that, potentially evolving into standards proposals to enforce that for top-level third-party content.
Thanks for your work here, @NiklasMerz and others. FYI, as part of my team's work, I wrote Survey of web embedding technologies.
My intent with that doc was to provide a broad perspective on what systems are available or where web content is embedded using those systems in ways exposed to devs or users. That led to my looking beyond just webviews towards web embedding technologies in general, which we found useful. Feel free to reuse or include elements from that doc in the markdown here.
Brief discussion in 2022-08-09 meeting Android WebView, WKWebView, WebView2: full-fledged WebViews Custom Tabs and SFSafariViewcontrollers: WebViews for a browser-like experience in apps
Use case name
Define different types of webviews
Submitter(s)
Niklas Merz
Motivation
As we discuss more and more use cases it might be helpful to define and name the different uses of webviews. Webviews can be used in many different ways and some of them are vastly different in terms of privacy and security implications. It could be a good idea to separate them into different categories to discuss them better.
Stakeholders
Browser vendors App developers
Analysis
We can already see these different categories of webviews with the APIs available on the two big mobile platforms. Android offers a powerful webview API and Chrome Custom Tabs. iOS has WKWebView for a rich webview API and SFSafariViewController for a more browser-like experience embedded in native apps.
The webview APIs offer powerful features for example injecting JavaScript or other interactions with the pages loaded into the webview. These features require the designers of the webview APIs and app developers to think a lot about the security and privacy implications of their design choices. Webviews that allow the user to navigate the web freely need to be much more secure and restricted than webviews that just allow code under control of the app developer. Webviews are used a lot to build the UI or core features of apps. These apps could benefit from more control over the native parts of the app or vice versa the native code might want to have more control over the web content. The distinction between browser-like webviews and full webviews embedded into apps is the most obvious one but there are many more like we see with ePub and mini apps.
If there are different types of webviews with different use cases and feature sets app developers could benefit from more freedom or security and privacy. Browser vendors could roll out powerful features for developers of apps built around webviews but still keep the browsers and browser-like webviews secure.
Related W3C deliverables and/or work items
How is the issue solved in the Browser, and what’s more is needed?
Webviews and browsers currently always have the same features and restrictions. Different webview implementations share different APIs to interact with the webview content.