Style Settings

[adrocknaphobia]

Hey everyone. Thanks again for all the feedback on our latest developer preview. We’re circling back here to share some of the ideas that have been refined through discussion here as well as through live conversations with several of you. We’re breaking up the various topics into individual threads so that we can post updates more quickly and create a more focused discussion. Please remember, these are just ideas of how we might implement a solution. We’re looking for your feedback to help mold the final product. In this thread, we want to dive into style settings.

In today's themes, it’s common to duplicate settings in order to set different customizations for mobile and desktop breakpoints. This leads to a lot of visual clutter for merchants in the sidebar. It can also create confusion when a merchant changes a mobile setting while previewing the desktop and vice versa.

With style settings, we’re introducing the ability to only show a single setting for customizations, and allow merchants to toggle between different breakpoints in the theme editor to edit the value of these settings for different breakpoints.

As part of the developer preview, we’ve shown how you can use the | class_list filter to catch style panel settings in Liquid, but we are also going to allow you to read the values of style settings in Liquid as you do other input settings. Style settings can hold multiple values, so you need to retrieve the values for each breakpoint.

// blocks/group.liquid
<style>
  #{{ block.id }} {
    gap: {{ block.settings.gap[breakpoints.base] }};
    
    {% if block.settings.gap[breakpoints.mobile] != blank %}
       {{ breakpoints.mobile.media_query }} {
         gap: {{ block.settings.gap[breakpoints.mobile] }};
       }
    {% endif %}
  }
</style>

<div class="my-class">
  {% content_for "blocks" %}
</div>

{% schema %}
{
  "name": "Group",
  "settings": [
    {
      "type": "style.range",
      "label": "Gap",
      "id": "gap",
      "min": 0,
      "max": 100,
      "default": 20,
      "units": ["px", "em"]
    }
  ]
}
{% endschema %}

While this approach will work, it can be quite verbose to manually catch these settings in liquid, as you can see below. Even if they all share the same values, these inline styles get repeated across each instance of the block, so this can negatively impact the storefront performance of your theme.

<div id="BLOCK-A" class="block:group">
  <style>
    #BLOCK-A {
      gap: 20px;
    }
  </style>
  <div class="my-class">
    [...]
  </div>
</div>

<div id="BLOCK-B" class="block:group">
  <style>
    #BLOCK-B {
      gap: 20px;
    }
  </style>
  <div class="my-class">
    [...]
  </div>
</div>

<div id="BLOCK-C" class="block:group">
  <style>
    #BLOCK-C {
      gap: 10px;
      
      @media screen and (min-width: 480px) {
        gap: 30px;
      }
    }
  </style>
  <div class="my-class">
    [...]
  </div>
</div>

To make it easier to apply settings, we’re exploring how we might make it possible for you to specify the CSS variable that you would like to use and Shopify will ensure it is populated with the right value based on the breakpoint. This will allow you to use the full expressiveness of CSS to achieve advanced use-cases, such as using calc, clamp, minmax, and more, without having to write a ton of boilerplate code.

// blocks/group.liquid
{% stylesheet %}
  .my-class {
    gap: calc( var(--my-gap-variable) * 2);
  }
{% endstylesheet %}

<div class="my-class"> 
  {% content_for "blocks" %}
</div>


{% schema %}
{
  "name": "Group",
  "settings": [
    {
      "type": "style.range",
      "label": "Gap",
      "id": "gap",
      "css_variable": "--my-gap-variable", // create and set a css variable
      "min": 0,
      "max": 100,
      "default": 20,
      "units": ["px", "em"]
    }
  ]
}
{% endschema %}

In the example above, setting the css_variable property to --my-gap-variable will instruct Shopify to generate a CSS var in the linked stylesheet with the value of the gap setting. You may then rely on that variable throughout your theme.

<head>
  <link src="/cdn/compiled_assets/stylesheet.css" />
  <style>
    #BLOCK-A {
      --my-gap-variable: 10px;
      
      @media screen and (min-width: 480px) {
        --my-gap-variable: 30px;
      }
    }
  </style>
</head>

[...]

<div id="BLOCK-A" class="block:group">
  <div class="my-class">
    [...]
  </div>
</div>

<div id="BLOCK-B" class="block:group">
  <div class="my-class">
    [...]
  </div>
</div>

<div id="BLOCK-C" class="block:group">
  <div class="my-class">
    [...]
  </div>
</div>

/* stylesheet.css Generated by Shopify */
.block:group {
  --my-gap-variable: 20px;
}

We hope this level of control and the minimal size of the generated CSS will be helpful to theme developers.

New Specialized Input Settings

Finally, we plan on introducing new specialized input settings for common controls – think margin, padding and more. So it’s not just panels, but individual settings that you can incorporate a la carte. They will be available with breakpoint aware style.padding and as plain settings with no breakpoint interaction padding.

{
  "type": "padding",
  "label": "Padding",
  "id": "my_padding"
}

{
  "type": "style.padding",
  "label": "Padding",
  "id": "my_padding"
}

As always, thanks for feedback and please let us know what you think. Keep in mind these are directional. The code isn't final but we want to share early and hear feedback.

[eballeste]

i think the css variable approach is not only very smart, but extremely flexible, i can't wait to use all of this!

