Allow webview to go in custom views as well

[mike-lischke]

This feature request is about getting the possibility to show HTML code in a custom view (instead of that treeview). So, just like we have for previewHTML would be required there too: a code provider and a canvas to draw on. That would allow for some pretty cool things, including animations (like displaying status images for hardware development which switch state, depending on the HW status).

[jrieken]

Dislike - we want to phase out previewHtml and make folks use an upcoming webview API. For that, yes, we should support showing it in different locations

[mike-lischke]

I have no strong feelings for previewHTML. It's just that what we have currently. The base idea is to render HTML in small support windows, like the ones docked in the left sidebar. If we get the ability to dock a webview anywhere then this FR would be obsolete.

[mjbvz]

I'm against expanding webview usage without very careful consideration. Webview are resource heavy, awkward for accessibility, and don't play nicely with many other areas of the vscode api (such as keybindings and so on).

They also offer too much freedom. VS Code is what it is today in part because its api is more restrictive. This undoubtably prevents some cool extensions possibilities, but in return you get an editor that is faster, more stable, and more consistent. Webview Editors are already bad enough for all these reasons

[mike-lischke]

I hear you Matt. This wish only came up because the existing API is very limited. I know there's work going on to improve the treeview in these support windows, but it doesn't look like they will become versatile enough to be used for more than basic display.

I totally understand if you don't want a full webview there and it's up to you to refuse the FR. However, it should at least be possible to print formatted text (including left/middle/right alignment and images) easily. I could then construct a grid output using that (event though, aligning to columns is still tricky then).

[eamodio]

I would strongly echo the desire to at least have a webview in an activity (once an extension can provide activities). While having webviews as editors is great, depending on the use-case, they can end up being the only mechanism for an extension to provide richer behaviors and interactions (think of chat integration) which can lead to a compromised experience. Because now the editor/tab needs to be managed, positioned, etc by the user.

So while I certainly agree that the strictness of the api is certainly a strength, it is a double-edge sword. And maybe a compromise by only allowing it at the full activity level will alleviate some of the wild-wild west concerns with UI getting out of control, while still satisfying a need for richer extensions.