Request for improvements: Color Filters in Liquid

[0xtlt]

Request for improvements: Color Filters in Liquid

---

Background

Liquid, as the templating language for Shopify, provides a range of filters for working with colors (e.g., color_to_hex, color_to_hsl, color_to_rgb). However, the current implementation lacks support for certain advanced color models and operations essential for modern web projects, such as OKLCH.

For example, OKLCH has become increasingly popular due to its perceptually uniform color representation, making it highly suitable for animations, color accessibility, and advanced design systems. Design system libs like Daisy UI are already adopting OKLCH.

Current limitations

1. No support for color_to_oklch in Liquid filters:
   This limits the ability to work with modern color spaces that are increasingly adopted in web development.

2. Lack of a "raw value" filter for colors:
   Developers currently cannot strip wrappers like rgb(...) or rgba(...) to access clean numerical representations for further manipulation.

3. Missing mathematical methods:
   Liquid lacks essential mathematical functions such as atan2, cos, and sin, which are required to manually convert between advanced color spaces (e.g., HEX to OKLCH). This makes custom implementations cumbersome or impossible in plain Liquid.

---

Proposal

1. Add a color_to_oklch filter:
This filter would enable designers and developers to leverage OKLCH in their Shopify projects. Its adoption would align Shopify's Liquid language with modern CSS practices and empower merchants and developers to create more sophisticated and accessible designs.

2. Add a "raw value" filter for colors:
This filter would remove wrappers like rgb(...) or rgba(...), providing a clean numerical representation of color values for further manipulation or external use.

3. Implement basic mathematical methods:
Adding functions such as atan2, cos, and sin would allow developers to perform advanced color manipulations and implement custom filters directly in Liquid.

---

Potential benefits

• Accessibility: Improved handling of contrast ratios for designs adhering to accessibility standards.
• Better animations: More natural color transitions for dynamic interfaces.
• Alignment with modern CSS standards: OKLCH is already supported natively in modern browsers and CSS workflows.
• Developer empowerment: Easier integration with advanced design systems like Daisy UI and custom implementations.

---

Call for suggestions

We welcome feedback, ideas, or use cases for these proposed additions.

• Are there other color filters you would like to see in Liquid?
• How would these filters improve your development process?

---

Example: Usage of color filters in Liquid

{% assign hex_color = "rgb(255, 0, 0)" %}
{% assign oklch_color = hex_color | color_to_oklch %}
{% assign raw_color = hex_color | color_to_raw %}

{{ oklch_color }}  <!-- Example output: oklch(0.7035 0.2573 29.2346) -->
{{ raw_color }}    <!-- Example output: 255, 0, 0 -->

We appreciate your input to help make Liquid more powerful and aligned with modern web development needs!

[catlee]

Can you expand more on how you would use color_to_raw?

We do have the colour drops which expose .red, .etc. to get access to the individual channel values.

Would introducing a to_color filter to get color drops from strings help?

What about something like this?

{% assign color = "rgb(255, 0, 0)" | to_color %}
{{ color.red }} <!-- outputs the red channel of the colour 255 -->
{{ color | color_lighten: 20 }} <!-- "#ff6666" -->
{% assign oklch_color = color | color_to_oklch %} <!-- converts to an "oklch(...)" string -->

{% assign color = "oklch(0.7035 0.2573 29.2346)" | to_color %}
{{ color }} <!-- outputs the colour in its native colour space: "oklch(0.7035 0.2573 29.2346)" -->
{{ color.lightness }} <!-- 0.7035 -->
{{ color | color_lighten: 20 }} <!-- lightens the colour in its native color space: "oklch(0.9035 0.2573 29.2346)" -->

{% assign rgb_color = color | color_to_rgb %} <!-- converts to an "rgb(...)" string -->

[0xtlt]

Hi @catlee,

The idea of color_to_raw was more like: "keep only the value of the color function."

For example:

• rgb(255, 0, 255) → 255, 0, 255
• oklch(0.7035 0.2573 29.2346) → 0.7035 0.2573 29.2346

My objective is to extract color values from my theme settings and inject them easily as CSS variables in the root.
My UI design system is already leveraging those values like:

{% assign raw_primary_color = settings.primary_color | color_to_rgb | color_to_raw %}
{% assign raw_primary_oklch = settings.primary_color | color_to_oklch | color_to_raw %}

<style>
  :root {
    --primary-rgb: {{ raw_primary_color }}; /* Output: 255, 0, 255 */
    --primary-oklch: {{ raw_primary_oklch }}; /* Output: 0.7035 0.2573 29.2346 */
  }
</style>

This would generate the following CSS:

:root {
  --primary-rgb: 255, 0, 255;
  --primary-oklch: 0.7035 0.2573 29.2346;
}

[catlee]

@0xtlt, and what is the benefit of having the raw colour values as CSS variables, as opposed to the full rgb(255, 0, 255). How is this consumed by the rest of your CSS?

[0xtlt]

This is an example of the CSS bundle generated by DaisyUI, which is a design system lib:

And used in the code as:

.btn {
  background-color: oklch(var(--btn-color, var(--b2)) / var(--tw-bg-opacity));
}

The idea is just to remove the "function name" "oklch" part of the generated color_to_oklch :)

[catlee]

Got it! Thanks for explaining!