[PaulNewton]

Nit, spatial UX, padding/margin/border etc side controls should be arranged spatially in a cross, condensing them to a box for condensing's sakes or dev familiarity(css clockwise usage) isn't great for merchants.
We're already going to be hitting the spatial problem of blocks/sections being arranged Y-axis-only but the rendered output is going to be both X&Y (and sometimes Z).

[PaulNewton]

 "css_variable": "--my-gap-variable", // create and set a css variable

Wouldn't css vars be more for section level decisions then , or how is shopify going to namespace the css-vars for each block
that has the css_variable setting but a different value?

[PaulNewton]

We have to also keep in mind nestable blocks means we could put all/some style based settings in a standalone block dedicated only to styles that then applies to the containing section, or block-siblings or block-children etc.
Just have to work through the limitations of such an architecture caused either by syntax, scope issues, or block cap limits etc.

When I have the time I'm working on a prototype of this concept to move advanced-customizations such as animations, grid layouts, responsive behavior, or overrides to an advanced-block; that advanced-block also would serve as an opt-in indicator when a merchant/theme has gone past basic support.

[wiebekaai]

Hey, thanks for the clear examples and great progress.

How can we use CSS variables with design tokens if they're only in em and px? It would be nice to have a unit-less number range or maybe t-shirt size options (S, M, L, XL).

[wiebekaai]

Or em (why not rem?) with preset options instead of steps.

[PaulNewton]

The style.range unit type should be settable/unsettable just like the range settings unit property:

"units": ["px", "em"]

https://shopify.dev/docs/storefronts/themes/architecture/settings/input-settings#range

[wiebekaai]

Nice. Still presets would help, when you have to add a smaller option than your already defined styles.

[PaulNewton]

Example wanted?

I think the preset/default is no unit type at all, or what the schema defines , or the presets of the blocks presets.
block presets set values only though and can't change schemas properties.

have to add a smaller option than your already defined styles

Isn't that what CSS specificity and the cascade is for? Should be doable with a unit less range?
Or see my comment in this thread about experiementing with dedicated-sstyle-blocks as overrides/granular settings.

[wiebekaai]

If you have paddings 0-5, but now you'd now like a size between 0-1. You can easily change that, but then you would have to adjust all your existing 1s to 2s to not change your current templates.

[gideonb]

@adrocknaphobia — I am late to the party here but I have been thinking about css variables and grid systems this whole time.

I want blocks to set themselves up according to the surrounding theme settings. I also want to give merchants the ability to overwrite any style at a granular level.

I think css variables are the right interface for this, but what I really want is something like this:

{
  "type": "style.range",
  "label": "Gap",
  "id": "gap",
  "max": 100,
  "default": "--gap", // read-write interface
  "units": ["px", "em"]
}

The value of style.range.gap should match the rest of the design tokens related to spacing. Unfortunately that value is contextual. The value of any gap is modified by global, section-level, group-level, or even neighbor-block settings. I can hardcode default JSON templates with pixel values but as soon as a merchant adds their own block, or changes the background color of the neighbouring block, or changes a global grid setting, the system falls down.

Letting style settings default to a css variable would expose the contextual value of a static block to the theme editor and allow merchants to overwrite any granular pixel value at any breakpoint. It's just one system. As long as the theme editor doesn't set a value until a merchant adds a value, the theme and the theme editor can use the same css variables.

[mnj-novicell]

Hi @adrocknaphobia, I really like the idea of the css variables, but I´m wondering if there will be an option for it not to be set.
I might have a section where I have a general setting to adjust padding for all the blocks within. Then I also have an option on each block to make individual padding overrides. If the settings on the blocks always sets the css variable value, then I assume it won´t be able to use a shared setting, since it will always be overridden by the individual setting.

I normally have a related checkbox setting to determine if the individual setting should be used or not, but I imagine that won´t work with the css variable setup? In general it would be nice to have more options for blank values, so we can use the setting only if it has a value and not having to add the additional checkbox setting.

I`m imagining a css variable solution would work for our purpose if we were able to set the padding setting to blank, which then should not set the css variable. It could also be a solution where you can disable settings so the setting would just return blank even though you have a value in the setting.

Really looking forward to what you come up with 🥳

[nchan0154]

I agree with the other contributors who mentioned that they need support for design tokens and systems that require more than just a pixel value in a CSS variable. Setting font sizes in pixels is harmful to accessibility and merchants don't know what an em or a rem is, so if the solution basically makes editing pixel values easy, but requires theme developers to take on the burden of working with other units that might pose a better experience, that would be far from ideal.

I would really want a system like to to be able to support arbitrary values, like a select that lets you change values at different breakpoints, as there needs to be a way to support the internationalization case.

Some key things to consider, are that the directions for the margin/padding tokens must be reversed in RTL language. Code that supports RTL is probably using things like or 'text-align: start' under the hood, but the current text_alignment setting only outputs left, center and right, which means the theme developer has to be in charge of translating that into a less rigid system. Showing 'start', 'center' or 'end' is not ideal as merchants won't understand what that is.

Another use case would be the display property, it's not uncommon for merchants to want to show or hide different sections on mobile or desktop, and I think being able to show them a label other than 'None' or 'Block' would be vital to making it feel good and usable.