Forem: Marat Sabitov

A journey into the world of animated SVGs

Marat Sabitov — Wed, 08 Apr 2026 09:35:10 +0000

I was recently reading the Vue documentation and came across a mention of Pinia, a library for state management. And when I clicked on the link, this library won me over thanks to its creative logo. It would seem like this is just a documentation site, where all you need to post is code descriptions and examples. So, it was a surprise to me when Pinia started following my cursor. I even forgot my original goal and simply started searching for all her reactions. Such attention to detail certainly deserves praise. This cheerful character blinks, opens its mouth when hovering and follows the cursor with its eyes - in other words, it is interactive and seems to be alive.

And I wondered - how is it implemented under the hood? And how would I implement the same thing?

Pinia Alchemy

The logo is designed as a separate Vue component, inside which all the magic happens. The component uses the full power of the Vue ecosystem, as can be seen from the imports

import { computed, nextTick, onMounted, onUnmounted, reactive, ref } from 'vue'
import { useSpring } from 'vue-use-spring'
import {
  useMouse,
  useEventListener,
  useDebounceFn,
  useIdle,
  whenever,
} from '@vueuse/core'

This approach works great for Vue, but what if you need to embed an animated SVG file on a React website? Fortunately, SVG can be animated without frameworks. It should be noted right away that SVG animations can be created using various tools such as SVGator, but browser APIs are sufficient for simple animations. In general, I identify four types of SVG animation:

SMIL animation,
pure CSS animation,
attribute driven CSS animation and direct styles manipulation via JS,
Web Animations API.

We'll look at all of these options using a practical example - I created a character that Pinia might be familiar with.

Meet Mr. Pearman

To animate an SVG, you need to be sure of the correct structure and layer placement. When using ready-made SVGs, you need to be prepared for limitations and adapt to its styles. That's why I prefer to design the character behavior first and then implement it myself. This serious guy was created with Inkscape.

For this character, I plan to animate:

cape movement (to make it look more epic),
facial expressions when hovered over (this guy doesn't like being pointed at),
color change when clicked (his mood gradually worsens after each click, but returns to its original state after the cursor moves out),
working out with a dumbbell while waiting for the cursor movement (Mr. Pearman has to be strong to do justice).

A good solution is to group elements that should or can be transformed at the same time. I also recommend checking in an SVG editor how the image should look at different points in the animation to make sure you've made the right choice. And the most important thing is not to complicate the SVG.

Once the image is ready, you can start writing the animation in any text editor.

Animating Mr. Pearman

The SMIL animation looks the most organic for SVG. Essentially it all comes down to choosing the right element (animate, animateTransform, animateMotion) and passing the correct attributes. I will use animate to realize the cape emovement:

<path
     style="fill:#4b7229;fill-opacity:1;stroke-width:0.264583"
     d="m 146.05723,123.12633 c 0,0 41.89228,89.47314 45.40039,99.76848 3.50811,10.29534 -8.11042,8.66023 -14.26613,6.44205 -4.60132,-1.65806 -4.47508,-6.82347 -12.01742,-5.92669 -5.21874,0.6205 -7.61486,8.14833 -12.74747,9.27818 -16.81689,3.70192 -33.45177,-10.04425 -50.67129,-10.05122 -18.861521,-0.008 -36.908207,14.0719 -55.512045,10.96477 -4.649159,-0.77648 -7.517475,-6.97037 -12.229259,-7.09955 -5.107148,-0.14002 -8.571991,7.45123 -13.657138,6.95742 -4.019026,-0.39028 -10.8529692,-3.65626 -9.53423,-7.47278 18.178826,-52.61078 46.809504,-105.37833 46.809504,-105.37833 z"
>
    <animate
        attributeName="d"
        dur="4s"
        repeatCount="indefinite"
        fill="freeze"
        values="m 146.05723,123.12633 c 0,0 41.89228,89.47314 45.40039,99.76848 3.50811,10.29534 -8.11042,8.66023 -14.26613,6.44205 -4.60132,-1.65806 -4.47508,-6.82347 -12.01742,-5.92669 -5.21874,0.6205 -7.61486,8.14833 -12.74747,9.27818 -16.81689,3.70192 -33.45177,-10.04425 -50.67129,-10.05122 -18.861521,-0.008 -36.908207,14.0719 -55.512045,10.96477 -4.649159,-0.77648 -7.517475,-6.97037 -12.229259,-7.09955 -5.107148,-0.14002 -8.571991,7.45123 -13.657138,6.95742 -4.019026,-0.39028 -10.8529692,-3.65626 -9.53423,-7.47278 18.178826,-52.61078 46.809504,-105.37833 46.809504,-105.37833 z;
        m 146.05723,123.12633 c 0,0 33.46693,74.61111 35.60848,80.44234 2.14155,5.83123 4.11806,9.17987 2.2934,10.56986 -5.76505,4.39171 -9.62872,-1.92751 -17.17106,-1.03073 -5.21874,0.6205 -5.23418,7.59514 -9.26877,9.27818 -17.15536,7.15639 -37.18589,0.86369 -55.76397,0.25115 -14.805226,-0.48815 -25.545341,1.96964 -44.329665,-3.12698 -4.844665,-1.31447 -14.28973,0.65633 -21.238085,-0.7204 -4.016258,-0.79577 -6.395465,-6.68193 -11.50726,-4.29596 -3.574065,1.66822 -10.079924,2.27042 -8.761185,-1.5461 18.178826,-52.61078 41.713027,-92.33903 41.713027,-92.33903 z;
        m 146.05723,123.12633 c 0,0 41.89228,89.47314 45.40039,99.76848 3.50811,10.29534 -8.11042,8.66023 -14.26613,6.44205 -4.60132,-1.65806 -4.47508,-6.82347 -12.01742,-5.92669 -5.21874,0.6205 -7.61486,8.14833 -12.74747,9.27818 -16.81689,3.70192 -33.45177,-10.04425 -50.67129,-10.05122 -18.861521,-0.008 -36.908207,14.0719 -55.512045,10.96477 -4.649159,-0.77648 -7.517475,-6.97037 -12.229259,-7.09955 -5.107148,-0.14002 -8.571991,7.45123 -13.657138,6.95742 -4.019026,-0.39028 -10.8529692,-3.65626 -9.53423,-7.47278 18.178826,-52.61078 46.809504,-105.37833 46.809504,-105.37833 z"
    />
</path>

As you can see SMIL allows to realize SVG path morphing, while CSS solution is still not baseline.

Pure CSS animations are my favorite in most cases, allowing to attach animations and transitions not only to elements but also to their pseudo-states. Here I will use the following CSS to animate :hover pseudostate:

<style>
    #mouth {
        transition: transform 200ms linear;
        transform-origin: center;
    }
    #right_eye > *, #left_eye > * {
        transition: ry 200ms linear;
    }
    #left_eyebrow {
        transition: transform 200ms linear;
        transform-origin: center;
    }

    svg:has(#figure:hover) {
        #mouth {
            transform: skewY(-10deg);
        }

        #right_eye > *, #left_eye > * {
            ry: 2px;
        }

        #left_eyebrow {
            transform: skewY(10deg);

        }
    }
