Philosophy

Derivation, not aliasing

Most utility frameworks introduce a vocabulary layer. Class names represent CSS values through human-readable aliases.

<!-- 123 chars -->
<div style="display: inline-flex; align-items: center; margin-block-start: 1.5rem; margin-left: 1rem; color: #000000; font-weight: 600;">Blog</div>

<!-- 35 chars -->
<h1 class="d-if ai-c mbs-6 ml-4 c-black fw-600">Blog<h1>

With Yumma CSS, if you know CSS, you already know the class name. Each class is derived from the CSS property and value you would have written anyway.

About semantics

Semantic frameworks optimize for readability, font-semibold reads very naturally. But readability comes at a cost: you need to memorize a separate vocabulary on top of CSS. font-semibold doesn't tell you it's font-weight: 600. items-center doesn't tell you it's align-items, and so on and so forth.

The derivation rule is consistent and predictable. Once you know that jc is the initials of justify-content and c is the initial of center, you can derive jc-c without looking anything up. The same rule gives you jc-fe (flex-end), jc-sb (space-between), and every other value.

There is no vocabulary to memorize on top of CSS. There is only CSS, compressed.

How does it works?

Every class in Yumma CSS maps to exactly one CSS property.

.ai-c {
  align-items: center;
}

.c-white {
  color: #ffffff;
}

.d-f {
  display: flex;
}

.fw-600 {
  font-weight: 600;
}

One class, one property

Every class maps to exactly one CSS property. The generated CSS is transparent and predictable by inspection.

// 1.1kB
<button class="px-3 py-2 bg-indigo h:bg-indigo-8 bc-indigo-7 c-white br-md bw-1 fw-600 c-p">
  Add to Cart
</button>

When Yumma CSS fits

• You know CSS well and want class names that reflect it directly.
• You prefer explicit values (fw-600) over semantic aliases (font-semibold).
• You want predictable output without indirections.
• You're building a design system where consistency and transparency matter.
• You want no new vocabulary to memorize.

When it may not fit

• You rely heavily on a large pre-built component ecosystem.
• Your team is deeply familiar with another framework's vocabulary and the switching cost outweighs the benefit.
• You need official multi-framework UI kits out of the box.