Export and Management of 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 technical management of styles has a lot of shortcomings that have an impact both when sharing styles as well as maintaining them.

Update Support Through Protected Styles

Version 2.0 introduced the concept of tainted styles where it is possible to have the style in a semi-locked state that permitted making additions to the CSS and changes to the color scheme. This was designed with the intention to support updates by the style creator and for the most part does its job.

This “protected” mode also meant that the additional CSS of the style couldn’t be altered. This was never deemed an issue when designing this feature because of how CSS works and the ability to overrule previous styles. Users were tempted to remove this protection because it allowed them to simply rip out CSS rules they didn’t want to apply or to make some quick adjustments to the existing selectors.

Looking back, this was one of the greatest mistakes we made. Despite the lengthy (!) warning in the dialog to remove this protected mode, far too many users opted to go this route because it made things easier in the short term. This for the most part works fine as long as there are no substantial changes to the templates, but as soon as those happen, the style will slowly start to fall apart. Updating the style is no longer an option because the now tainted style has diverged from the style author’s variant versions ago thus they will eventually face a situation where they can only throw away their style, even though the author might have done a good job at maintaining it.

Key Lessons Learned

There are a few things that worked out while others have proven to be a step in the wrong direction.

• Only store changed values for the color palette.
  Style authors are currently unable to make changes to individual color values. This was intended to avoid overwriting adjustments by the site owner but also meant that slight color adjustments to fix things like contrast issues were impossible.
• Do not allow users to break update support.
  The update support is a fundamental aspect of styles and allowing users to break it is doing them a disservice. Especially upgrades are a major blocker and a recurring source of frustration when the upgrade appears to break their style, although this could have been avoided.
• The export of a style must be complete.
  The style export was designed with the idea of sharing it with others but not to preserve the style as-is. The export must support both use cases so that users can export their modified style while preserving the update support.

Unsolved Questions

• How do we want to preserve the update support when exporting a style? The update support currently relies on two different components: The package itself and the style carrying an identifier. Exporting a style cannot magically export the package if the user is not the package owner.
  Wild idea: Treat styles like packages, allow them to be distributed via the package servers. Bonus points for making it impossible to artificially tie a style to a plugin.
• Should we make it possible to intentionally break the update support? A possible candidate would be an extra flag in the style export that only exist in debug mode with enabled developer tools.
• How should the properties of a style be stored to allow it to be preserved as-is alongside the user modifications?