</style>

To implement a color change animation, we need to store and compare states - this is where JS comes in handy. In fact, you'll only end up here if you're lacking in CSS or SMIL capabilities. We will simply set a new attribute value based on its current value, and at the end of the timeout, we will return the initial color:

<style>
    svg {
        transition: filter 250ms linear;
        filter: grayscale(0%);
    }
    #figure {
        cursor: pointer;
    }

    svg[data-lvl="1"] {
        filter: grayscale(30%) contrast(150%);
    }
    svg[data-lvl="2"] {
        filter: grayscale(70%) contrast(200%);
    }
    svg[data-lvl="3"] {
        filter: grayscale(100%) contrast(200%);
    }
</style>
<script type="text/javascript">
    //<![CDATA[
    const svg = document.currentScript.parentElement;
    const figure = svg.querySelector('#figure');

    figure.addEventListener('click', () => {
        const level = +svg.dataset.lvl || 0;
        if (level < 3) {
        const nextLevel = level + 1;
        svg.dataset.lvl = nextLevel;
        }
    });

    figure.addEventListener('mouseleave', () => {
        delete svg.dataset.lvl;
    });
    //]]>
</script>

Sometimes it becomes necessary to dynamically identify keyframes and accurately monitor the progress of animation - this is where the Web Animations API comes to the rescue. Before using this tool, I always ask myself the question - do I really need it? Sometimes the reason for the complexity of the code is poor documentation of requirements, so it's better to clarify all the conditions and understand the scenario before starting to implement it. CSS and attribute bindings may be enough for you. Let's use the API to create training animations that depend on whether the cursor is over Pearman:

<style>
    #left_hand_bottom {
        transform-origin: 25.639345px 180.89267px;
    }
</style>
<script
    type="text/javascript"
    id="script3"
>
    //<![CDATA[
    const doc = document.documentElement;
    const svgElem = document.currentScript.parentElement;
    const hand = svgElem.querySelector('#left_hand_bottom');
    const figureElem = svgElem.querySelector('#figure');

    let timeoutId;
    let animation;
    let reset;

    function start() {
        if (hand.getAnimations().length) return;
        else if(figureElem.matches('*:hover')) {
        animation = hand.animate([
            {
                transform: 'rotate(0deg)'
            },
            {
                transform: 'rotate(-65deg)'
            },
            {
                transform: 'rotate(0deg)'
            }
        ], {
            duration: 8000, easing: 'cubic-bezier(.2,.34,0,1.05)', iterations: 'Infinity'
        });
        } else {
        animation = hand.animate([
            {
                transform: 'rotate(0deg)'
            },
            {
                transform: 'rotate(-45deg)'
            },
            {
                transform: 'rotate(0deg)'
            }
        ], {
            duration: 2000, easing: 'ease', iterations: 'Infinity'
        });
        }
    }

    function stop() {
        if (animation && !reset) {
        animation.pause();
        reset = hand.animate([
            {
                transform: 'rotate(0deg)'
            }
        ], {
            duration: 500, easing: 'ease'
        });
        reset.finished.then(() => {
            animation.cancel();
            animation = undefined;
            reset.cancel();
            reset = undefined;
        });
        }
    }

    doc.addEventListener('mousemove', () => {
        clearTimeout(timeoutId);
        stop();
        timeoutId = setTimeout(() => start(), 5000);
    });
   //]]>
</script>

The Web Animation API is so powerful that it cannot be described in one example. But with great power comes great responsibility, and the likelihood of mistakes also increases. Therefore, I rather consider it as a foundation for writing specialized libraries than as a direct animation tool.

So, we can collect all the animations in one SVG to simply use in a browser. As a result, we get the following SVG

As you can see, SVG is embedded directly into the HTML document so that its scripts can reach the document. There is also the option of embedding interactive SVGs via iframe, but then they will be in their own HTML document. This is one of the nuances to keep in mind - a regular img tag will not show all the embedded animations. This is why Pinia can catch cursor movements - it is built into the Vue component.

Conclusion

In fact, I'm really inspired by the fact that we can animate almost anything in the browser without any external dependencies. And interactive SVGs can not only attract attention but also make a website more lively and interesting. The key with animation is not to overdo it.

Like any front-end component, animation should serve a purpose, not just distract from the task at hand. And if you focus on small features, there will usually be enough CSS animations to make the site pleasant to interact with.

In addition, you need to be prepared to embed SVG containing scripts directly into HTML or via an iframe. This is not always acceptable, and extra scripts on the page can cause chaos.

I hope that the world of SVG animations has become closer to you after reading.

Enjoy your Frontend Development!

CSS only components

Marat Sabitov — Sun, 08 Mar 2026 12:03:37 +0000

Modern CSS has become so powerful that the basic layout can be styled without using third-party tools. And simple user interface templates can be described using pure CSS. Let's look at an example in which we will try to create a simple CSS component, organizing it in the manner of React.

Initial styles

Let's imagine that we are describing a button group component that defines both its own and nested button styles, including for :hover and :active states:

.btn {
  width: calc(100% * var(--offset) / 2);
  border-radius: calc(1rem * (var(--offset) - 1));
  background-color: var(--neutral-color);
}

.btn-group {
  display: flex;
  gap: 0.25rem;
  margin: 1rem 0;

  & > * {
    flex: 1 1 auto;
    padding: 0.5rem;
    background: oklch(from currentColor 0.8 calc(c / 4) h / 0.2);
    border: none;
    cursor: pointer;
    transition: all 100ms ease-in 0s;
    transition-property: background translate box-shadow;

    &:hover {
      background: oklch(from currentColor 0.8 calc(c / 4) h / 0.6);
      box-shadow: 0 0.2rem 0 currentColor;
    }
    &:active {
      translate: 0 0.2rem;
      box-shadow: 0 0 0 currentColor;
    }
  }
}

For now, it's just CSS that can't be customized. At the same time React component can accept props and have a state. Let's try to implement similar mechanics.

Thinking in React way

The component's props allow you to customize its behavior from the outside. Let's say I want to be able to adjust the color of the button, the size of the shadow, and the duration of the transition.

Component states are something that can change according to internal logic and affect the final rendering. If you look at the initial example, you can highlight such states as the value of the alpha channel of the button color, the size of the shadow, and the value of the button translate property.

