DEV Community: 𝝝̷𝝟̷𝝙̷ 𝝗̷𝝘̷𝝞̷𝝝̷𝝥̷𝝛̷

Universal OKLCH Color System Blueprint: One-Base-Color Design Tokens

𝝝̷𝝟̷𝝙̷ 𝝗̷𝝘̷𝝞̷𝝝̷𝝥̷𝝛̷ — Wed, 08 Jul 2026 20:55:35 +0000

OKLCH Color Systems: One Base Color, Entire Token System

When you hand over a color system to your team, the worst-case scenario is this: your designers pick a brand red, the developers build a palette around it using HSL—and six months later, the mid-tone reds are unreadable over your backgrounds because the lightness formula broke in a way neither of you saw coming.

This article walks through why that happens, how OKLCH fixes it, and introduces CHROMA/1—a framework and tool I've built to generate entire design systems from a single base color, guaranteed perceptually uniform, with light/dark modes, WCAG validation, and components ready to copy.

The HSL Problem

HSL looks intuitive at first: hue (0–360°), saturation (0–100%), lightness (0–100%). You'd think that if you pick L=50 for two colors, they'd look equally bright, right?

Wrong.

hsl(0, 100%, 50%)   /* red — actually looks bright */
hsl(240, 100%, 50%) /* blue — looks much darker */

This is the lightness perception gap. HSL measures lightness mathematically, but human eyes don't perceive it linearly. Yellow and blue at the same L value appear wildly different in actual brightness. This is fine for one-off colors, but the moment you try to scale a palette—say, generating a 50–950 scale for red and blue using the same L curve—the blue steps look wrong because the perceptual jumps are uneven.

Web designers have patched this with tweaks: nudge the saturation down, shift the lightness up, add special cases per hue. It works, but it's brittle and doesn't scale across brands.

OKLCH: Perceptual Linearity

OKLCH is an entirely different approach: it's based on OKLab, a color space engineered for perceptual uniformity.

oklch(L C H)

L (lightness): 0–1, perceptually linear. A step from L=0.3 to L=0.4 looks the same brightness jump as 0.6 to 0.7, across any hue.
C (chroma): how saturated the color is (roughly 0–0.4 for sRGB).
H (hue): 0–360°.

Here's the magic: because L is perceptually uniform, a simple 11-step scale (50, 100, 200, 300, 400, 500, 600, 700, 800, 900, 950) works for every color. Red, blue, yellow—same L values mean same perceived brightness.

/* Red base #990000 */
--color-red-50:  oklch(0.971 0.013 28);
--color-red-500: oklch(0.637 0.237 28);
--color-red-950: oklch(0.250 0.090 28);

/* Blue — same L curve, different hue */
--color-blue-50:  oklch(0.971 0.013 259);
--color-blue-500: oklch(0.637 0.215 259);
--color-blue-950: oklch(0.250 0.070 259);

/* Both 50 look equally light. Both 500 look equally bright. */

One Base Color → Entire System

Here's the insight: if L and C curves are predictable and reusable, you only need one input—the brand color—and everything else derives mathematically.

The Method

Convert input hex to OKLCH: #990000 → oklch(0.429 0.176 29.23)
Find anchor step: Look at the L value (0.429). That's perceptually between step 700–800, so place your brand color at step 800 (the anchor). Don't force it to 500.
Generate scale: Apply the standard L and chroma curves:

   Step 500: L=0.637, C=1.0 × C_peak
   Step 600: L=0.577, C=1.0 × C_peak
   Step 700: L=0.505, C=0.87 × C_peak
   Step 800: L=0.429, C=0.72 × C_peak (← your base sits here)

