Proposed Removal of the Resizable and Auto-Scaling GUI Feature and External CSS Concerns

[michaelbauchert]

I've been enjoying the process of developing with CMajor, but I had some concerns regarding the styles of the container that holds the plugin's custom element.

I tested the demo custom element and proposed CSS changes with the CMajor plugin Windows 11.

Resizable and Auto-Scaling GUI

In my opinion, the resizable and auto-scaling gui feature, in it's current implementation, isn't needed. It uniformly scales the entire UI, maintaining the plugin's aspect ratio. When required, this specific behavior can be recreated entirely by plugin authors using only CSS. I made this demo to show one way of doing it, but I imagine there are other methods, each with their own trade-offs.

I argue the dimensions of the plugin UI should rarely be fixed. One of the benefits of using web tech for UI is the ability to program responsiveness to changing screen dimensions. I suggest it should be the plugin author's responsibility to adapt to the dimensions of the plugin UI container. Container Queries and Container Query Length Units , which received baseline support across mainline browsers last year, should prove to be a key technology for plugin authors to adapt their UI when the plugin's custom element dimensions change. Alternatively, if it is expected that the plugin UI will only exist in the context of a floating window, Media Queries and Viewport Units will suffice.

Applied Styles to the Plugin's Custom Element

In my opinion, I think there should be a clear boundary between the CMajor container HTML and the plugin author's components. I suggest applying styles that only affect the DOM outside the plugin UI. Keep the boundary between the CMajor container markup and the author's custom element as clear and predictable as possible. I reiterate: I believe it should be the responsibility of the plugin author to adapt their plugin's custom element to the context it resides in.

Following is every style currently applied the the custom element and why, according to the philosophy outlined above, I think each should be removed or rescoped.

Display: Block

The display property of the plugin's custom element is set to block in the style attribute of the plugin's custom element. This is especially an issue if the plugin author wants to apply CSS Grid or CSS Flex layouts to the host element of their UI. Plugin authors can currently circumvent this by using !important. As this property affects the internal behavior of the plugin's custom element, I suggest allowing the author to set the display property.

Width and Height in px

The view dimensions in the manifest file are applied directly in px units to the plugin's custom element, which disables the plugin's ability to dynamically resize. To preserve this behavior, I suggest setting the manifest's view dimensions to the window, but to not apply them as px units to the plugin's custom element. Plugin authors can currently circumvent this by setting the dimensions to 100% and delimiting them with !important.

Removing the px dimensions from the plugin's custom element may make it awkwardly fit inside the plugin window. It could be too large or too small. To remedy this, and also allow plugin authors the flexibility they need, I suggest setting the display property of cmaj-patch-view-holder to grid. This change will stretch the plugin's custom element to fit cmaj-patch-view-holder when the custom element is too small and show scroll bars when it is too big. Plugin authors will still be able to refine this behavior to fit their UI's needs.

* Selector Reset

Here is a block of styles currently applied to every element within the plugin window:

* {
    box-sizing: border-box;
    padding: 0; 
    margin: 0; 
    border: 0; 
}

If a plugin author chooses not to use the Shadow DOM, which is not necessarily required when creating a custom element, this CSS will apply to every child element within the custom element. One benefits of using a "light DOM" approach is allowing the custom element to inherit styles of the outside application for a more cohesive look. Using the Shadow DOM, these styles apply to the host element of the plugin's custom element.

I think setting box-sizing and margin on the host element is appropriate, as those properties affect the DOM outside the bounds of the plugin's custom element. To be safe, I suggest rescoping them to:

*:not(cmaj-patch-view-holder > *  *) {
    box-sizing: border-box; 
    margin: 0; 
}

Because box-sizing is set to border-box on the plugin's custom element, any applied border can no longer spill outside the bounds of the custom element. As the border property enters the domain of the plugin UI, along with padding, I suggest scoping these styles to everything but the plugin's custom element:

*:not(cmaj-patch-view-holder > *) {
    padding: 0; 
    border: 0; 
}