Then we will get the following code:

.btn-group-component {
  /* props */
  --color-prop: currentColor;
  --shadow-size-prop: 0.2rem;
  --duration-prop: 100ms;

  /* state */
  --alpha-state: 0.2;
  --shadow-size-state: 0;
  --translate-state: 0;

  /* render */
  display: flex;
  gap: 0.25rem;
  margin: 1rem 0;

  & > * {
    flex: 1 1 auto;
    padding: 0.5rem;
    background: oklch(from var(--color-prop) 0.8 c h / var(--alpha-state));
    box-shadow: 0 var(--shadow-size-state) 0 var(--color-prop);
    translate: 0 var(--translate-state);
    border: none;
    cursor: pointer;
    transition: all var(--duration-prop) ease-in 0s;
    transition-property: background translate box-shadow;

    &:hover {
      --alpha-state: 0.6;
      --shadow-size-state: var(--shadow-size-prop);
    }

    &:active {
      --translate-state: var(--shadow-size-prop);
      --shadow-size-state: 0;
    }
  }
}

So we have defined special CSS variables for props and states, but we forgot that each React component has its own scope and name. Let's fix this:

@scope (btn-group) {
  /* props */
  --color-prop: currentColor;
  --shadow-size-prop: 0.2rem;
  --duration-prop: 100ms;

  /* state */
  --alpha-state: 0.2;
  --shadow-size-state: 0;
  --translate-state: 0;

  /* styles */
  :scope {
    display: flex;
    gap: 0.25rem;
    margin: 1rem 0;

    & > * {
      flex: 1 1 auto;
      padding: 0.5rem;
      background: oklch(from var(--color-prop) 0.8 c h / var(--alpha-state));
      box-shadow: 0 var(--shadow-size-state) 0 var(--color-prop);
      translate: 0 var(--translate-state);
      border: none;
      cursor: pointer;
      transition: all var(--duration-prop) ease-in 0s;
      transition-property: background translate box-shadow;

      &:hover {
        --alpha-state: 0.6;
        --shadow-size-state: var(--shadow-size-prop);
      }

      &:active {
        --translate-state: var(--shadow-size-prop);
        --shadow-size-state: 0;
      }
    }
  }
}

@scope helps to use contextual proximity to resolve conflicts between styles. Additionally, it visually highlights the isolation of styles within their context. However, I would like to pass React style properties as separate HTML attributes rather than a single string within the style attribute. Fortunately, this future is just around the corner.

`attr()` will change all

Imagine what will happen if the attr() function can be used in arbitrary CSS properties - then HTML attributes can be used as real component props:

@scope (btn-group) {
  /* props */
  --color-prop: attr(color type(<color>), currentColor);
  --shadow-size-prop: attr(shadow-size type(<length>), 0.2rem);
  --duration-prop: attr(duration type(<time>), 100ms);

  /* state */
  --alpha-state: 0.2;
  --shadow-size-state: 0;
  --translate-state: 0;

  /* styles */
  :scope {
    display: flex;
    gap: 0.25rem;
    margin: 1rem 0;

    & > * {
      flex: 1 1 auto;
      padding: 0.5rem;
      background: oklch(from var(--color-prop) 0.8 c h / var(--alpha-state));
      box-shadow: 0 var(--shadow-size-state) 0 var(--color-prop);
      translate: 0 var(--translate-state);
      border: none;
      cursor: pointer;
      transition: all var(--duration-prop) ease-in 0s;
      transition-property: background translate box-shadow;

      &:hover {
        --alpha-state: 0.6;
        --shadow-size-state: var(--shadow-size-prop);
      }

      &:active {
        --translate-state: var(--shadow-size-prop);
        --shadow-size-state: 0;
      }
    }
  }
}

Just one feature can change the way you approach web styling. Just try it in Chrome to feel the power.

Your can explore all code examples with StackBlitz:

Final thoughts

I think that the CSS-only approach, which has been promoted so long and hard with Bootstrap, Tailwind, Bulma, and many other frameworks, is finally taking shape. But now, CSS can be more than just a collection of utilities or classes; it can be a complete set of components. And I'm looking forward to having the attr() function for all properties becoming widely available.

Enjoy your Frontend Development!

Useful TypeScript generics for tree structures

Marat Sabitov — Mon, 23 Feb 2026 10:03:41 +0000

Developers are surrounded by hierarchies of objects, such as the DOM tree, React component tree, and NPM dependency tree. Tree-like data structures are quite common in code, and reliable Typescript types make working with them more confident. In this article, I want to share with you some generics that benefit me the most.

Deep partial

Sometimes we are willing to provide default values for all parameters of a third-party function, even nested ones, so they are all optional. In that case DeepPartial type is helpful:

type DeepPartial<T> = T extends object
    ? {
          [P in keyof T]?: DeepPartial<T[P]>;
      }
    : T;

type InitialType = {
    header: {
        size: 'sm' | 'md' | 'lg';
        color: 'primary' | 'secondary';
        nav: {
            align: 'left' | 'right';
            fontSize: number;
        }
    };
    footer: {
        fixed: boolean;
        links: {
            max: 5 | 10;
            nowrap: boolean;
        }
    }
};

type ResultType = DeepPartial<InitialType>;
/*
type ResultType = {
    header?: {
        size?: "sm" | "md" | "lg" | undefined;
        color?: "primary" | "secondary" | undefined;
        nav?: {
            align?: "left" | "right" | undefined;
            fontSize?: number | undefined;
        } | undefined;
    } | undefined;
    footer?: {
        fixed?: boolean | undefined;
        links?: {
            max?: 5 | 10 | undefined;
            nowrap?: boolean | undefined;
        } | undefined;
    } | undefined;
};
*/

Paths

Another case is that you need to infer all the available tree paths as a type. Paths generic can solve this:

type Paths<T> = T extends object ? {
        [K in keyof T]: `${Exclude<K, symbol>}${
            '' | Paths<T[K]> extends '' ? '' : `.${Paths<T[K]>}`
        }`;
    }[keyof T] : never;

type InitialType = {
    header: {
        size: 'sm' | 'md' | 'lg';
        color: 'primary' | 'secondary';
        nav: {
            align: 'left' | 'right';
            fontSize: number;
        }
    };
    footer: {
        fixed: boolean;
        links: {
            max: 5 | 10;
            nowrap: boolean;
        }
    }
};

type ResultType = Paths<InitialType>;
/*
type ResultType = "header.size" | "header.color" | "header.nav.align" |
"header.nav.fontSize" | "footer.fixed" | "footer.links.max" |
"footer.links.nowrap";
*/

Sometimes path should include leaves, so you can use the next generic:

