Dedicated Options for Styles

[dtdesign]

Note: This is part of a larger initiative to overhaul the style system and the customization options in general. See #6028 to learn more.

The status quo for styles with customization abilities is to ship alongside a regular plugin that provides generic options in the admin panel. This approach works because some types of options are exposed using variables in the SCSS compile step which allows for some decision to be made. The second building block are customized templates that embed additional logic or insert extra blocks that are then customized by the style.

Drawbacks of Using Global Options

Using global options are undesirable for a plethora of reasons:

1. Styles are then tied to the plugin that provides the package. Lifting the style protection will remove that coupling which means that users could uninstall the plugin and break their style.
2. This causes the options menu to be filled with sometimes tens of options per style which causes a lot of clutter and especially noise in the search results.
3. While the naming of the categories are mostly relatable, a lot of the times it makes it difficult to draw the connection between the option and the style it affects.
4. Exporting styles is a mess because while customized templates are exported, individual options are left out. This is caused by the options provided through the plugin and not by the style itself.

Potential Solution: Options per Style

The most straightforward approach is to add support for custom options to styles based on form builder input fields. This provides a wide range of customization options while providing a familiar UI while avoiding additional burden for style authors. Options are then tied to that specific style and can be exported / imported alongside.

Unclear

• How should these options be made available? Exporting them as CSS variable is possible, but does not allow for proper decision making in CSS selectors.
• How should we deal with boolean options and/or radio selects? Those could be translated into CSS classes applied to the document element, allowing for some degree of decision making. Something like .style__option__%s for boolean fields and .styleOption__%s--%s for radio selects could work.
• Do we want to support custom input fields? This could enable some more advanced options but would then cause the styles to be tied to a specific plugin once again. If there are some useful form fields missing, we could add them to the core. If we want to restrict options to those available in the core only, we must maintain an explicit allow-list to make it work.