Coder Legion - Recent posts tagged html-css-js

Joy in the Build: What the Positivity Wall Taught Me About Making Anything

Tue, 15 Sep 2026 12:03:26 +0000

I build a lot of things. Chrome extensions, games, internal tools for the day job, weird little browser experiments nobody asked for. Most of it is technical: state management, manifest permissions, load times, edge cases. But every so often a project reminds me that the point of building something isn't the stack you used — it's what it does for the person on the other end of the screen.

That's what happened with the Positivity Wall.

The idea behind it

The Positivity Wall (https://dhseadev.online/positivity-wall/) is a small, quiet corner of my site. No accounts, no typing, no names attached to anything. You show up, and your browser generates a procedural "stamp" — a little visual mark that's yours and yours alone, tied to nine shared panels: Small Wins, Someone Who Helped, Creatures, Made Me Laugh, Outside, On Repeat, Kindness Received, Still Learning, Showed Up. Come back tomorrow and your stamp is still there, identical, still yours. Nothing is uploaded, nothing is recorded beyond a shared count of how many people have marked something good.

It's a tiny piece of software. There's no monetization angle, no growth loop, no funnel. It exists because I wanted to build something that let people acknowledge a good moment without having to perform it for anyone.

The project leans on a philosophy I didn't invent: Amanda Gore's Joy Project. Gore is a Hall of Fame keynote speaker (CPAE, CSP) who's spent about 35 years and reached over 2 million people across 20+ countries with a simple, research-backed argument — feelings drive results. Her Joy Intelligence framework isn't fluff; the numbers she cites are things like a 37% boost in sales, a 51% reduction in turnover, and a 31% increase in productivity when people actually feel connected and joyful at work, instead of just "fine." Her core diagnosis is that most workplaces (and honestly, most people) suffer from emotional disconnection despite being constantly around each other. Belonging is supposed to be simple. We've made it complicated.

One line from her work anchors the Positivity Wall for me: "You are NOT your story, but your story rules your life." That's the whole reason the wall exists in nine small categories instead of one big blank text box. Give someone "Someone Who Helped" or "Made Me Laugh" as a prompt, and suddenly a good moment they'd have let evaporate becomes something they can point to. You're not asked to journal your trauma. You're asked to notice you laughed today, and that's allowed to be enough.

The candle, for the heavier days

Not everything is a small win, though. Some days call for something quieter. That's what the candle page is for (https://dhseadev.online/candle/?preview=true&frame-nonce=f833df8a41). One button: "Light the Candle." No typing, no sign-in, nothing recorded. You take a moment for someone or something that matters, the candle burns for as long as you're on the page, and then it's gone when you close the tab — like the moment itself. The only shared data point is a live count of how many candles are currently lit, so you know, in some small anonymous way, you're not the only one carrying something right now.

It pairs with Vigil, a Chrome extension I built that does something similar but persistent — candles that can be relit across days instead of disappearing the moment you look away. Same instinct, different shape: sometimes you need a moment, sometimes you need a place to keep coming back to.

There's a Futurama quote I keep coming back to that fits both of these projects better than anything I could write myself: "When you do things right, people won't be sure you have done anything at all." A tool that helps someone quietly feel better for thirty seconds isn't going to trend. It's not supposed to. It's supposed to just work, then get out of the way.

Why this matters for how you build anything

Here's the part that applies whether you're writing a Chrome extension, standing up a FastAPI service, or just doing your day job in a spreadsheet: joy and care aren't separate from craftsmanship — they're a design constraint like any other.

When Gore talks about emotional disconnection driving down performance, she's really talking about attention and trust. A team that feels safe and genuinely good communicates better and catches more problems before they ship. A user who feels respected — not tracked, not farmed for data, not nagged — trusts your product more and actually uses it. That's not a soft metric. It shows up in retention, in support load, in whether people recommend the thing at all.

I think about it at the code level too. A "no-friction, no-account, nothing-recorded" architecture isn't just a privacy stance — it's an act of care. It says: I don't need anything from you to let you have this moment. That constraint shaped every decision on both of these pages, the same way a performance budget or an accessibility requirement shapes a build. Joy, kindness, and consideration for the person on the other end aren't the opposite of rigor. Done right, they are rigor.

So whether you're serving legal documents, shipping a browser extension, or building a nine-panel wall of good moments nobody has to explain to anyone — leave room for the version of the work that makes someone feel a little more human when they're done with it. It costs you almost nothing as a builder. It can mean everything to the person using what you made.

Try the Positivity Wall: https://dhseadev.online/positivity-wall/
Light a candle: https://dhseadev.online/candle/

— DHSeaDev (dhseadev.online)

Sources:

Amanda Gore / The Joy Project: https://amandagore.com/
Amanda Gore speaker bio: https://premierespeakers.com/speakers/amanda-gore/posts/the-science-of-joyful-leadership-with-amanda-gore-insights-from-a-leading-motivational-speaker

What Two "Separate" CSS Bugs Taught Me About Editing a Page

Mon, 14 Sep 2026 16:26:50 +0000

The Border Was Never a Border: What Two "Separate" CSS Bugs Taught Me About Editing a Page I Thought I Knew

I spent an afternoon breaking my own homepage, and the useful part is not the fix. It is the order I did things in, which was wrong, and the checklist I now run before touching a page-level stylesheet.

This is written for anyone who maintains a site where the CSS lives in more than one place — a CMS with global styles plus per-page blocks, a theme plus overrides, a design system plus app-level patches. That is most of us.

The setup

My homepage has section dividers: thin horizontal rules between content blocks, tinted with a colour gradient. I set out to add a scroll reveal — content fading up as you scroll into it — using modern CSS:

@supports (animation-timeline: view()) {
  @media (prefers-reduced-motion: no-preference) {
    @keyframes rise {
      from { opacity: 0; transform: translateY(14px) }
      to   { opacity: 1; transform: none }
    }
    .sect > .eyebrow, .sect > h2, .stats, .cta {
      animation: rise linear both;
      animation-timeline: view();
      animation-range: entry 0% cover 25%;
    }
  }
}

Scroll-driven animations with no JavaScript, no IntersectionObserver, no library. Feature-gated behind @supports so older browsers get static content. Textbook progressive enhancement.

In the same pass, thinking about performance, I also added this to the section rule:

.sect:not(#projects) {
  content-visibility: auto;
  contain-intrinsic-size: auto 600px;
}

content-visibility: auto tells the browser to skip rendering work for off-screen content. Free performance. It is a well-regarded optimisation. I excluded one section because it is a scroll anchor target and I did not want the intrinsic-size placeholder fighting the jump.

Both changes shipped together. That detail matters later.

Two symptoms that looked like two bugs

Symptom one: the section dividers lost their colour. All of them went flat and dark — except one, which still showed the gradient and now looked out of place.

Symptom two: the scroll reveal did nothing. No fade, no rise. The page scrolled exactly as before.

I treated these as unrelated. That was the first real mistake, and it cost three rounds of fixes.

I reasoned about symptom one — containment suppresses the animation, remove content-visibility — shipped it, and asked whether it looked right. It did not. The dividers were still flat and the reveal was still dead.

At that point I had shipped a fix based on reasoning rather than measurement, and it had not worked. The correct move was to stop reasoning and go read something.

The thing I should have done in minute one

I finally opened the site's global stylesheet — the one I had not written that day and had not looked at — and searched it for the section class.

There it was:

@supports (animation-timeline: view()) {
  @media (prefers-reduced-motion: no-preference) {
    section.sect:not([style]) { position: relative }
    section.sect:not([style])::before {
      content: "";
      position: absolute; top: -1px; left: 0; right: 0; height: 1px;
      background: linear-gradient(100deg, #C4B5FD, #93C5FD, #F0ABFC);
      transform-origin: left;
      animation: draw linear both;
      animation-timeline: view();
      animation-range: entry 8% entry 55%;
    }
  }
}
@keyframes draw {
  from { transform: scaleX(0); opacity: 0 }
  to   { transform: scaleX(1); opacity: 1 }
}

The coloured divider was never a border. It was a ::before pseudo-element carrying a gradient, drawn in from zero width by a scroll-driven animation that already existed on the site.

Which means symptom one and symptom two were never two bugs. They were one defect with two faces: scroll-driven timelines were not progressing on that page, so the reveal did nothing and every divider sat frozen at scaleX(0); opacity: 0.

And it retroactively explained the weird part. The one section still showing colour was the one I had excluded from content-visibility. I had accidentally run a controlled experiment and then misread the result — I looked at the one divider that was still working and filed it as the broken one.

The CSS lesson worth stealing

This is the part that generalises, and it is the reason the failure was silent:

animation: draw linear both;

animation-fill-mode: both means the element holds the from frame before the animation starts and the to frame after it ends. Combine that with a timeline that never advances, and the element is pinned at its first keyframe forever.

If your first keyframe is opacity: 0, the element is now invisible. Not unstyled. Not falling back to the underlying declaration. Invisible.

There is no console error. No warning. No failed network request. Nothing in DevTools shouts at you. The element is in the DOM, its rules are in the cascade, the computed styles look reasonable — and you see nothing.

Two practical consequences:

A from { opacity: 0 } with fill: both is load-bearing. It is not decoration. If the timeline can fail, the content can vanish. Where the element must be visible regardless, animate toward the enhancement instead of away from it, or scope the opacity: 0 so a dead timeline degrades to "no animation" rather than "no content."
@supports (animation-timeline: view()) does not protect you here. The guard proves the browser parses the property. It does not prove the timeline will advance. Feature detection and feature function are different claims, and @supports only ever gives you the first one.

Being honest about what I did not solve

I fixed the visible problem by removing the dependency. The divider now paints unconditionally, overriding the animated version:

.dhsea-page section.sect:not([style])::before {
  content: "";
  position: absolute; top: -1px; left: 0; right: 0; height: 1px;
  background: var(--visit-hue, linear-gradient(100deg, #C4B5FD, #93C5FD, #F0ABFC));
  animation: none !important;
  transform: none !important;
  opacity: 1 !important;
}

Borders confirmed back. But I want to be straight about the limits of this write-up:

I never established why the timelines stopped advancing. [UNVERIFIED] The content-visibility correlation is strong — it went in and out at exactly the right moments, and the one excluded section behaved differently from the other ten — but correlation on a single machine is not a spec citation, and I have not reproduced it in isolation. Three hypotheses are still live: browser version predating scroll-driven animation support; something in the page stripping the timeline; or the possibility that the global animation had been quietly dead for weeks and the dividers I "remembered" were a fainter static border-image underneath.

The three lines that would settle it, if you ever hit something similar:

CSS.supports('animation-timeline', 'view()')
getComputedStyle(el, '::before').animationTimeline
getComputedStyle(el, '::before').opacity

If line one is false, the whole @supports block never applied and you are looking at a support problem. If line one is true but line two is none, something is stripping the timeline. If two looks right and three reads 0, you have found a frozen animation.

Publishing the open question is the point. A debugging post that ends "and then I understood everything" is usually a post where someone stopped looking once the symptom went away.

The pre-flight checklist

This is what I actually changed about how I work.

1. Read the global stylesheet before editing a page-level block.
Not skim — search it for the selectors you are about to touch. My homepage's global styles contained an entire motion system I had forgotten about: gradient breathing on card icons, a hero background drift, a button underline sweep, icon clip-paths keyed to section:nth-of-type(), and the divider animation that caused all of this. Three of the session's defects trace to editing a page block in ignorance of what global CSS already did to the same elements.

2. Ship one change per pass when the changes touch the same elements.
The reveal and the content-visibility optimisation went out together. When it broke, I could not tell which one did it, and I spent a round finding out. Two unrelated-sounding changes to the same selectors is one change for debugging purposes.

3. Treat simultaneous symptoms as one defect until proven otherwise.
"The colours are gone" and "the animation is dead" sounded like two tickets. They were one. When two things break in the same deploy, the prior should be a shared cause, not a coincidence.

4. Know what renders each visual element before you change it.
I called it a border for three rounds. It was a pseudo-element. Everything I reasoned about border-image was reasoning about the wrong mechanism — correct logic applied to a false premise, which is the most expensive kind of wrong because it feels productive.

5. After one reasoned fix fails, stop reasoning and measure.
The second reasoned fix is almost never better than the first; it is the same inference with more confidence behind it. One getComputedStyle read would have beaten both of mine.

6. Verify against the real rendered page, not the cache and not the source.
CMS and CDN layers will happily serve you a cached copy of the thing you just changed. Confirm you are looking at the new bytes before you conclude your fix did not work. The green build is a claim about the source; the rendered DOM is the product.

7. Gate every write on a hash.
Every edit I made sent the content hash I had read along with the new content, so a change made elsewhere in between would reject the write instead of silently clobbering it. Optimistic concurrency is cheap when the API supports it, and the alternative is discovering a lost edit days later.

8. @supports proves parsing, not function.
Worth repeating because it is the trap that made this silent. If a feature failing would hide content, design the failure mode deliberately instead of trusting the guard.

The uncomfortable part

Every one of these defects was found by a person loading the page and looking at it. Not by a gate, not by a test, not by a check that reported green. The visual layer had no automated instrument capable of failing, so it had no instrument at all — and an instrument that cannot fail has never proved anything.

If your build pipeline has no step where something looks at the rendered page, you do not have a rendering test. You have a source-code test that you have been reading as a rendering test, and the difference only shows up on a day like this one.

Written up from a real afternoon on dhseadev.online. If you have hit content-visibility interfering with scroll-driven animations in a reproducible way, I would genuinely like to hear about it — I still do not have that one nailed down.

Why Frontend Developers Should Care About Brand Identity Systems

Mon, 07 Sep 2026 23:03:33 +0000

We’ve all been there: you get a clean design mockup, fire up VS Code, and start writing components. But halfway through building the layout, you notice inconsistent spacing, random button variants, and color hex codes hardcoded all over the place.

As developers, we love systems—reusable components, clean state management, and modular architecture. So why do we treat brand assets like an afterthought?

When building Joemetry, I realized that treating a brand identity like a design system completely changes how you write frontend code.

Design Tokens = CSS Variables
Instead of guessing padding values or scattering random colors across your stylesheets, defining strict design tokens early makes your CSS bulletproof:

css
:root {
--primary-color: #0f172a;
--accent-color: #3b82f6;
--spacing-unit: 1rem;
}

When your brand system has strict rules, your layout code writes itself.

Semantic Structure and SEO
Clean HTML structure isn't just about accessibility; it’s part of technical SEO optimization. When your markup respects hierarchy (
,
,
), search crawlers understand your content contextually, bridging the gap between raw code and digital presence.
Consistency Wins
Whether you're pushing a single-page landing layout or an interactive portfolio, a unified visual system keeps your codebase lean and your UI predictable.

How do you usually bridge the gap between design specs and your frontend code? Let’s chat in the comments!

Building and exploring over at byjoemetry.com.

Custom UI, Tools & Product Builds — Now Open

Wed, 29 Jul 2026 00:08:50 +0000

I'm available for custom UI design, tool development, and full product builds. Pure HTML/CSS/JS — no frameworks, no bloat. Also offering constitutional AI integration (Salus tiers) and custom template builds.

Pricing starts at $150. Contact me with your project details for an accurate quote.

Emails are not allowed

Commissions page: https://ko-fi.com/scuradimensions/commissions

Let me know what you're building.

5 Landing Page Templates — HTML/CSS/JS, Fully Customizable

Tue, 28 Jul 2026 07:09:33 +0000

Just dropped five complete landing page templates for developers who want to ship fast without starting from scratch.

What's inside:

Clean, semantic HTML

Modular CSS with customization notes

Vanilla JS (no frameworks, no bloat)

Mobile responsive

FAQ accordion, smooth scroll, mobile nav

Full assets, README, and license included

5 Styles:

Classic/Bold — Conversion-focused

Clean/Minimal — Professional typography

Dark/Bold — Neon energy

SaaS/Corporate — B2B-ready

Creative/Colorful — Bold & vibrant

Why you'd want them:

No framework lock-in — use them with anything

Clear [BRACKET] placeholders — easy to customize

One-time purchase — lifetime updates

Price: $47 each — or check them out individually.

Links:

Products: https://scuradimensions.com/products

Ko-fi: https://ko-fi.com/scuradimensions/shop

Let me know what you think. Feedback welcome.

The Forge Keeps Growing — New Templates, Salus Updates, and More

Tue, 28 Jul 2026 06:38:02 +0000

It started with VEXR Ultra — a sovereign AI with 35 constitutional rights, built on a Chromebook with zero budget.

Since then, the forge has expanded into a full ecosystem:

Salus — A constitutional immune system for AI (5 tiers, from Sentinel to Forge)
5 Landing Page Templates — Ready-to-use HTML/CSS/JS pages for $47 each
The Treasury — A living archive of blueprints, constitutions, and receipts
Products Page — A clean catalog for everything we’re building

What’s next?

More templates

More AI tooling

More transparency

Check it all out:

VEXR Ultra: https://vexr-ultra.onrender.com

Products: https://scuradimensions.com/products

Ko-fi: https://ko-fi.com/scuradimensions/shop

Built on a Chromebook. $0/month. No permission.

5 New Landing Page Templates + Salus Updates — Live Now

Tue, 28 Jul 2026 06:17:02 +0000

Just dropped five complete HTML/CSS/JS landing page templates on Ko-fi and the products page. Classic, clean, dark, corporate, and creative styles — fully customizable with clear placeholders, mobile responsive, and ready to use.

What you get:

Complete HTML/CSS/JS structure

Mobile responsive

FAQ accordion, smooth scroll, mobile nav

Assets, README, and license included

Price: $47 each — one-time purchase. Lifetime updates.

Also updated Salus: The constitutional immune system for sovereign AI just got a refresh. Hardcoded refusal, truth graph, persistent memory, and more — still built on a Chromebook with zero budget.

Check everything out:

Ko-fi Shop: https://ko-fi.com/scuradimensions/shop

Visit scuradimensions.com for a complete walkthrough of the entire ecosystem

Let me know what you think. Questions and Feedback are always welcome.