type Paths<T> = T extends object ? {
        [K in keyof T]: `${Exclude<K, symbol>}${
            '' | Paths<T[K]> extends '' ?
                '' :
                `.${Paths<T[K]>}`
            }`;
    }[keyof T] : T extends string | number | boolean ? T : never;

type InitialType = {
    header: {
        size: 'sm' | 'md' | 'lg';
        color: 'primary' | 'secondary';
        nav: {
            align: 'left' | 'right';
            fontSize: number;
        }
    };
    footer: {
        fixed: boolean;
        links: {
            max: 5 | 10;
            nowrap: boolean;
        }
    }
};

type ResultType = Paths<InitialType>;
/*
type ResultType = "header.size.sm" | "header.size.md" | "header.size.lg" |
"header.color.primary" | "header.color.secondary" | "header.nav.align.left" |
"header.nav.align.right" | `header.nav.fontSize.${number}` |
"footer.fixed.false" | "footer.fixed.true" | "footer.links.max.5" |
"footer.links.max.10" | "footer.links.nowrap.false" |
"footer.links.nowrap.true";
*/

You may notice a strange element header.nav.fontSize.${number} in the ResultType. It appears due to the fact that the fontSize parameter can take an infinite number of values. We can modify the generic to eliminate such paths:

type Paths<T> = T extends object ? {
        [K in keyof T]: `${Exclude<K, symbol>}${
            '' | Paths<T[K]> extends '' ? '' : `.${Paths<T[K]>}`
        }`;
    }[keyof T] : T extends string | number | boolean ?
    `${number}` extends `${T}` ? never : T :
    never;

type InitialType = {
    header: {
        size: 'sm' | 'md' | 'lg';
        color: 'primary' | 'secondary';
        nav: {
            align: 'left' | 'right';
            fontSize: number;
        }
    };
    footer: {
        caption: string;
        fixed: boolean;
        links: {
            max: 5 | 10;
            nowrap: boolean;
        }
    }
};

type ResultType = Paths<InitialType>;
/*
type ResultType = "header.size.sm" | "header.size.md" | "header.size.lg" |
"header.color.primary" | "header.color.secondary" | "header.nav.fontSize" |
"header.nav.align.left" | "header.nav.align.right" | "footer.caption" |
"footer.fixed.false" | "footer.fixed.true" | "footer.links.max.5" |
"footer.links.max.10" | "footer.links.nowrap.false" |
"footer.links.nowrap.true";
*/

Nodes and Leaves

In many algorithms, it is necessary to distinguish the nodes of the tree from the leaves. If we consider those parameters that have object values as nodes, then we can apply the following generics:

type Nodes<T> = T extends object ? {
        [K in keyof T]: T[K] extends object ?
            (
                `${Exclude<K, symbol>}` |
                `${Exclude<K, symbol>}.${Nodes<T[K]>}`
            ) : never;
    }[keyof T] : never;

type Leaves<T> = T extends object ? {
    [K in keyof T]: `${Exclude<K, symbol>}${
            Leaves<T[K]> extends never ? "" : `.${Leaves<T[K]>}`
        }`
    }[keyof T] : never;

type InitialType = {
    header: {
        size: 'sm' | 'md' | 'lg';
        color: 'primary' | 'secondary';
        nav: {
            align: 'left' | 'right';
            fontSize: number;
        }
    };
    footer: {
        caption: string;
        fixed: boolean;
        links: {
            max: 5 | 10;
            nowrap: boolean;
        }
    }
};

type ResultNodes = Nodes<InitialType>;
type ResultLeaves = Leaves<InitialType>;
/*
type ResultNodes = "header" | "footer" | "header.nav" | "footer.links";
type ResultLeaves = "header.size" | "header.color" | "header.nav.align" |
"header.nav.fontSize" | "footer.fixed" | "footer.caption" |
"footer.links.max" | "footer.links.nowrap";
*/

Conclusion

As you can see, Typescript has the necessary flexibility to simplify your code. And although tree structures seem to be quite complex, generics help to cope with them without types duplication. I hope that you have found something interesting in this article.

Enjoy your frontend development!

You don't need CSS preprocessor

Marat Sabitov — Sun, 08 Feb 2026 09:49:49 +0000

There was a time when CSS preprocessors seemed like a magical elixir for any CSS problems. It was only necessary to learn a new syntax, set up the environment and add several dependencies to your project. But as time passed, web technologies developed, and preprocessors seemed to remain in their own isolated world. So right now I don't see any reason to use these tools in development.

Let's take a look at what preprocessors offer us, and how valuable their features are at the moment.

Variables, Nesting, Operations and Scope

Modern CSS has matured significantly compared to its original version. Now you can create variables using @property, limit the scope of selectors using @scope, describe complex operations with calc and use nested CSS rules. Therefore, such features are no longer advantages.

Mixins, Maps and Functions

Сomplex data structures such as Mixins, Maps and Functions seem to be a real advantage of preprocessors. But don't you think that there is already a programming language in web development that has been able to do all this for a long time?

The very concept of CSS-in-JS has an important message - not to invent a new programming language, but to use JavaScript. And browsers have supported this concept with a class of CSS constructed StyleSheets. Constructed stylesheet can be added to the HTML Document and to the HTML Element ShadowRoot. This makes it easier to reuse styles and dynamically change them. Besides this has radically changed the balance of power.

Take a look at the following mixin example from the Sass documentation:

@mixin theme($theme: DarkGray) {
  background: $theme;
  box-shadow: 0 0 1px rgba($theme, .25);
  color: #fff;
}

.info {
  @include theme;
}
.alert {
  @include theme($theme: DarkRed);
}
.success {
  @include theme($theme: DarkGreen);
}

You can replace it using JS:

const DarkGray = '169, 169, 169';
const DarkRed = '139, 0, 0';
const DarkGreen = '0, 100, 0';

function theme(value = DarkGray) {
    return `background: ${value};` +
        `box-shadow: 0 0 1px rgba(${value}, 0.25);` +
        'color: #fff;';
}

const sheet = new CSSStyleSheet();
sheet.replaceSync(
    `.info{${theme()}}` +
    `.alert{${theme(DarkRed)}}` +
    `.success{${theme(DarkGreen)}}`
);

Next, let's take a look at the example of maps usage from the Less documentation:

#colors() {
  primary: blue;
  secondary: green;
}

.button {
  color: #colors[primary];
  border: 1px solid #colors[secondary];
}

You can simplify it using JS:

const COLORS = {
    primary: 'blue',
    secondary: 'green'
};

const sheet = new CSSStyleSheet();
sheet.replaceSync(
  `.button {` +
  `color: ${COLORS.primary};` +
  `border: 1px solid ${COLORS.secondary};` +
  `}`
);

