Experiment with ways a frontend can support ipywidgets 7 and 8

[jasongrout]

This is an experiment in distributing a plain HTMLManager AMD module in the dist directory, and makes the manager more flexible in that even the core controls can be overridden. The idea here is that HTMLManager can be used and even the core controls overridden (for example, possibly the widgets 7 version of core controls could be used?)

This is partly an attempt to address #3429, and maybe providing a way to load either widgets 7 or widgets 8 controls depending on what was requested by the kernel at runtime.

[github-actions]

👈 Launch a binder notebook on branch jasongrout/ipywidgets/amd8

[jasongrout]

I also experimented with adding a new control comm message, like suggested in #3429 (comment)

[jasongrout]

New idea that seems much simpler:

Make @jupyter-widgets/controls from ipywidgets 7.x work with ipywidgets 8, and @jupyter-widgets/controls from ipywidgets 8 work with ipywidgets 7. Create dist/ folders in the published @jupyter-widgets/controls packages for both that contain single anonymous amd modules. Then modify html manager to pull the core controls from CDN if the version number does not match what was bundled with the html manager (in core controls for widgets 7.x and for 8.0). We might still have an issue with CSS from the bundled controls stomping on the CSS from what is being pulled from CDN, but let's see what it looks like first. Perhaps we don't load the built-in controls first, and only load those dynamically as needed, so if we are dealing with a widgets 7 system, we never end up loading the widgets 8 controls.

[jasongrout]

We might still have an issue with CSS from the bundled controls stomping on the CSS from what is being pulled from CDN

To take care of this, we can assume that either controls for 7.x or controls for 8.x will be loaded, but not both. Then we can dynamically load either controls versions as needed (with the css for that version).

[jasongrout]

In the widgets dev meeting, we decided to conclude these experiments for now. To summarize lessons:

1. The widget control message could work, but is kind of abusing the widget registration system. The widget registration system is for kernel-side widgets to register themselves to be instantiated from the browser, but here we are using that information to assume what widgets will be instantiated in the browser from the kernel (i.e., the other way around). In practice, the assumption that these are the same probably holds, but it still has a code smell. An advantage of this approach is that we can preemptively decide whether to instantiate a widgets 7 or widgets 8 widget manager, before we get any actual widgets created, so we have very clean separate codepaths for supporting ipywidgets 7 and ipywidgets 8.
2. The "load core widgets 7 and widgets 8" and use whatever the kernel wants should work in js (i.e., the core controls for 7 should work with the 8 widget manager), but there are still concerns around the css from one messing with the css from the other. These could be alleviated with a new 7.8 and 8.1 release that completely separated the css.

In the end, we're still not sure how much of an issue it will be for frontends in practice, so I hesitate to spend more time and effort in exploring this. If it becomes a problem in practice after we release, we have several avenues to mitigate issues.