Content creators familiar with CMS Hub are used to our page editor having a styles tab when you have a module selected. Previously only default modules, and drag and drop area elements could have fields in the styles tab. We're now opening this up to developers to add fields to the styles tab for modules.
How does this work?
Adding style fields isn't much different than fields you add to the options tab. Style fields are added to the same fields.json file you use for "content" fields. The important difference is that all style fields must be added within a field group with a "tab" property set to "STYLE".
Not all module fields can be used in the Styles tab. The distinction is generally between fields that are definitely content and fields that are clearly intended for styling purposes. Some fields can be used for both. You should place your fields appropriately based on whether they are controlling styling, or whether they affect the meaning of the content you are displaying.
We are also introducing new fields that are only available to use as style fields.
Styling on the web is generally tied to your CSS code. We've introduced a new property available in your module.html which directly outputs the CSS associated with the field. You can still get the direct field values if you want full control, but the generated CSS can take away a lot of the work. This is especially true in the case of gradients.
We're also introducing a new HubL scope_css block tag to make it easier to scope your CSS to specific module instances.
Note: At this time there isn't a way to migrate existing module options fields to style fields - for modules that are already in-use on pages. Additionally style fields must be added to your module's fields.json and uploaded using the CLI. The ability to create style fields using the Design Manager is coming soon.
More detail on style fields can be found in our module and theme fields overview.
Additionally we understand that it's important to deliver a great experience for content creators. We've put together a page expressing what we've found to be the best practices for using these fields.