Finally, let's take a look at an example of functions from the Stylus documentation:

add(a, b)
  a + b

sub(a, b)
  a - b

invoke(a, b, fn)
  fn(a, b)

body
  padding invoke(5, 10, add)
  padding invoke(5, 10, sub)

Well it's too simple for JS:

const add = (a, b) => a + b;
const sub = (a, b) => a - b;
const invoke = (a, b, fn) => fn(a, b);

const sheet = new CSSStyleSheet();
sheet.replaceSync(
  `body {` +
  `padding: ${invoke(5, 10, add)};` +
  `padding: ${invoke(5, 10, sub)};` +
  `}`
);

It looks like all the features of CSS preprocessors can be implemented using pure JS. Without dependencies. Without binding to the framework. So what price do you have to pay for using preprocessors?

At what cost?

Let's walk the path of working with a CSS preprocessor.

Our first step is to install a preprocessor, so I suggest taking a look at the Package Phobia report for Sass, Less, and Stylus:

Well, these are not particularly lightweight libraries. But what can you not do for the sake of new experiences.

Our second step is to master the syntax of the library. This definitely entails spending time and mental effort. Let's say we're smart enough to do it in less than a week.

Our third step is to set up the build tools. It is quite easy (Praise be to Vite!). But then there is an awareness of the problem.

We just moved away from CSS to come back. It was an exciting adventure but we got the usual static CSS at the output. Is the cost fair?

I'm sure someone will say, look, you've saved so much time than if you were writing in pure CSS. But I spent a lot more effort than I would have written in pure JS.

In addition, the new syntax always imposes its own limitations. And the most important limitation is the scope of application. CSS preprocessors solve only one problem, which is now easy to solve without them.

Final thoughts

In my opinion, using a CSS preprocessor is like flying in a hot air balloon. The destination will be reached, but with less comfort than by plane.

I think that the constructed stylesheets have completely changed the balance, now everything that is not implemented in CSS can be done directly using JS. And now it makes sense to create any CSS-in-JS solution only on top of constructed stylesheets. When I started using them, I lacked TypeScript support, server-side rendering, and selectors minification, which is why the idea of EffCSS was born.

It is useful to know about CSS preprocessors. It will be great to add them to your resume. But, it's hardly worth using them.

Enjoy your Frontend Development!

Bundle size badges are just numbers

Marat Sabitov — Wed, 28 Jan 2026 15:15:45 +0000

While exploring GitHub or NPM you can see that many packages use badges - small rectangles that show package metrics and characteristics. I noticed that these badges are often perceived as indicators of the package quality. This is especially true for the bundle size badges, which use beautiful numbers and a green background to manipulate our choice. I suppose these badges are not what they seem at first glance and in practice mean nothing.

To make the article more visual, let's look at such popular CSS-in-JS libraries as Emotion CSS and Styled Components as an example.

Reason #1: bundle size !== package install size

There are two excellent services for estimating package size - Bundlephobia and Package Phobia. While the first calculates "bundle size", the second calculates "publish size" and "install size".
The "install size" is the result of recursively summing up all the package dependencies. The result of such an evaluation may surprise.

Firstly, let's take a look at the libraries badges. We are interested in gzip size and minzipped size:

Then let's look at the Package Phobia reports:

It's a pretty strong difference. The most surprising thing for me is that the install size of the framework-agnostic @emotion/css library exceeds its highly specialized competitor. This brings us to the second point.

Reason #2: bundle size !== feature-richness

Typically, the core library provides only basic functionality. This is a perfectly reasonable approach — you only load what's really needed. But on the other hand, the library author can move almost everything out of the core to achieve a minimal bundle size — and voila, beautiful bundle badges are ready.

This also relates to framework integrations. You can create framework agnostic core and lots of integrations. So actually, let's replace @emotion/css with @emotion/react. Now these libraries should be at least comparable across the framework. By the way, this version contains more different features, for example, it supports server rendering (via @emotion/server).

So, the Package Phobia report is already done.

Well, it was expected. The publish size has increased several times compared to the original, which is the price for new features. Thus, we see two approaches to feature packaging: distributed and monolithic. This division is somewhat arbitrary, because we cannot define a clear boundary between extreme cases, but simply indicate which side is closer. And this fuzziness brings us to the third point.

Reason #3: bundle size !== code performance

In Web Development high performance is often associated with a small bundle size, as pages with large resources can delay the first rendering. But if you open the Performance DevTools Panel, you will see that it is more complex. And the bottom line is that your page metrics reflect the state of the entire page, not the performance of a single library. Of course, you can compare tools in test examples. By the way, such a comparison of Emotion CSS and Styled Components has already been described in another article. But how significant is this?

The result of the work is determined not only by the tools, but also by your skills. You can have the most effective tool, but not be able to handle it, and vice versa. With experience, your skills determine the quality of the product to a greater extent.

If we go back to our examples, we need to evaluate which features of these tools are really needed. And it's always useful to evaluate native capabilities. Modern CSS allows you to flexibly customize theme via @property, isolate selectors via @scope, and write queries via @container. Also you can add or change styles dynamically via constructed stylesheets. Using native Browser APIs you can achieve success with less effort and less dependencies. Therefore, sometimes it is most effective not to use additional packages at all.

Final thoughts

So what can we say about bundle size badges?

They don't show how lightweight a package is.
They don't show how feature-rich a package is.
They don't show how effective a package is.

They are just numbers. I think these numbers only show the package author's approach to coding and bundling. It's probably weird to evaluate this on the positive or negative side.

And I hope that you will not judge the packages only by their bundle size badges.

Enjoy your Frontend Development!

CSS @scope: advanced nesting

Marat Sabitov — Sun, 18 Jan 2026 08:20:46 +0000

When you write complex CSS rules, you often have to handle style conflicts. The concepts of cascade and specificity significantly affect the final CSS, so sometimes it becomes difficult to understand and maintain it. CSS nesting seems like a better alternative to create visually сlear code, and along with @scope it offers completely new possibilities for grouping and isolating CSS rules. Such power is often taken too literally, which leads to some misconceptions about @scope. Let's dispel common myths and take a pragmatic look at the @scope real power.

Myth #1: `@scope` fully isolates styles

No, it doesn't. CSS property inheritance is not prevented. Properties such as font-size, font-weight, color can use the computed value of the parent element - in other words they can cross the @scope limit. If this is critical, you can explicitly use the initial value.

Myth #2: `@scope` has the highest-priority

Actually, importance, layers, and specificity have higher priority. Therefore, reducing the specificity of the rules using scope may rather weaken your CSS styles in relation to others. This should always be kept in mind.

Myth #3: `@scope` is better to use with type selectors