Derive accent (for CTAs): Rotate hue +180° (complementary), keep L/C structure. Isolated accent = Von Restorff effect = higher click-through.
Derive neutral: Same hue, ultra-low chroma (0.004–0.012) for gray that feels warm/cool depending on brand.
Build semantic tokens: error, warning, success, info get fixed hues (29°, 90°, 145°, 259°) but share the L/C boosts from the system—so they feel like family.
Dark mode: Not an inversion. Background L≈0.14 (not #000), text L≈0.94 (not #fff), accent chroma down 15–30%. Elevate surfaces via lightness, not shadow.

All of that—with full WCAG 2.2 validation—from one hex input.

Practical: CHROMA/1 Studio

I built CHROMA/1 to make this repeatable and visual. It's a single HTML file (works offline, no build step).

Input: one color picker.
Output:
- Interactive scale preview (click any swatch to copy OKLCH value).
- Token diffs: light vs. dark side-by-side, with contrast badges.
- WCAG audit: 6 checks (text, muted text, CTA, each mode).
- 6 real components (navbar, hero, pricing, form, stats, alerts) rendered live with tokens.
- Copy-ready code for each component.
- Export: tokens.css (Tailwind v4), vars-only.css (vanilla), tokens.json (W3C DTCG).

Real-World Use

<!-- Download tokens.css from CHROMA/1 -->
<link rel="stylesheet" href="tokens.css">

<!-- Tailwind v4 picks up @theme automatically -->
<button class="bg-brand-600 text-white">Click me</button>

<!-- Or use CSS variables -->
<button style="background: var(--cta); color: var(--on-cta)">Click me</button>

Toggle light/dark mode on the page to stress-test both token sets in real time.

Why This Matters for Teams

Consistency across brand: One system per brand. Swap the base color, everything else scales.
No guesswork on contrast: OKLCH's perceptual linearity means a rule (L ≥ 0.4 gap = WCAG AA) actually holds.
Dark mode doesn't break: Because you're not inverting—you're re-computing with the same formulas, just different L ranges.
CRO built-in: Token architecture enforces 60-30-10 (neutral/structure/accent), preventing rainbow syndrome. CTA = only accent element on the page.
Accessibility-first: WCAG checks run live; you see failures before shipping.

The Catch: Browser Support

OKLCH as a CSS keyword:

Chrome 111+ ✅
Safari 15.4+ ✅
Firefox 113+ ✅
Edge 111+ ✅

For older browsers, pre-compute hex values and export vars-only.css. The math doesn't change.

Numbers: What Changed Since HSL

Material Design 3 (Google) switched to HCT (a similar approach). Build times for their docs: no dramatic speedup, but consistency improved measurably.

Tailwind CSS v4 moved the entire default palette to OKLCH. From their blog:

"We've upgraded the entire default color palette from RGB to OKLCH, taking advantage of the wider gamut to make colors more vivid where we were previously limited by sRGB."

Teams at Shopify, Figma, Apple (via Adaptive Colors), and Stripe all use perceptually uniform spaces. The pattern is clear.

Try It Yourself

Download chroma1-oklch-studio.html (standalone, no build needed).
Enter your brand color.
Export tokens.
Drop tokens.css into your next Tailwind project.
Swap the base color for a different brand—entire system re-derives, no manual tweaks.

For documentation and Astro 7 scaffold, see the full build at /docs (included in the studio).

Going Deeper

If you want to understand the math:

OKLab: Björn Ottosson's breakdown of OKLab color space.
W3C DTCG: Design Tokens Community Group's spec (reached Candidate Recommendation October 2025).
WCAG 2.2 vs. APCA: WCAG is the legal standard (4.5:1 text); APCA is more accurate for dark mode but still draft.

One More Thing: AI Integration

The studio includes AI asistants (via OpenRouter, model nvidia/nemotron-3-super-120b-a12b:free free tier) that can:

Suggest a brand color from a product description.
Audit your palette for CRO + accessibility gaps.
Name and narrate your palette for design docs.

No Claude API key needed—you bring your own OpenRouter key (free tier available).

CHROMA/1 is open and MIT-licensed. The tool is a single HTML file with zero dependencies (not even Tailwind); the math is vanilla JavaScript. Astro 7 starter kit included.

If you build a color system using OKLCH, or improve on this framework, I'd love to hear about it—drop a comment or reach out.

One color. Entire system. Perceptually sound. No regrets.

What is AMP PWA Offline Generated Page?

𝝝̷𝝟̷𝝙̷ 𝝗̷𝝘̷𝝞̷𝝝̷𝝥̷𝝛̷ — Mon, 24 Feb 2020 16:15:55 +0000

If you've learned about Progressive Web Apps,
you might know that the core of it
is a technology called service worker, a client-side proxy
that sits between your server and web app
to provide things like faster loads
and offline functionality.

But what if you built the most amazing Progressive Web App,
and nobody discovers it?
The problem with service workers is
that they won't make your first page load fast.
On a cold start, your service worker
will only activate on the second page load.

Even though the service worker API
allows you to cache away all of your site's assets
for an almost instant subsequent load,
like when meeting someone new, it's
the first impression that counts.
If the first load takes more than three seconds,
our latest DoubleClick study shows that more than 53%
of all users will drop off.
Don't feel too bad though.
The overall landscape of today's web looks a lot grimmer.

The average mobile page loads in about 19 seconds,
with 77% of it taking longer than 10,
doing 214 survey requests, 50% of which are ad-related.
Yeah.

Take a moment to wipe away your tears.
Turns out we found a solution for the first page load.
And surprise, surprise, we call it AMP.
AMP, short for Accelerated Mobile Pages,
is an ecosystem consisting of web components library that
allows you to declaratively write
HTML we call AMP HTML, because it's
both a superset and a subset.
And AMP caches,
basically CDN's, or more technically correct,
reverse proxies that accelerate the delivery.

Now, if you've already read about the individual advantages
and disadvantages of Progressive Web Apps versus AMP,
you have surely struggled with this question before.

AMP or Progressive Web App?
Instant delivery and optimized delivery, or the latest
advanced platform features and super flexible application
code?

In the end, what matters is the user journey.
The first hop to your site should feel almost instant.
And the browsing experience should get more and more
engaging afterwards.

AMP and Progressive Web App are both critical components
to make this happen AMP pages for the first navigation,
and your Progressive Web App for the onward journey.

There are two ways of combining the two-steps I personally
call AMP up and AMP down.
Now, AMP up is the background bootstrapping
of your Progressive Web App shell.

While the user is enjoying your AMP page.
And then number two, AMP down, describes
reusing AMP pages as a data source for your Progressive Web
App.

So the basics with AMP up are that the first click
will be an AMP page, usually served from the AMP cache.
But any links on that page will navigate
to your Progressive Web App
Now normally, that second click would still
be considerably slower than the instant-feeling, preloaded,
first click to your AMP page.

But there's a powerful component baked into AMP--
the tag.
It allows you to install your service worker
for your origin--
yes, even when your AMP page is served from the AMP cache.

That means while the user is reading the article,
the service worker can warm up and precache
the entire Progressive Web App app
shell and some initial data.

When the user now clicks on any link on the page,
or call to action at the bottom, your Progressive Web App
shows up instantly.

Start fast, stay fast.
This is what I call AMP up.
But now you're in the Progressive Web App,
and chances are most of you are using
some Ajax-driven navigation that fetches content via JSON.

Now, you can certainly do that, but now
you have these crazy infrastructure
needs for two completely different content backends.
One generating AMP pages, and one offering a JSON-based API
for your Progressive Web App.

The AMP team has asked themselves
the logical next question-- what if we could dramatically
simplify backend complexity by ditching the additional JSON
API and instead reusing AMP as a data format for our Progressive
Web App?

We started with a proof of concept many months ago
and iterated on it for a while, rewriting many parts of AMP
to make it a reality.

So how do we do it?
The process looks like this.
The Progressive Web App hijacks navigation clicks,
then does an Ajax request to fetch the requested AMP page.
Third, puts the content into a new Shadow Root.
And fourth, tells the main AMP library, hey,
I have a new document for you.

Check it out.
Which, in other terms, means calls
attachShadow Doc on the runtime.
And then you have things like Shadows Slots
and advanced CSS classes to insert advanced widgets
and functionality into your AMP pages
from the Progressive Web App.

Now of course, you can do that last step manually
by regexing the source of the AMP page,
but the key is that the above is easy for everyone.

OK, finally, time for an even more advanced pattern I
call AMP Konami Code, because it's up, down, left,
right-- all the things.

So we have a pretty good experience now,
but if you are in the Progressive Web App,
copy a link, and share it on Twitter,
that link will open the Progressive Web App directly.

And for a new user who doesn't have a warmed up service worker
cache, it won't feel instant.
That, too, is a problem we can solve in the final step
of our development journey.

Instead of creating a separate URL space for the Progressive
Web App-- for instance, pwa.yourdomain.com/article--
like we did before, we reuse existing AMP URLs
to load the Progressive Web App on the site's origin.

All we need to do for this is to listen for navigation requests
in the service worker.
Then, instead of serving a cached AMP page,
we serve the cached PWA shell, which
then does an XHR to fetch the requested AMP doc.
This means that in just one request,
your Progressive Web App would show up along
with the requested content.

Best of all, we now progressively
enhance our AMP pages with our Progressive Web App.
And showing that no matter what, your users
will get a super fast experience.
For browsers that do not support service worker,
they'll simply see AMP pages.

So now, one additional thing we build
is called fallback URL rewriting.
And this means that even for browsers
that do not support AMP caches, we're giving to you the ability
to rewrite links to another URL space that
is a fallback URL for your Progressive Web App.

And there you got it.
We've successfully combined AMP with a Progressive Web App.
Now the user always gets it fast experience, no matter what.
Your site is progressively enhanced.
You have less backend complexity because you have just one data
source, and profit from the built-in performance of AMP
everywhere, even in your Progressive Web App.

Before I leave you, keep in mind this is just one pattern
to build sites, and it won't work for everyone.
You probably shouldn't build the next Air Horn or Gmail with it,
but focus on sites that have lots of leaf nodes--
individual sites with static content.

By all means, find out if the pattern
is the right one for you, and feel
free to get in touch to discuss.
Check out our React-based demo and learn more about AMP
and Progressive Web Apps individually on amp.dev
and developers.google.com/web.
I can't wait to see what you will build.

Manfaat Dan Pentingnya Website Perusahaan Company Profile

𝝝̷𝝟̷𝝙̷ 𝝗̷𝝘̷𝝞̷𝝝̷𝝥̷𝝛̷ — Sun, 07 Jul 2019 10:12:34 +0000

Manfaat dan Pentingnya Website Company Profile Untuk Perusahaan Anda Perkembangan internet yang semakin pesat telah menyadarkan banyak orang akan pentingnya sebuah layanan yang mudah. Dengan hal itu, tak kita tidak akan kesulitan lagi dalam mencari sebuah informasi. Kini sebuah perusahaan sudah selayaknya memiliki sebuah website yang menjadi ruang untuk calon klien mengetahui tentang perusahaan itu. Dalam website tersebut bisa mencantumkan berbagai hal yang berkaitan dengan perusahaan Anda. Ada banyak manfaat yang bisa didapatkan sebuah perusaan jika mereka memiliki website yang biasa disebut company profile.

Cara Halaman Pertama Pada Hasil Pencarian Google

𝝝̷𝝟̷𝝙̷ 𝝗̷𝝘̷𝝞̷𝝝̷𝝥̷𝝛̷ — Mon, 14 Jan 2019 00:41:51 +0000

Coba search site:blogspot.com di Google. Ketika saya mencobanya beberapa waktu lalu, keluar hasil 321.000.000. Artinya ada 321.000.000 halaman web pada blogspot.com yang terindeks oleh Google. Tentu urusan ranking soal lain. Tapi terindeks saja sudah sudah satu langkah positif. Beberapa diantara halaman-halaman tersebut memiliki ranking yang bagus. Meskipun pada blogspot.com, bukan pada website kita sendiri, memiliki halaman page dengan ranking bagus membawa banyak manfaat. Lalu bagaimana caranya mendapatkan ranking yang tinggi dengan blogspot.