Enhancing style.spacing_panel with Support for Predefined Spacing Systems

[thagxt]

The current implementation of the style.spacing_panel in Shopify's theme architecture restricts spacing values to percentages (%) and pixels (px). This approach poses challenges for teams that employ a Predefined Spacing System using CSS variables to maintain design consistency across storefronts.

Challenges with the Current Implementation:

• Inconsistency in Design: Allowing only % and px units can lead to discrepancies when developers or merchants apply arbitrary values, potentially disrupting the visual harmony established by a spacing system.

• Maintenance Complexity: Manually ensuring that all components adhere to a consistent spacing standard becomes cumbersome without the flexibility to utilize predefined variables.

Proposal:

1. Allow Number-Only Input: Instead of limiting the style.spacing_panel to predefined units like % or px, allow developers to define spacing values as raw numbers. This gives flexibility to decide later in the code how those numbers are used, without imposing specific units.

   For example:

   • If we input 25 into the style.spacing_panel, it could be used directly in the theme code like this:

     padding: var(--space-{{ block.settings.size }});

     Here, the number is seamlessly integrated into a design system without any additional conversions.

2. Optional Unit Handling: For developers who want to use units (e.g., px, rem), the raw numbers can still be paired with the desired units in the code:

   margin: {{ block.settings.size }}px;

   or:

   gap: {{ block.settings.size }}rem;

3. Maintain Developer Control: This approach ensures that developers remain in full control of how spacing values are applied, whether via a tokenized spacing system (var(--space-N)) or by explicitly appending units. The system remains unit-agnostic, making it more versatile for different use cases.

Benefits:

Design Consistency, Simplified Maintenance, Alignment with Modern Practices, More control over our designs.

[thagxt]

Also, why does this setting:

"justify-items": "flex-start",

output flex-start instead of just start?

With modern CSS, start is sufficient and not limited to flexbox-specific alignment. Using flex-start feels outdated and unnecessarily tied to a specific layout model, whereas start is more semantic and works across different contexts, including Grid and other layout systems.

Why no CSS Grid support?

Additionally, why is this implementation seemingly limited to Flexbox? CSS Grids offer powerful layout capabilities and, in many cases, can be a better choice for complex or structured layouts. By restricting this to Flexbox, it feels like an arbitrary limitation that doesn’t take into account the flexibility of modern CSS. Who decided that Flexbox is inherently better for these cases, and why should we be constrained to use only that?

Wouldn’t it make more sense to provide broader support for both Flexbox and Grid to let developers choose the best layout tool for their specific needs? This restriction seems unnecessary and limiting.

https://developer.mozilla.org/en-US/docs/Web/CSS/justify-content

[thagxt]

Why are you using a hyphen in no-wrap instead of the standard CSS spelling nowrap?

CSS universally uses nowrap without a hyphen, so why invent a new way of spelling it? There's no such thing as no-wrap in CSS, and introducing this custom variation adds unnecessary confusion.

Consistency with established CSS standards is crucial for developers, as it reduces the learning curve and avoids potential mistakes. I don’t see a valid reason to deviate from the standard nowrap.

Style settings docs