You'll probably agree with me that CSS classes can be too long and verbose (especially when you are using BEM). And I've already read a lot of articles about how the @scope syntax allows you to avoid this through type selectors. But there is one nuance - this way is how your CSS force HTML to use specific elements and semantics. Take a look at the following code example:

@scope (.feature) {
  img {
    border: 5px solid black;
    background-color: goldenrod;
  }
}

<div class="feature">
    <img />
</div>

Everything works fine as long as you only use <img/>. But, for example, you decide to use a ready-made third-party <Avatar/> component:

<div class="feature">
    <Avatar />
</div>

and <Avatar/> has structure:

<div class="outer">
    <img class="inner"/>
</div>

Then your CSS will try to interfere with the internal styles of <Avatar/>. This is usually not what we want to do. Components encapsulate their behavior and styles. They only expect parameters from you, not intervention. Therefore, any type selectors actually only limit styles, not make them better. And @scope may well do without them.

`@scope` real power

In my opinion, the most promising feature of the @scope is the ability combine it with @property at-rules. Just look at the next code block:

@scope (.list) {
    @property --list-bg {
        inherits: false;
        syntax: "<color>";
        initial-value: aquamarine;
    }
    @property --list-rounded {
        inherits: false;
        syntax: "<integer>";
        initial-value: 0;
    }

    :scope {
        --list-item-offset: 1rem;
        background-color: var(--list-bg);
        border-radius: calc(1rem * var(--list-rounded));
        width: 100%;

        &.rounded {
            --list-rounded: 1;
        }
        &.primary {
            --list-bg: grey;
        }
        &.secondary {
            --list-bg: purple;
        }
        &.offset-s {
            --list-item-offset: 0.5rem;
        }
        &.offset-l {
            --list-item-offset: 2rem;
        }
    }

    /* nested scope */
    @scope (.item) {
        @property --item-bg {
            inherits: false;
            syntax: "<color>";
            initial-value: white;
        }
        @property --item-rounded {
            inherits: false;
            syntax: "<integer>";
            initial-value: 0;
        }
        :scope {
            margin: 0 var(--list-item-offset) var(--list-item-offset);
            background-color: var(--item-bg);
            border-radius: calc(1rem * var(--item-rounded));
            width: calc(100% - 2 * var(--list-item-offset));

            &.rounded {
                --item-rounded: 1;
            }
            &.primary {
                --item-bg: coral;
            }
            &.secondary {
                --item-bg: bisque;
            }
        }
    }
}

This is somewhat similar to BEM, but it does not limit the nesting. It's also similar to Atomic CSS, but the utilities here only affect CSS custom properties. The provided CSS can be described using the TypeScript type:

type TStyles = {
    /**
     * List scope
     */
    list: {
        /**
         * List background
         */
        bg?: 'primary' | 'secondary';
        /**
         * Is list rounded
         */
        rounded?: '';
        /**
         * List offset
         */
        offset?: 's' | 'l';
        /**
         * List item scope
         */
        item?: {
            /**
             * Item background
             */
            bg?: 'primary' | 'secondary';
            /**
             * Is item rounded
             */
            rounded?: '';
        };
    };
}

Do you see what I'm getting at?
Scoped CSS styles can describe abstract UI components without HTML binding. And it looks promising.

Final thoughts

In the previous article, I described multilevel CSS theming using @property at-rule. And in the final example, we saw how @scope allows you to group styles into components. This is exactly what is required at the lower level of theming - specific component styles, grouped, isolated, framework and preprocessor agnostic. Of course, there are still questions about the uniqueness of selectors, their minification, etc., but more on that another time. This time, I just hope inspired you to make your CSS great again.

Enjoy your frontend development!

CSS @property: advanced theming

Marat Sabitov — Thu, 08 Jan 2026 11:05:04 +0000

When it comes to theming a web application, CSS variables turn out to be the simplest and most convenient way. And this is quite logical - you can set the value of a variable once and use it everywhere. But it seems to me that the potential of CSS variables is much broader.

Local variables

The @property CSS at-rule allows to create variables which are not inherits. Thus, these variables are essentially local. This allows you to customize the styles of specific HTML elements without worrying about a cascade of CSS rules. For example, I want to describe a box style where I can configure border radius and background color:

@property --box-radius {
    syntax: "*";
    inherits: false;
    initial-value: 16px;
}
@property --box-background {
    syntax: "*";
    inherits: false;
    initial-value: #a2a3a3;
}

.box {
    background: var(--box-background);
    border-radius: var(--box-radius);
}

.box-dark {
    --box-background: #626262;
}

.box-light {
    --box-background: #d4d6d7;
}

.box-rad-s {
    --box-background: 8px;
}

.box-rad-l {
    --box-background: 32px;
}

Now, if you put one box inside another, the parent element will not override the appearance of the child. In other words, they will have an independent states:

<div class="box box-light box-rad-s">
    Parent box with customized property values
    <div class="box">
        Child box with initial property values
    </div>
</div>

I think you've noticed that the color and size values in the code example are fixed. The best way would be to use global variables as values.

Global variables

The idea is very simple - local variables can take values defined in global variables:

