Consider dropping support for the embedded web library #596
Description
We currently have experimental support for building a web library version that can be embedded on third-party websites (part of #446). It has never been officially supported or documented, is not actively tested, and is unlikely to be used anywhere. Based on this experiment, I have concluded that the web library is not a good fit for embedding. The main reasons are:
- It is heavily dependent on screen size and input type, attempting to offer the best UX for a given device. To achieve this, it installs global event listeners and expects the web library to take up the entire width of the window.
- There isn't enough space on small screens to make the embedded version work on mobile devices.
- It uses routing that is reflected in the URL, meaning the embedded version cannot support the browser’s back/forward navigation.
- It includes multiple features that cannot be easily separated from the bundle but would effectively be dead code in an embedded version.
- It has features that depend on Zotero’s server architecture, which is not available in the embedded version.
- Potential issues with font license.
- Maintaining both the normal and embedded versions increases code complexity.
Therefore, I propose canceling the idea of producing an embedded web library. Instead, I suggest building something from the ground up, focused on meeting the requirements for an embedded Zotero library—or at least a subset that we can realistically support. To avoid duplication, components and utilities that are universal enough to be used in both versions could become part of web-common.
The immediate benefit would be that it would make #571 much simpler. Also, #457 (required for #584) would most likely require changes to the embedded variant of non-URL-based routing.