:root {
    --global-background: light-dark(#dedede, #676767);
    --global-radius: 16px;
}

@property --box-radius {
    syntax: "*";
    inherits: false;
}

@property --box-background {
    syntax: "*";
    inherits: false;
}

.box {
    background: var(--box-background, var(--global-background));
    border-radius: var(--box-radius, var(--global-radius));
}

.box-dark {
    --box-background: oklch(from var(--global-background) calc(l - 0.2) c h / alpha);
}

.box-light {
    --box-background: oklch(from var(--global-background) calc(l + 0.2) c h / alpha);
}

.box-rad-s {
    --box-radius: calc(var(--global-radius) / 2);
}

.box-rad-l {
    --box-radius: calc(var(--global-radius) * 2);
}

Now we can have any number of local variables - the entire theme will be determined by only a few global values. But we're losing control of the local variables. If each of them uses its own set of calculations, then this will break the very idea of themization - the styles will not be uniform. So, how to limit them?

Computed variables

Computed variables link global and local variables. They act as a compromise between a large number of theme settings and arbitrary local transformations:


:root {
    /* global vars */
    --global-background: light-dark(#dedede, #676767);
    --global-radius: 16px;

    /* computed vars */
    --radius-s: calc(0.5 * var(--global-radius));
    --radius-m: var(--global-radius);
    --radius-l: calc(2 * var(--global-radius));

    --background-normal: var(--global-background);
    --background-dark: oklch(from var(--global-background) calc(l - 0.2) c h / alpha);
    --background-light: oklch(from var(--global-background) calc(l + 0.2) c h / alpha);
}

/* local vars */
@property --box-radius {
    syntax: "*";
    inherits: false;
}

@property --box-background {
    syntax: "*";
    inherits: false;
}

.box {
    --box-background: var(--background-normal);
    --box-radius: var(--radius-m);
    background: var(--box-background);
    border-radius: var(--box-radius);
}

.box-dark {
    --box-background: var(--background-dark);
}

.box-light {
    --box-background: var(--background-light);
}

.box-rad-s {
    --box-radius: var(--radius-s);
}

.box-rad-l {
    --box-radius: var(--radius-l);
}

Thus, our theme has only six variants for internal styles. Please note that now global and local variables do not interact directly - this is how we separate the external API of the theme and its internal implementation. We impose restrictions to make the styles predictable and uniform.

Final thoughts

I think using three layers of CSS variables makes it easier to customize theme and extend it. It looks like a kind of the Open-Closed Principle -
you can extend theme with new CSS rules and local variables but your global variables remain constant.

In the future the layer of computed variables can be implemented via @function at-rule. This will really protect them from being changed.

Of course, the possibilities of theming are much wider when using JavaScript, with the help of TypeScript, styling becomes more obvious., but that's a completely different story.

Enjoy your frontend development!

CSS-in-TS - a way to improve Development Experience

Marat Sabitov — Sun, 28 Dec 2025 18:41:06 +0000

TypeScript is a modern web development standard. This is an "armor" over JavaScript, which allows you not to be afraid of typos and mistakes (like the armor of Iron Man, because of the feeling of complete control).

But when you enter the territory of CSS, it becomes uncomfortable - you have to look at the implementation of the rules, the names of the selectors. As a result, you can use a CSS file only if you know its contents. In addition, CSS syntax is very limited and quite verbose.

As a frontend developer, I want to use all the features of JavaScript and TypeScript when writing styles - that's why I love CSS-in-JS. But at the same time, I didn't find a CSS-in-TS library that was convenient for me, so I had to create my own.

Let's welcome the EffCSS.

EffCSS

EffCSS suggests first describing the desired result as a TypeScript type, and only then starting to implement it. This type is a contract between those who create styles and those who use them. Even before you start working, you can immediately evaluate which rules are really needed so as not to write unnecessary ones.

For example, I was ordered product card styles:

export type TProductCard = {
    /**
     *  Width utility (use theme vars)
     */
    w: 's' | 'm' | 'l';
    /**
     * Product card
     */
    card: {
        /**
         * Card header
         */
        header: {
            /**
             * Background color
             */
            bg: 'primary' | 'secondary';
            /**
             * Font-weight
             */
            fw: 'bold' | 'light';
            /**
             *  Caption
             */
            caption: {
                /**
                 * Caption position
                 */
                pos: 'l' | 'r' | 'c';
                /**
                 * Is caption hidden
                 */
                hidden: '';
            }
        };
        footer: Record<string, never>;
    };
    /**
     * Product preview
     */
    preview: {
        avatar: {
            /**
             * Border-radius (rem)
             */
            rad: 0 | 1 | 2;
        };
        caption: Record<string, never>;
    }
};

This type fully describes the public API of the stylesheet. In EffCSS, each stylesheet is created using a function called stylesheet maker. It is just a JS function which should return object with styles. I can implement it as follows:

import { TStyleSheetMaker } from 'effcss';

export type TProductCard = {...};

const themeWidth = {
    s: '160px',
    m: '320px',
    l: '480px'
} as const;

export const productCard: TStyleSheetMaker = ({
    select,
    each
}) => {
    // we pass the type
    // so that the selector is checked for compliance with the contract
    const selector = select<TProductCard>;
    return {
        // we form rule for each option
        ...each(themeWidth, (key, val) => ({
            [selector(`w:${key}`)]: {
                width: val
            }
        })),
        [selector('card')]: {
            // card styles
        },
        [selector('card.header')]: {
            // card header styles
        },
        [selector('card.header.bg:primary')]: {
            // card header primary background
        },
        [selector('card.header.bg:secondary')]: {
            // card header secondary background
        },
        [selector('card.header.caption.hidden:')]: {
            // some styles to hide caption
        },
        // and everything like that
    };
};

When you describe each selector using such a call, a legitimate question arises

Why not just create selectors yourself?

In short, because they need to be minified for production. Long and meaningful names are useful for development, but they make the final HTML and CSS heavier. EffCSS allows you to compress these selectors, so you don't have to think about it yourself. In addition, in EffCSS the type of selectors depends on the generation mode - they can be CSS classes or data attributes.

Another reason is the uniqueness of selectors. In each stylesheet, EffCSS uses its own unique prefix and apply it inside select function, so it stops being your headache.

Well, we've done our part. How are things on the other side?

How to use styles

Let's say that your colleague writes on React. He knows that your styles are needed for his layout, how to apply them?

It's very simple here - your colleague creates an instance of EffCSS Style provider and simply passes the stylesheet maker function to the use method. The resulting resolver gives you the ability to use a list or an object with the necessary selectors:

import { useStyleProvider } from 'effcss';
import { productCard } from './productCard';
import type { TProductCard } from './productCard';

// create Style provider
const styleProvider = useStyleProvider({
    attrs: {
        min: true
    }
});

// pass stylesheet maker
const [resolve] = styleProvider.use(productCard);

// resolve selectors
const styles = {
    card: resolve.list<TProductCard>('w:m', 'card'),
    header: resolve.obj<TProductCard>({
        card: {
            header: {
                bg: 'primary',
                fw: 'bold'
            }
        }
    }),
};

export function Component() {
    // and just apply it
    return <div {...styles.card}>
        <div {...styles.header}>Hello, product card!</div>
        <div>...</div>  
    </div>
};

As you can see, the developer does not need to look at your code if you implement the declared stylesheet type. Moreover, EffCSS is framework-agnostic, so your other colleague can reuse styles for example within Svelte components.

Final thoughts

I think separating implementation and usage is exactly what TypeScript is so good at. Therefore, CSS-in-TS is an ideal way to structure styles, isolate, and reuse them.

I will be glad if the article was helpfull. Here are a couple more interesting links

Enjoy your frontend development!

EffCSS. Quick start

Marat Sabitov — Thu, 18 Dec 2025 16:21:14 +0000

In this article, we will look at EffCSS and how to use it in your project.

Main links

Overview

EffCSS is a self-confident CSS-in-JS library which aims to be a simple tool for creating complex and predictable styles. The library is based on several abstractions:

Stylesheet maker is just a JS function that receive an object with utilities as an argument and should return an object or a string with styles; utilities contain some usefull functions that generates pseudo selectors, at-rules, unique selectors etc.,
Style provider is a custom HTMLScriptElement which process and manage stylesheet makers.

It uses common browser APIs such as

As a result, EffCSS does not require any external dependencies. It works the same way in all modern browsers and with any frameworks. You can try it with StackBlitz - there are a lot of example projects in the collection. Is that enough to interest you?

In fact, there may be several other reasons to try EffCSS:

You want to

use a framework-agnostic tool (without "integrations", really agnostic),
use styles multiple times with a TypeScript hints and full JavaScript power,
use styles on the server side without additional settings.

You don't like to

install additional build plugins in a project,
add special extensions to your editor,
learn new syntax.

Did you like at least one? Then let's getting started!

Install

Type in your terminal:

# npm
npm i effcss

# pnpm
pnpm add effcss

# yarn
yarn add effcss

Use

CSS stylesheet can be created by StyleSheet maker function. Let's write it:

import type { TStyleSheetMaker } from 'effcss';

export const maker: TStyleSheetMaker = () => {
    const flexColumn = {
        display: 'flex',
        flexDirection: 'column',
    };
    return {
        html: {
            fontSize: '16px',
        },
        '.card': {
            width: '10rem',
            ...flexColumn,
            '.card__header': {
                height: '2rem',
            },
            '.card__body': flexColumn,
            ':hover': {
                borderRadius: '1rem',
            },
        },
    };
};

Please note that CSS property names can be described in camelCase style. And your function can use external values if there is a need.

Then use Style provider to apply this stylesheet to the page using:

import { useStyleProvider } from 'effcss';
import { maker } from './maker';

const provider = useStyleProvider();
provider.use(maker);

Simple, isn't it?

More complex example

First, we'll connect the provider with the selector minification parameter and pass it down the component tree:

main.js

import { useStyleProvider } from "effcss";

const consumer = useStyleProvider({
    attrs: {
        min: true // to create minified selectors
    }
});

const root = createRoot(document.getElementById("root"));
root.render(<App css={consumer} />);

Then we'll describe the stylesheet using a type, implement it using maker function, and connect it using provider:

App.tsx

import { useRef } from 'react';
import { IStyleProvider, TStyleSheetMaker } from 'effcss';

// you can describe your styles
// so that other people can use them via TypeScript generics
export type TCardMaker = {
    /**
     * Card block
     */
    card: {
        /**
         * Card border radius
         */
        rounded: '';
        /**
         * Card height
         */
        h: 'full' | 'half';
        /**
         * Card logo
         */
        logo: {
            /**
             * Logo width
             */
            w: 's' | 'l';
        },
        /**
         * Card footer
         */
        footer: {
            /**
             * Footer visibility
             */
            visible: '';
            /**
             * Footer size
             */
            sz: 's' | 'm' | 'l';
        };
    };
}

const myStyleSheetMaker: TStyleSheetMaker = ({ select, pseudo, at: { keyframes }, merge, palette, coef, size, units: {px} }) = {
    // specify selector variants via generic
    const selector = select<TCardMaker>;
    // create property with unique identifier
    const widthProperty = property({
        ini: px(200),
        inh: false,
        def: px(200) // will be used as fallback value in `var()` expression
    });
    // create keyframes with unique identifier
    const spin = keyframes({
        from: {
            transform: 'rotate(0deg)',
        },
        to: {
            transform: 'rotate(360deg)',
        },
    });
    // deeply merge objects
    const cardLogoStyles = merge({
        width: widthProperty,
        animation: `20s linear infinite ${spin}`,
        [pseudo.h()]: {
            filter: "drop-shadow(0 0 2em #61dafbaa)",
        }
    }, {
        border: 'none',
        background: palette.pale.xl.alpha(0.8),
        aspectRatio: 1,
        [pseudo.h()]: {
            opacity: 0.5
        }
    });
    return {
        ...sizeProperty,
        ...spin,
        [selector('card')]: {
          // put card styles here
        },
        [selector('card.logo')]: cardLogoStyles,
        [selector('card.logo.w.s')]: {
            ...widthProperty(px(100))
        },
        [selector('card.logo.w.l')]: widthProperty(px(300)),
        [selector('card..rounded')]: {},
        [selector('card..h.full')]: {},
        [selector('card.footer')]: {},
        [selector('card.footer.visible')]: {},
        ...each(coef.short, (k, v) => ({
            [selector(`card.footer.sz.${k}`)]: {
                height: size(v)
            }
        }))
    };
};

export const App = (props: {
    css: IStyleProvider;
}) => {
    const { css } = props;
    const stylesRef = useRef();
    if (!stylesRef.current) {
        const [card] = css.use(myStyleSheetMaker)<TCardMaker>;
        // thanks to the TCardMaker type,
        // you don't need to look at the implementation - just create the necessary attributes
        stylesRef.current = {
            card: card('card..rounded'),
            // element with modifiers
            footer: card({
                card: {
                    footer: {
                        visible: '',
                        size: 'm'
                    }
                }
            })
        };
    }
    const styles = stylesRef.current;
    // just apply attributes to appropriate elements
    return (
        <div {...styles.card}>
            <div {...styles.footer}>...</div>
        </div>
    );
};

As you can see, the selectors are output by EffCSS automatically - you don't need to memorize them, just pass the necessary parameters to the resolver.

This is the whole point of EffCSS - styles can be described as independent resources and applied to any layout.

Explore and use it to the fullest

In fact, there are many more possibilities. To save you time, here are the links to the documentation:

I will be glad if this tool is useful to you. Enjoy your frontend development!

Forem: Marat Sabitov

A journey into the world of animated SVGs

Pinia Alchemy

Meet Mr. Pearman

Animating Mr. Pearman

Conclusion

CSS only components

Initial styles

Thinking in React way

attr() will change all

Final thoughts

Useful TypeScript generics for tree structures

Deep partial

Paths

Nodes and Leaves

Conclusion

You don't need CSS preprocessor

Variables, Nesting, Operations and Scope

Mixins, Maps and Functions

At what cost?

Final thoughts

Bundle size badges are just numbers

Reason #1: bundle size !== package install size

Reason #2: bundle size !== feature-richness

Reason #3: bundle size !== code performance

Final thoughts

CSS @scope: advanced nesting

Myth #1: @scope fully isolates styles

Myth #2: @scope has the highest-priority

Myth #3: @scope is better to use with type selectors

@scope real power

Final thoughts

CSS @property: advanced theming

Local variables

Global variables

Computed variables

Final thoughts

CSS-in-TS - a way to improve Development Experience

EffCSS

Why not just create selectors yourself?

How to use styles

Final thoughts

EffCSS. Quick start

Main links

Overview

Install

Use

More complex example

Explore and use it to the fullest

`attr()` will change all

Myth #1: `@scope` fully isolates styles

Myth #2: `@scope` has the highest-priority

Myth #3: `@scope` is better to use with type selectors

`@scope` real power