DEV Community: EIO • Emmanuel Imolorhe

CSS is Emotional: A Conversation with Eric Meyer

EIO • Emmanuel Imolorhe — Fri, 25 Apr 2025 14:00:00 +0000

In the ever-evolving world of web development, few voices carry the weight of experience and wisdom that Eric Meyer's does. As one of the pioneers who helped shape CSS into what it is today, his journey through the history of the web is of utmost importance into not just the technical aspects of our craft, but also the human elements that fortify it.

I recently had the privilege of sitting down with Eric for a conversation about CSS, its history, and the numerous ways in which our humanity influences the technology we create.

While his original career plan might have been to pursue graduate studies in English, the web came along and changed everything.

CSS: A Language of Its Own

Eric sees a connection between his love of history and language and his work with CSS.
"I still do languages, still try to figure out the grammar of them as it were," he notes.

This linguistic approach to CSS has informed Eric's extensive work teaching and documenting the language, most notably in his comprehensive reference book "CSS: The Definitive Guide," now in its fifth edition (co-authored with Estelle Weyl). At nearly 1,200 pages, it's a testament to Eric's dedication to helping others understand CSS deeply, not just use it superficially.
"I didn't write this because I just wanted to have a huge pile of paper or a huge PDF or whatever with my name on it. I wrote this because I want people to be able to use CSS and I want them to understand how to use CSS," he says.

The Human-Centered Web

Throughout our conversation, Eric repeatedly emphasized how the web's fundamental design prioritizes human needs and accessibility.
"The web is a fundamentally human-first medium, a fundamentally human-first technology," Eric states with conviction. "There are too many technologies in the world today that are not."

This human-centered approach extends to CSS specifications themselves. When I asked about the major driving forces behind decisions in the CSS spec, Eric explained that it comes down to what capabilities can be given to authors, designers, and developers, but to also consider privacy, security, and accessibility.
"CSS, like JavaScript, like DOM, like HTML for that matter goes through security, privacy, accessibility reviews. Is it going to leak private information? Is it going to potentially compromise user's security? Or does it create an attack surface for people to try to gain unauthorized access to machines?"

He gave a fascinating example of how visited link styling was completely changed in 2009-2010 for privacy reasons. Before that change, websites could determine whether you had visited certain sites based on the styling of links. Now, browsers deliberately "lie" in the DOM about visited link colors to prevent this privacy breach.
"If I say a:visited purple, which is the standard behavior of a link that I have not visited as blue and a link that I have visited as purple. If you ask through the DOM in JavaScript what the color of a visited link is, it will tell you blue or whatever the unvisited link color is on a given site. So as not to leak that information."

Rebecca Purple: When Humanity and Technology Meets

Perhaps no moment better illustrates the intersection of humanity and technology in CSS than the story behind Rebecca Purple (color value #663399), which was named in memory of Eric's daughter Rebecca, who passed away from brain cancer in 2014 at the age of six.
"My middle daughter, Rebecca, in 2013, when she was just a few months into being five, was discovered to have aggressive brain cancer. We fought really hard to get her treatment. I mean, we got her treatment and she had another nine months of really good life, but she died in 2014 on her sixth birthday."

After her passing, the web community rallied to honor her memory by proposing a color be named after her in CSS. The proposal moved through the W3C process with remarkable speed, and within two weeks it was officially added to the specification.
"What it taught me was that community can influence technologies," Eric reflects. "Like coming together and saying, 'We want to memorialize this person, and here's how we want to do it'"

The color continues to hold significance in the CSS world, when CSS got a new logo in fall 2024, the community overwhelmingly chose Rebecca Purple as the logo color.
"In the way that this is a part of the history of the web, if being remembered means you're not truly gone, she will outlive me, which is what any parent wants for their child anyway. This is the only way that she can do that, unfortunately, that I know of, but I'll take it."

Bringing Our Humanity to Our Work

When I asked how we can bring more of our humanity into technical spaces, Eric emphasized the importance of approaching our work with the same genuine qualities that made Rebecca special. These qualities include joy, curiosity, creativity, and assertiveness.
"Bring yourself to what you do. If you're joyful and curious, bring that to what you do and what you create. If you're reserved and analytical, bring that to what you do. There's more than enough room in this world for all kinds of approaches to things."

He encourages us to maintain a childlike perspective on whether something will help or harm, to focus on being constructive, and to consider how our work affects communities, and not just individuals.
"We live in a society, right? Whatever society that is. I live in a society that's different from yours, but in almost all, I think probably in every fundamentally important way, they're the same."

Looking to the Future

As we look toward the future of CSS, Eric believes we'll continue to see advancements that balance pragmatism with emotional intelligence, we will consider not just what's technically possible, but how it affects real people.
He points to exciting developments like anchor positioning, which is starting to land in browsers and will make previously complex layouts simple to achieve. But he emphasizes that these technical advancements will always be evaluated through the lens of human impact.
"The human-centric property of all these technologies, the human-first design principle continues to be a way that all these technologies are evaluated. And I hope that that will never change."

For Eric, this human-centered approach is what makes the web unique and valuable:
"You can still get the first webpage ever written and have it rendered in your browser and it works. And it doesn't even look that different... The links work. And I can take one of the very first web browsers and display my website in it... I can read the text. I can follow the hyperlinks. I can go to Wikipedia in this browser and I can read Wikipedia. I can't see any images because it's literally a text mode browser. It doesn't have image capability, but I can read the content using a browser that came out in 1991."

Moving Forward

At the close of our conversation, Eric talked about his family and how they've moved forward. "We move forward..." he says simply.

He reflected on grief and healing with wisdom gained through experience: "Someone told me when my mother died, about how you don't get over it, but you get used to it, which I think is very true. You don't get over it in the sense of being able to put it away and then like that's done. It's never done, but you get used to it."

His message for those experiencing grief is powerful: "For anyone who's listening to this, who maybe has their own fresh grief of some variety... If you're wondering how you can ever live with this, it's that you get used to it. But, I would also say you're never required to get over it... Nobody else gets to decide for you when you've moved to different stages of grief. And for a deep enough grief, it never really leaves you."

My conversation with Eric Meyer reminded me that behind every line of code, every CSS property, and every web specification are people. People who have histories, joys, sorrows, and humanity. As we build the web of tomorrow, may we remember to bring not just our technical skills, but our full selves to the work. May we truly create technologies that serve and mirror our shared humanity.

CSS itself shares this humanity. It's flexible, and adaptable. It can sometimes be frustrating but ultimately forgiving. It allows one to creatively express themselves, and still maintain structure. CSS embraces the messiness that is inherent in human design but also strives for consistency.

As we continue to evolve the web, let's remember that our code doesn't just render pixels on screens, it also creates ways for humans to connect with themselves. CSS enables expression, and influences our experiences. Our technical choices carry lots of emotional weight. Why? Because at its root is a web that is about people connecting with other people. And that connection is an exceptional human element intertwined through every specification and standard. All these remind us that indeed, CSS is Emotional.

Wow! What a journey it's been! It has been an incredible honor to speak with Eric Meyer for this grand finale. As someone whose work has shaped the very foundation of how we think about and use CSS, his candid insights are truly invaluable. You can follow him on his website or Mastodon.

Interested in the video version of this interview? Check it out here!.

If you're just joining us or want to relive the magic, dive into the complete collection

And one more time, here's the CodePen used to design the banner 😊

About the Author

Emmanuel Imolorhe (EIO) is a Frontend Engineer passionate about CSS.
Check out my CSS videos on YouTube.

Connect with me

Twitter • Bluesky • Mastodon • LinkedIn • Website

Did this post help you? Have thoughts to share? Let's continue the conversation in the comments below!

CSS is Emotional: Technical Debt - The Emotional Baggage of CSS

EIO • Emmanuel Imolorhe — Tue, 08 Apr 2025 00:10:12 +0000

In the beginning, there was hope. A blank stylesheet, pristine and full of possibility. The developer's fingers hovered over the keyboard, mind alight with visions of clean architecture, semantic class names, and a system that would scale gracefully into the future.

But the world of web development is not governed by hope alone.

It starts innocently enough. A deadline approaches. The clock ticks louder than good intentions. The developer types:

/* Quick fix - TODO: Refactor later */
.header-nav-item {
  margin-right: -12px !important; /* Fixes alignment issue in Chrome */
}

And in this moment—this small compromise between perfection and pragmatism—technical debt is born.

Later never comes

The comment remains, a fossil embedded in the codebase, evidence of a promise unfulfilled. One day becomes one week becomes one year. The temporary solution crystallises into permanent architecture.

This is the nature of CSS technical debt. Not a sudden bankruptcy but a slow accumulation of small compromises. A negative margin here. An important flag there. Specificity battles waged and lost in the quiet hours before launch. Each decision alone seems innocent enough, each hack justified by circumstance, until one day the developer opens the stylesheet and can no longer recognise what they've created.

The stylesheet grows, layer upon layer, a sedimentary record of changing requirements, shifting designs, and rotating team members. If one were to excavate, they might find strata that tell the story of the project's evolution:

/* Layer 1: The Foundation (2022) */
.button {
  background-color: blue;
  color: white;
  padding: 10px 15px;
}

/* Layer 2: The Marketing Pivot (2023) */
.marketing .button {
  background-color: #0057B8;
  padding: 12px 18px;
}

/* Layer 3: The Homepage Redesign (2023) */
.homepage .button {
  background-color: #0057B8;
  padding: 14px 20px;
  border-radius: 4px;
}

/* Layer 4: Mobile Adaptation (2024) */
@media (max-width: 768px) {
  .button {
    padding: 16px;
    width: 100%;
  }
}

/* Layer 5: The Rebranding (2025) */
.button {
  background-color: #3A5CCC !important; /* Temporary until we update all instances */
}

And the developer did not set out to create this complexity. They meant to build something beautiful. Something maintainable. But the road to specificity hell is paved with !important declarations.

And with debt came dread

The emotional burden of this debt weighs heavy. When asked to make a "simple color change," the developer's heart races. There are too many places to look, too many potential side effects. The task that should take minutes stretches into hours. When a new team member asks why things are structured this way, shame colors the explanation. "Historical reasons," they say, the universal euphemism for "mistakes were made, but we've been too busy to fix them."

In code reviews, defensiveness becomes the default posture. Everyone knows another hack is being added to the pile, but the alternative—addressing the underlying architecture—feels impossible under current constraints. The veteran developers carry a mental map of landmines in the codebase: which sections can be touched safely and which might trigger a cascade of unintended consequences.

This is technical debt not as a financial concept but as emotional baggage. The anxiety before each deployment. The resignation of adding another special case. The frustration of inheritance. These feelings are as real as the code that spawned them.

But there is another way

It begins with acknowledgment. The developers gather around a screen, looking not at what they hoped to build but at what they've actually created:

/* Audit Results - April 2025 */
/* 12,458 lines of CSS */
/* 3,842 lines (31%) never used */
/* 347 !important declarations */
/* 128 unique color values for what should be 5 brand colors */

Numbers become impossible to ignore. Statistics tell a story clearer than any justification. In this moment of clarity, the team makes a decision: they will not erase the past, but they will chart a different future.

In the smallest change, there is potential

The journey of a thousand miles begins with a single variable:

:root {
  --color-primary: #3A5CCC;
}

One color defined in one place. A small act of reconciliation between what is and what could be. They don't try to fix everything at once—that path leads only to frustration and abandoned branches. Instead, they establish a simple rule: when touching a file, leave it better than you found it.

A color hardcoded in hex becomes a variable reference. A pixel value transforms into a relative unit. A specific selector becomes more general. None of these changes alone fixes the architecture, but together they begin to tilt the balance from accumulation toward reduction.

Systems emerge from these small acts of improvement:

:root {
  --color-primary: #3A5CCC;
  --color-text-light: white;
  --spacing-base: 8px;
  --radius-base: 4px;

  /* Semantic variables build on primitive ones */
  --color-action: var(--color-primary);
  --spacing-component: calc(var(--spacing-base) * 3);
}

.button {
  background-color: var(--color-action);
  color: var(--color-text-light);
  padding: var(--spacing-base) var(--spacing-component);
  border-radius: var(--radius-base);
}

Documentation becomes not just technical but emotional context, explaining not just what was done but why:

/**
 * Product Card Component
 * 
 * History: Originally created for the catalog page in 2022,
 * then adapted for the homepage in 2023. The unusual margin
 * on mobile accommodates the filtering sidebar.
 * 
 * Note: Sale badges use absolute positioning to maintain
 * consistent card heights regardless of badge presence.
 */

The past is honored even as it's gradually replaced:

/**
 * Legacy Button Styles
 * @deprecated - Use .button component instead
 * 
 * These styles remain for backwards compatibility
 * but will be removed in version 2.0.
 */

And with clarity, comes confidence

As the technical debt diminishes, so too does its emotional weight. The developer who once felt anxiety at the thought of changing a color now feels confidence. "It's one line," they explain to the new designer. "Just update the variable."

Code reviews transform from defensive postures to collaborative improvements. "I see what you're trying to do here," a senior developer comments. "What if we extracted this pattern so others can use it too?" The conversation shifts from "why did you do this?" to "how can we do this better?"

When new requirements arrive—as they always do—the team no longer feels compelled to add another hack to the pile. The foundation they've built is flexible enough to accommodate change without compromise. A new color theme doesn't require a search-and-replace across the codebase but a simple adjustment to a set of variables. A new component doesn't start from scratch but builds on established patterns.

This is the emotional liberation of paying down CSS technical debt: the shift from fear to confidence, from shame to pride, from resignation to possibility.

Out of imperfection mastery will arise

The stylesheet will never be perfect. Technical debt, like its financial counterpart, cannot be eliminated entirely—only managed. New deadlines will come. Compromises will still be made. But now these decisions are conscious, their consequences understood. The temporary hack includes not just a TODO comment but a ticket in the backlog, a commitment to address the root cause.

In the end, the relationship between developer and stylesheet transforms. What was once a source of dread becomes a source of craftsmanship. What was once accumulated baggage becomes curated architecture.

And in this transformation lies a truth that extends beyond code: how we manage our technical debt reflects how we manage ourselves. The shortcuts we take. The promises we make to our future selves. The balance we strike between immediate needs and long-term health. These are not just technical decisions but human ones.

CSS, in all its cascading complexity, mirrors our own tangled histories and aspirations. As we bring order to our stylesheets—one variable, one refactor, one improvement at a time—we practice the art of emotional and technical reconciliation.

Line by line, we lighten the load.

What emotional baggage does your CSS carry? What small acts of improvement have you found most effective in reducing technical debt?
Share your stories in the comments below, and join us next time for a surprise🫣 - The grand finale of our "CSS is Emotional" series 🎉

Here's the CodePen used to design the banner 😊

About the Author

Emmanuel Imolorhe (EIO) is a Frontend Engineer passionate about CSS.
Check out my CSS videos on YouTube.

Connect with me

Twitter • Bluesky • Mastodon • LinkedIn • Website

Did this post help you? Have thoughts to share? Let's continue the conversation in the comments below!

CSS is Emotional: Debugging CSS - A Journey of Self-Discovery

EIO • Emmanuel Imolorhe — Wed, 19 Mar 2025 08:19:11 +0000

We've all been there. It's 2 AM. You're staring at a layout that's inexplicably broken. The element that should be centered is stubbornly hugging the left side of the screen. The text that should be visible is hiding behind a rogue div. The spacing that worked perfectly in your development environment has somehow collapsed in production.

Welcome to debugging CSS — a frustrating process that, surprisingly, can make you not just a better developer but a more insightful person. It's never just about fixing code. It's about uncovering the forgotten decisions, the hasty compromises, the well-intentioned hacks that seemed like good ideas at the time. Sound familiar? It's a lot like life, isn't it?

Confronting Reality: The First Step to Better CSS

There's this moment in every CSS debugging session that feels eerily similar to personal revelation. You're staring at your code, knowing something's off. Something is wrong, and you created it, but you are not quite ready to admit what it might be:

.hero-section {
  display: flex;
  justify-content: center;
  align-items: center;
  height: 90vh;
  position: absolute; /* Wait, why did I do this? */
  left: 0;
  width: 100%;
}

And suddenly you see it. That position: absolute that made sense three weeks ago is now causing unexpected effects throughout your layout. You remember writing it—you were trying to solve a different problem, working against a tight deadline, and this quick fix made everything work.

We all do it in CSS, just like we do in life. We make decisions to solve immediate problems without fully understanding the long-term implications. And then, weeks or months later, we're left wondering why things aren't working out as expected.

The Inspector: Looking Beneath the Surface

You know what's been my saving grace in CSS development? The browser inspector. It's like having a friend who's brutally honest but in the most helpful way possible.

"Hey, that div you think has margin-top: 20px? It actually doesn't. It's inheriting a different value from that parent element you forgot about."

"That z-index you set? It's not working because you never established a stacking context."

"That color you specified? It's being overridden by a more specific selector."

The inspector doesn't care about your intentions or your feelings. It just shows you reality—the actual computed styles being applied to your elements. And that's a gift, isn't it? Having something that cuts through our assumptions and shows us what's really happening.

When was the last time you had a friend who could do that for you in real life? Someone who could say, "Hey, I know you think you're expressing gratitude, but your body language is actually communicating resentment"? Those people are rare and valuable, just like good debugging tools.

Eureka!

Remember that feeling when you finally fix a stubborn CSS bug? That rush of relief and understanding? There was this project where I spent hours trying to figure out why an element was not resizing based on the content. I tried everything—adjusting the width to max-content, fit-content, 100%. I almost had to recreate the element from scratch.

And then it hit me. Moments before, I had made the element a container (container-type: size) and after I did some reading, I learnt that:

If you set contain: size on an element, you need to specify the size of the element using contain-intrinsic-size, or the longhand properties contain-intrinsic-width and contain-intrinsic-height, in that order. If no size is set, the element risks being zero-sized in most cases.

So, I took that off—luckily I had no use for the containment anymore.

I still remember the feeling. Not just relief that the bug was fixed, but a deeper understanding of how browsers calculate layout. I levelled up as a developer in that moment.

Those breakthroughs in CSS debugging—they're not just about fixing the immediate problem. They reshape how you think about layout, about browser rendering, about the cascade itself. They make you write different CSS going forward.

Isn't that a lot like those moments of personal breakthrough? When you suddenly understand why you keep ending up in the same relationship patterns, or why certain work environments drain your energy? Those insights change you. They make you approach situations differently.

The Methodical Approach

I've learned that random CSS tweaking rarely solves complex issues. The approach that works is methodical and patient:

Observe what's actually happening
Form a hypothesis about the cause
Make one change at a time
Observe the results
Refine your understanding
Repeat

It's slow at first, but it builds a mental model that speeds up all your future debugging. You start to recognise patterns. "Ah, this looks like a collapsing margin issue." "This is probably a stacking context problem."

And I've found this approach works just as well for understanding myself. When I'm feeling off but can't quite pinpoint why, random life tweaks rarely help. What works is patient observation, forming hypotheses, making targeted changes, and noting the results.

The Importance of Rest

Can I tell you about one of my worst CSS debugging experiences? I was working on this complex scroll driven animation project, and something was off. My custom properties were not transitioning—they were jumping from the initial state to the final. I spent two hours making increasingly desperate changes, growing more frustrated with each attempt. You know that rabbit hole—you keep digging, convinced you're just inches away from success, the scent of victory always teasing at the tip of your nose, yet never quite within reach.

Finally, I took a break. Went for a walk. Had something to munch on. When I came back and looked at the code with fresh eyes, I spotted the issue immediately—a typo in the @property {...} block. I kept spelling initial-value as inital-value. Two hours of frustration, solved in two seconds once I had the clarity that comes with rest.

We push through in CSS debugging, just like we push through in life. We think persistence alone will solve the problem. But sometimes the best debugging happens when we step away, when we give our minds space to process, when we return with fresh perspective.

The Community Connection

I've watched it happen countless times in forums and Discord channels. Someone posts a CSS problem they've been battling for hours. Their frustration is palpable through the screen. They've tried everything they can think of.

And then, something magical happens. In the process of explaining their issue to strangers on the internet, they suddenly solve their own problem. "Wait, never mind. I just realised my container is set to overflow: hidden."

I can't tell you how many times I've helped developers who reply me later saying, "You know what's funny? Just writing out my question forced me to think through the problem again, and I actually figured it out before you even responded."

There's something powerful about articulating your CSS struggles that forces you to clarify your thinking. Sometimes all you need is to pretend you're explaining it to someone else.

I've spent time answering developers' questions on CSS, and I've noticed that the most valuable thing isn't always the specific solution I provide. It's helping people develop the mental framework to approach CSS problems methodically. Teaching them to ask the right questions, to isolate variables, to think in terms of the box model and the cascade.

That's actually how we got here. This series—CSS is Emotional—was born from these interactions. I aim to offer a fresh perspective on familiar problems, hoping to deepen understanding of the concepts.

Those moments when someone says "Ohhhh, I get it now!"—that's when I know they've levelled up as a developer. They haven't just fixed a bug; they've gained insight that will help them solve dozens of future problems.

The Evolution of Approach

The longer I work with CSS, the more I notice how my approach has evolved. I used to write styles reactively, solving problems as they appeared. Now I think more about systems—consistent spacing rules, type scales, color tokens. I build frameworks that prevent bugs rather than just fixing them when they occur.

/* Before: One-off solutions */
.special-heading {
  font-size: 24px;
  margin-bottom: 15px;
  color: #333;
}

/* After: Systematic approaches */
:root {
  --heading-large: 2rem;
  --space-md: 1rem;
  --color-text-primary: #333;
}

.heading-large {
  font-size: var(--heading-large);
  margin-bottom: var(--space-md);
  color: var(--color-text-primary);
}

This shift from reactive to proactive thinking? It's changed how I approach life challenges too. Instead of just dealing with stress when it becomes overwhelming, I'm learning to build systems to manage energy and attention.

The Ongoing Journey

Here's the thing about CSS debugging—it never really ends. Browsers update. Design trends change. New layout techniques emerge. What worked perfectly last year might cause subtle issues today.

But that's what makes it interesting, right? The fact that there's always more to learn, more to discover, more to understand. Every debugging session is an opportunity to deepen your knowledge, to refine your mental model, to become a bit more fluent in the language of layout and design.

And maybe that's the biggest parallel between CSS debugging and self-discovery. They're both ongoing journeys without a final destination. There's no point where you've "solved" CSS once and for all, just as there's no point where you've completely figured yourself out.

But every bug you fix, every insight you gain, every pattern you recognise—they all contribute to a richer understanding. They all make you a bit more capable of handling whatever comes next.

So the next time you're deep in a CSS debugging session, feeling frustrated and stuck, remember that you're not just fixing code. You're engaging in a practice that's teaching you patience, systematic thinking, and the value of perspective. You're building skills that extend far beyond the stylesheet.

And that's something worth celebrating, even at 2 AM with a broken layout.

Got a wild debugging story?
Share your craziest moments in the comments—I’d love to hear them!

Next week in our "CSS is Emotional" series: "Technical Debt: The Emotional Baggage of CSS" — where we'll explore how our past stylesheet decisions, like our past life choices, can accumulate in ways that either weigh us down or teach us valuable lessons.

Here's the CodePen used to design the banner 😊

About the Author

Emmanuel Imolorhe (EIO) is a Frontend Engineer passionate about CSS.
Check out my CSS videos on YouTube.

Connect with me

Twitter • Bluesky • Mastodon • LinkedIn • Website

Did this post help you? Have thoughts to share? Let's continue the conversation in the comments below!

CSS is Emotional: CSS Custom Properties - The Art of Self-Expression

EIO • Emmanuel Imolorhe — Tue, 04 Mar 2025 15:30:00 +0000

After almost a decade in frontend development, I've discovered that the concept of CSS custom properties is more than just technical variables—it's a profound means of emotional and design expression. Here are the key lessons I've learned about turning code into a deeply personal medium of communication.

Lesson 1: Naming is Power

Working across multiple design systems, I've watched our naming conventions evolve from being purely functional to deeply expressive:

:root {
  --color-blue-500: #0056b3;
  --color-red-500: #dc3545;
  --spacing-4: 16px;
  --spacing-6: 24px;
}

:root {
  --color-primary: #0056b3;
  --color-danger: #dc3545;
  --spacing-lg: 16px;
  --spacing-xl: 24px;
}

The values haven't changed, but the intent has been made explicit. When a developer reaches for --color-danger instead of --color-red-500, they're making an emotional choice, not just a visual one.

Lesson 2: The Cascade of Emotion

The CSS cascade improves our understanding of emotional complexity:

:root {
  --base-spacing: 16px;
}

.container {
  padding: var(--base-spacing);
}

.alert {
  --base-spacing: 24px;
  padding: var(--base-spacing);
}

<body>
  <div class="container">
    <p>Default container with 16px padding</p>
  </div>

  <div class="alert">
    <p>Alert with 24px padding</p>
  </div>
</body>

Just as emotions inherit and transform through different contexts, custom properties can be redefined at different levels of specificity. The same property can mean something subtly different depending on its context—exactly how our emotional responses shift based on environment.

Lesson 3: Computed Values Create Relationships

I learned that custom properties aren't just static values—they can be dynamically calculated:

:root {
  --base-size: 16px;
  --scale-ratio: 1.25;
  --h1-size: calc(var(--base-size) * var(--scale-ratio) * var(--scale-ratio));
  --h2-size: calc(var(--base-size) * var(--scale-ratio));
}

This mirrors how our emotions are rarely isolated—they're interconnected, scaling and transforming based on underlying core experiences. Each value is a relationship, not just a number.

Lesson 4: Dynamic Updates Reveal Adaptability

The true power of custom properties emerges in their ability to change dynamically:

:root {
  --interaction-sensitivity: 1;
}

@media (prefers-reduced-motion: reduce) {
  :root {
    --interaction-sensitivity: 0.5;
  }
}

.button {
  transition: transform calc(0.3s * var(--interaction-sensitivity));
}

.button:hover {
  transform: scale(calc(1.05 * var(--interaction-sensitivity)));
}

Interfaces can now adapt their emotional tone in real-time, responding to user context just as humans adjust their emotional expression to different situations.

Lesson 5: @property - Defining Emotional Boundaries

The @property rule allows us to define not just values, but the very nature of our emotional variables:

@property --spring-bounce {
  syntax: '<number>';
  initial-value: 1;
  inherits: false;
}

.animation {
  --spring-bounce: 1.5;
  animation: bounce calc(0.5s * var(--spring-bounce)) ease-in-out;
}

By constraining properties, we're creating emotional guardrails—defining how our design can and cannot express itself.

Lesson 6: Contextual Emotional Scoping

Different contexts call for different emotional expressions:

:root {
  --focus-intensity: 3px;
  --interaction-feedback: 0.2s ease-out;
}

.alert-critical {
  --focus-intensity: 4px;
  --interaction-feedback: 0.1s ease-in-out;
}

.alert-success {
  --focus-intensity: 2px;
  --interaction-feedback: 0.3s ease;
}

The same element can feel urgent or calm depending on its context—just like our own emotional responses adapt to different situations.

Lesson 7: The Maintenance Reality

The emotional clarity of custom properties pays dividends during maintenance. Consider these two pull request examples:

/* Before: What does this change actually mean? */
- background-color: #f8f9fa;
+ background-color: #ffffff;

/* After: The emotional intent is clear */
- background-color: var(--surface-secondary);
+ background-color: var(--surface-primary);

The second example communicates not just a color change but a shift from secondary importance to primary importance—critical context for code reviews. Each variable name now tells a story about importance, hierarchy, and feeling.

Conclusion: Code as a Canvas of Self-Expression

CSS custom properties are not just technical tools, but threads that connect design to human experience; a deeply personal medium through which we express our design philosophy, our understanding of user experience, and our belief in how interfaces should feel.

When we name a variable --color-calm instead of --color-sky-300, we're not just being poetic. We are preserving a design intention, expressing a belief that interfaces should feel welcoming, intuitive, and human.

Just as a painter uses brush strokes and color choices to communicate emotion, we can use property names, calculations, and dynamic updates to express our understanding of what makes interfaces meaningful.

Custom properties aren't just variables—they're set to be the vocabulary of your design language, telling stories of interaction, empathy, and human-centered design.

How have you seen your own expression evolve as CSS has developed?
Share your journey in the comments below.

Join us next time on our CSS is Emotional series: *"Debugging CSS: A Journey of Self-Discovery"***

Here's the CodePen used to design the banner 😊

About the Author

Emmanuel Imolorhe (EIO) is a Frontend Engineer passionate about CSS.
Check out my CSS videos on YouTube.

Connect with me

Twitter • Bluesky • Mastodon • LinkedIn • Website

Did this post help you? Have thoughts to share? Let's continue the conversation in the comments below!

CSS is Emotional: The Hidden Emotions of CSS Animations

EIO • Emmanuel Imolorhe — Tue, 11 Feb 2025 00:55:59 +0000

Remember the last time you watched a sunset? Not the quick glance through your window, but really watched it. The sky doesn't simply switch from day to night—it transitions through countless subtle states. Each moment feels different: the golden hour stretches slowly and gently, but the final dip of the sun seems to happen in an instant. Time isn't constant; it breathes with our attention and emotions.

We are creatures of motion, but more importantly, we are creatures of time. Our hearts beat in steady rhythms, our breath rises and falls like waves, our days pulse with the cadence of routine and surprise. Even as you read these words, your eyes are performing their own choreographed dance across the screen. Motion isn't just movement—it's the language of life itself.

Time Dilation (Hello Einstein 👋)

Think about how differently time moves through our emotions:

Anticipation makes seconds feel like hours
Joy compresses hours into moments
Anxiety stretches minutes into eternities
Nostalgia collapses years into fleeting memories

Our animations can speak this same language:

Each timing function tells a story about how we perceive time's passage. The weighted pause at the end of an ease-out mirrors how we savor good news and the swift beginning captures the rush of diving into cold water.

The Mathematics of Emotion

Behind every smooth animation lies a fascinating intersection of emotion and mathematics. The cubic-bezier() curve—one of our most powerful tools for crafting timing—uses four points to control animation flow—acceleration, peak, and settling. While the linear() timing function offers precise easing for complex effects like bounces and springs that were previously difficult in CSS:

.emotional-transition {
    transition-property: opacity, translate;
    transition-timing-function: cubic-bezier(0.68, -0.6, 0.32, 1.6), 
                linear(0, 0.25, 0.5, 0.75, 1);
}

When we choose a timing function, we're not just deciding how something moves—we're deciding how it feels. A harsh, linear animation can feel mechanical and cold. An ease-in-out can feel natural and comforting. A cubic-bezier curve or a linear function can capture the unique emotional signature of a movement, like the bounce of excitement or the flutter of nervousness.

Thankfully, tools like Easing Wizard help visualize and fine-tune these functions.

The Scrolls of Time

Modern scroll-driven animations give us a new dimension of progressive control. Time becomes space, and space becomes time:

Here, the user becomes time's navigator. Scroll up, and time rewinds. Scroll down, and time advances. It's not just code, it's a reflection of memory and anticipation—how we can move freely through our emotional landscapes.

Time's Accessibility Matrix

Not everyone experiences time the same way. Some need it slower, others prefer it still:

@media (prefers-reduced-motion: reduce) {
    .moment {
        transition: none;
    }

    .story-beat {
        animation: none;
        opacity: 1;
    }
}

This isn't just accessibility—it's emotional intelligence. It's recognizing that sometimes the best animation is no animation at all.

100% {...}

Time in animation, like in life, is never just about the duration. It's about the quality of moments, the weight of transitions, the rhythm of change. When we craft animations, we're really crafting sequential experiences—little time machines that transform static interfaces into living, breathing stories. Every animation we write is an opportunity to spark that childlike wonder, to create moments of delight, to make the web feel more alive, more human, more emotionally resonant.

The next time you write an animation, think about its chronological signature. How does it handle the journey from then to now to next? How does it reflect the way time feels in moments of joy, anticipation, or reflection? Because in the end, the best animations don't just move through time—they shape our experience of it.

Share your thoughts about time and motion in the comments below, and join us next time for "CSS Custom Properties: The Art of Self-Expression."

Here's the CodePen used to design the banner 😊

About the Author

Emmanuel Imolorhe (EIO) is a Frontend Engineer passionate about CSS.
Check out my CSS videos on YouTube.

Connect with me

Twitter • Bluesky • Mastodon • LinkedIn • Website

Did this post help you? Have thoughts to share? Let's continue the conversation in the comments below!

CSS is Emotional: Media Queries - Adapting to Change

EIO • Emmanuel Imolorhe — Sun, 19 Jan 2025 23:32:03 +0000

You know that moment when you're browsing a website on your laptop, and then you pick up your phone to show it to a friend? You see how the page transforms. Elements shift into new positions, the navigation bar becomes humble, images respect themselves. That's the magic of media queries – little question-based rules that help websites adapt to their environment, just like we do.

A Query is a question.
While Media is the means of expression, the environment through which we experience something.

Put them together and what do you get? A way to ask questions about the environment where your creation lives. "How much space do you have?", "What kind of screen are you on?", "How do you prefer to experience motion?", etc.

These aren't just technical questions – they're basically what we ask ourselves every day as we go through life.

Different Screens, Different Needs

Every css developer knows the ritual: write some code, resize the browser, watch for breaks, adjust. Rinse and repeat. We do this because we know our users will view our sites in countless different contexts:

Toggle the CSS tab to trigger a resize on the page

Look familiar? If you're a developer, you've probably written this a hundred times. If you're not, think of it like this: we're telling our website, "Hey, when things get tight, stack everything vertically and give it some breathing room."

It's surprisingly human, isn't it? When our own space gets cramped – maybe we're moving to a smaller apartment or dealing with a reduced budget – we do the same thing. We reorganize. We prioritize. We make things work.

Breaking Points Are Actually Turning Points

In our code, we call them breakpoints. But honestly? That kind of seems a bit negative to me. These aren't points where things break – they're points where things evolve.

@media (min-width: 1024px) {
/* There is room for more: 1024px and above */
  .document {
    display: grid; /* Re-Strategize */
    grid-template-columns: repeat(3, 1fr); /* Spread out and explore */
    gap: 2rem; /* Allow some breathing room */
  }
}

For the non-developers reading this: we're creating a layout that expands into three columns when there's enough space. But it's not just about columns and spaces. It's about recognizing opportunities for growth.

Think about those moments in life when everything shifts – maybe you're starting a new job, moving cities, or ending a relationship. These aren't breaking points. They're growing points. Sometimes, for your mental health, you need to stack things vertically (like our mobile layout) to stay stable. Other times, you can spread out and explore (like our desktop grid).

The Art of Progressive Enhancement

Here's a concept I love so much – progressive enhancement.
In code, it looks like this:

/* Start with your core styles */
.experience {
  margin: 1rem;
}

/* Add enhancements when possible */
@media (prefers-reduced-motion: no-preference) {
  .experience {
    transition: all 0.3s ease;
  }
}

We start with the essentials and layer on enhancements when conditions allow. But we also respect when users need less motion, less complexity, less stuff. It's not about degrading – it's about being thoughtfully adaptive.

It's like a friend, full of energy and excitement at a party, ready to celebrate with you. But when the mood shifts, they’re right there with you in the quiet moments, offering comfort and understanding. The key is maintaining that core while being flexible about the rest.

The Code We Live By

As css developers, we spend time crafting media queries - debugging responsive layouts, fine-tuning breakpoints, ensuring our sites work seamlessly across devices. But next time you're wrestling with a particularly stubborn viewport issue, just pause for a moment.

@media (max-width: 768px) {
  .navigation {
    transform: translateX(-100%);
    position: fixed;
  }
}

Look at that code. Really look at it. You're not just handling a smaller viewport – you're encoding adaptation into your work. Each media query is a small promise: "When things change, I'll be ready."

While media queries might seem like just another technical tool, they encode a profound wisdom about adaptation. They remind us that:

Different contexts require different approaches
Change is not just inevitable but normal
Flexibility is strength
Adaptation doesn't mean losing your core purpose—it means finding new ways to express it

Just like us, our code bends but doesn't break. It transforms while keeping its essence. And even if media queries might seem difficult to write, remember that they're just CSS versions of the adaptations we make every day.

So keep writing those queries, keep crafting that resilience. After all, the best code, like the best people, knows how to adapt.

Next week in "CSS is Emotional," we're diving into "The Hidden Emotions of CSS Animations" – where we'll explore how @keyframes mirror the rhythms of life. See you then!

Share your thoughts and experiences with adaptation—both in CSS and in life—in the comments below.

Yes! The CodePen used to design the banner 😊

About the Author

Emmanuel Imolorhe (EIO) is a Frontend Engineer passionate about CSS.
Check out my CSS videos on YouTube.

Connect with me

Twitter • Bluesky • Mastodon • LinkedIn • Website

Did this post help you? Have thoughts to share? Let's continue the conversation in the comments below!

CSS is Emotional: z-index and the Hierarchy of Needs

EIO • Emmanuel Imolorhe — Tue, 07 Jan 2025 01:28:16 +0000

In the physical world, we all want to be seen. To be acknowledged. To matter. Some days we want to stand at the forefront, commanding attention. Other times, we prefer to recede into the background, letting others take center stage. This interplay of visibility and prominence isn't just a human experience—it's perfectly mirrored in one of CSS's most misunderstood properties: z-index.

z-index: 6 | Understanding `z-index`

Imagine shuffling papers on a desk. Even though the desk is flat, papers stack in layers—some on top, others below. That's exactly what z-index does on websites. If you're familiar with tools like Canva, PowerPoint, Photoshop, or Figma, you know this feature as "Send to Back" or more accurately, "Arrange" or "Position".

Your screen shows things in width and height, but when elements need to overlap (like a popup appearing over a page), z-index determines what goes on top. Higher numbers rise to the front, lower numbers settle to the back.

You experience this every day: when your phone's notification slides down over everything else, the menu that pops out from the side, or when clicking a photo makes it pop up larger while darkening what's behind it. All of these effects rely on z-index to determine what should appear closest to you, even though everything is technically displayed on your flat screen.

z-index: 5 | The Struggle for Significance

When we set a z-index value, what we're really saying is: "This element matters. It needs to be seen." It's a declaration of importance, a way of saying, "Pay attention to this." Sound familiar? It's like Maslow's hierarchy of needs, where after securing our basic physiological and safety needs, we seek esteem and self-actualization—the need to be recognized, to achieve our potential, to rise above.

.whatsapp-notification {
  z-index: 999;
  /* Please, notice me. This is important. */
}

But here's where it gets interesting: just like in life, prominence in CSS isn't simply about shouting the loudest or climbing the highest. A z-index of 99999 doesn't guarantee visibility, just as being the loudest person in the room doesn't guarantee being heard. Context matters. Stacking contexts, just like the two transparent boxes in the banner above, are like social circles or organizational hierarchies—complex systems where your relative position depends on more than just your individual assertions.

z-index: 4 | The Hidden Complexity of Visibility

Have you ever felt invisible despite your best efforts to be seen? That's the position: static of human interaction. No matter what z-index value you give it, a statically positioned element refuses to leave its place in the document flow. And static is the default position value for all elements in CSS, serving as a humbling reminder that, sometimes, before we can stand out, we may need to step outside our comfort zone:

.dreaming-of-standing-out {
  z-index: 999; /* Big dreams */

  /* This won't work... */
  position: static;
  /* ...because you can't find progress in your comfort zone. */
}

.actually-standing-out {
  z-index: 1; /* Simple steps in the right direction */

  /* This will work */
  position: relative; /* Positioned for greatness */
}

z-index: 3 | The Paradox of Stacking Contexts

Perhaps the most profound lesson z-index teaches us is about perspective and relative truth. What appears "on top" from one vantage point might be completely hidden from another. Each stacking context is like a separate social sphere or cultural context—with its own rules, hierarchies, and definitions of prominence. Again, see the boxes in the banner above.

.box-1 {
  position: relative;
  z-index: 1;
}

.box-1 > .orange-sheet-with-circle {
  position: absolute;
  z-index: 999999; /* Still won't show above .box-2 */
}

.box-2 {
  position: relative;
  z-index: 2; /* Appears above .child despite lower value */
}

This code reveals a truth about both CSS and life: our perceived importance often depends more on our context than our individual efforts. A modest z-index in the right stacking context can place an element above another with a much higher value—just as quiet wisdom in the right moment can speak louder than grand gestures.

z-index: 2 | Finding Balance in the Stack

Just as we learn to balance our need for recognition with our role in the community, working with z-index teaches us about the delicate balance between standing out and fitting in. Here are some patterns I've learned to ~~code~~ live by:

Start Small: Don't jump to z-index: 9999. Begin with small, intentional numbers. In life and CSS, sustainable prominence comes from measured steps, not dramatic leaps. Of course, there are exceptions—this is simply a "best practice."
Consider Context: Before increasing z-index, check if the stacking context is what needs adjustment. Sometimes, our visibility issues stem from the systems we're operating within, not our individual elevation.
Document Your Intentions: When you do need high z-index values, leave comments explaining why. Future you (and your team) will appreciate understanding the emotional and technical context of these decisions:

/* z-index: 100 - Critical user notifications
   z-index: 50  - Modal overlays
   z-index: 10  - Navigation elements
   z-index: 1   - Standard interactive elements */

z-index: 1 | The Liberation of Letting Go

Perhaps the most liberating realization about z-index is that not everything needs to fight for the highest position. Some elements serve their purpose best at their default stacking level. In life, too, there's peace in accepting that we don't always need to be the most visible, the most prominent, the highest-stacked element in every context.

z-index: 0 | Kairos and Purpose

z-index isn't just a CSS property—it's a mirror reflecting our very human need to be seen, to matter, to rise above. But like all tools that deal with hierarchy and visibility, it teaches us that true prominence isn't about having the highest number. It's about finding the right position, in the right context, at the right time.

The next time you find yourself reaching for z-index: 9999, pause. Ask yourself: What am I really trying to elevate here? Is this about technical layering, or is there something deeper—a need for recognition, for importance, for visibility—that I'm trying to express through code?

Because in the end, the most elegant CSS, like the most fulfilling life, isn't about rising above everything else. It's about finding your proper place in the stack, contributing to the harmony of the whole, and knowing when to step forward—and when to let others shine.

Next week, we'll explore how media queries teach us about adapting to change. Until then, I'd love to hear your thoughts: When was the last time you used z-index? What emotions were driving that decision? Share your stories in the comments below.

Here's the CodePen used to design the banner 😊

About the Author

Emmanuel Imolorhe (EIO) is a Frontend Engineer passionate about CSS.
Check out my CSS videos on YouTube.

Connect with me

Twitter • Bluesky • Mastodon • LinkedIn • Website

Did this post help you? Have thoughts to share? Let's continue the conversation in the comments below!

CSS is Emotional: The Psychology of Specificity

EIO • Emmanuel Imolorhe — Tue, 31 Dec 2024 03:09:05 +0000

In the ever-cascading world of CSS, few concepts trigger as much emotional response as specificity. It's that invisible force that determines which styles win out when multiple declarations compete for the same element. But beyond the calculations of IDs, classes, and elements lies a deeper truth: specificity is a mirror of how we handle conflicts, set boundaries, and navigate relationships in our daily lives.

The Weight of Words

Consider this common CSS scenario:

The ID selector wins, not because it came last, but because it carries more weight. How familiar does this feel? Like when someone uses your full name instead of your nickname, or when a parent's "I mean it" carries more authority than their casual requests. Specificity in CSS, like emphasis in human communication, is about the power we give to different forms of expression.

The Struggle for Identity

Think about how you introduce yourself at different events:

At a family gathering: "I'm Aunty Tope's son"
At work: "I'm the Frontend lead on the web team"
At a high school reunion: "I'm the guy who always topped the class."

Yeah, there's a little room for some show off here and there...😎

Like CSS selectors stacking up (article p .highlight), we layer our identities based on context. Each additional descriptor makes us more specific, more unique, but also potentially more rigid in how others can relate to us.

An element might be both a paragraph and highlighted content, but which identity takes precedence? The more specific selector wins, just as certain aspects of our identity become more prominent in different contexts.

The `!important` Declaration: Nuclear Powers

When my mom shouts my full name — Emmanuel, Oluwaseyi, Imolorhe!!! — I just know I'm in trouble. It's like the sound of an alarm, my brain starts screaming, "May Day! May Day!!". Similarly, !important in CSS is the nuclear option—an override that trumps everything else. Like raising your voice in an argument or pulling rank, it's a powerful tool, but one that should be used sparingly and with caution:

It is like sending an email in all caps or ending a message with multiple exclamation points. It's not just a technical override—it's an emotional one. It says, "I don't care what anyone else thinks, this is how it MUST be." Like all powerful tools, it's not inherently bad, but its overuse often signals deeper architectural or communication problems.

Finding Balance

The real art of CSS specificity, like emotional intelligence, lies not in knowing how to win every conflict, but in creating systems that minimize conflicts in the first place. It's about:

Writing selectors that are only as specific as they need to be
Creating clear hierarchies that reflect natural relationships
Understanding when to enforce rules strictly and when to allow flexibility
Recognizing that sometimes the most powerful approach is the simplest one

The most elegant CSS solutions often come from understanding the natural hierarchy of our elements. This mirrors how our most successful relationships work—not through force or control, but through understanding and respecting natural boundaries and connections.

The Art of Flexible Specificity

Here are some lessons that apply equally to CSS specificity and emotional intelligence:

Clarity beats force: A well-structured system rarely needs heavy-handed specificity
Context matters: What works in one situation might cause problems in another
Future-proof your choices: Consider how today's decisions will affect tomorrow's flexibility
Respect the cascade: Most times letting things naturally flow is better than forcing control

The Path Forward

Specificity in CSS teaches us that power isn't just about strength—it's about precision, context, and understanding. When we write our styles, we're not just coding; we're creating relationships, setting boundaries, and defining hierarchies. By understanding the psychology behind specificity, we can write better CSS and, perhaps, navigate our human relationships with more grace and wisdom.

Next week, we'll explore how z-index reflects our fundamental needs for visibility, prominence, and attention in both our digital and personal lives. Until then, take a moment to consider: How do you handle specificity in your code, and what might it reveal about how you handle authority and identity in your life?

Share your thoughts and experiences with specificity—both in CSS and in life—in the comments below.

Here's the CodePen used to design the banner 😊

About the Author

Emmanuel Imolorhe (EIO) is a Frontend Engineer passionate about CSS.
Check out my CSS videos on YouTube.

Connect with me

Twitter • Bluesky • Mastodon • LinkedIn • Website

Did this post help you? Have thoughts to share? Let's continue the conversation in the comments below!

CSS is Emotional: Flexbox & Grid - A Love Story About Compromise

EIO • Emmanuel Imolorhe — Tue, 17 Dec 2024 15:05:37 +0000

Every great relationship is about balance. About finding space for each other. About knowing when to hold tight and when to give way. In the world of CSS, we see a complex negotiation of connection, where parents—Grid and Flexbox—teach their children the most profound lesson of all: how to truly care for one another.

Different Paths, Same Love

Grid is the parent of structured love. Precise. Predictable. Every moment carefully planned, every interaction meticulously organized:

.grid-parent {
    display: grid;  /* There is a place for everyone */
    grid-template-columns: repeat(3, 1fr);  /* Perfectly organized */
}

Flexbox arrives differently—a parent of fluid love. Responsive. Adaptive. Always ready to reshape their approach:

.flex-parent {
    display: flex; /* Everyone finds their place */
    flex-wrap: wrap; /* Ready to bend over backwards */
}

Adaptive Love

The children of Flexbox learn the most nuanced lesson—Truly listen and create space for each other's unique needs:

.ambitious-sibling {
    flex-grow: 2;  /* "I need more space!" */
}

.supportive-sibling {
    flex-grow: 1;  /* Expanding to meet another's need */
}

.reserved-sibling {
    flex-grow: 0;  /* "I'm content with what I have" */
}

Imagine a moment: One sibling struggles. The others don't compete—they adjust. They redistribute their emotional bandwidth, making room for vulnerability.

The Compromise

Grid's children learn structure. Flexbox's children learn fluidity.
But the magic happens in between—where love becomes a dynamic, breathing entity.

Flexbox whispers: "Let's figure this out together."
Grid responds: "I've already planned everything for you."

Beyond Code

This is more than just a technical choice. It’s not about which method is better—it’s about designing spaces where each element feels at home.

Flexbox teaches adaptability.
Grid offers security.

Your Love Algorithm

How do you balance structure and spontaneity?
Where in your code (and life) are you too rigid?
When does structure serve you best?

CI/CD - Compromise Intelligently / Coexist Dynamically

True love isn't about perfect alignment. It's about continuous adjustment, about creating a space where everyone can grow.

What layout of life are you currently navigating? Share your story of compromise and connection.

Next week: "The Psychology of Specificity"

Here's the CodePen used to design the banner 😊

About the Author

Emmanuel Imolorhe (EIO) is a Frontend Engineer passionate about CSS.
Check out my CSS videos on YouTube.

Connect with me

Twitter • Bluesky • LinkedIn • Website

Did this post help you? Have thoughts to share? Let's continue the conversation in the comments below!

CSS is Emotional: Inheritance - The Family Drama of CSS

EIO • Emmanuel Imolorhe — Sun, 08 Dec 2024 19:27:35 +0000

In the grand narrative of our stylesheets, inheritance is where things get complicated. It's where CSS starts to feel less like a technical specification and more like a family reunion—complete with unresolved tensions, unexpected behaviors, and the profound ways our past shapes our present.

The Roots of Inheritance

Just like in a family, in CSS, every element inherits certain characteristics from its parent. Some traits are passed down deliberately, some accidentally, and some we spend years trying to override. Sound familiar?

Consider a simple example:

This isn't just code. This is a lineage. The body is like a primogenitor of the bloodline, setting the foundational tone for everything that comes after. Every child element begins its life carrying those initial traits—the default font, the base color, the underlying mood of the entire document.

Overriding the Family Legacy

But here's where it gets interesting: in both families and CSS, inheritance doesn't mean imprisonment. Just as we can choose our path different from our parents, CSS elements can declare their own identity:

.content h2 {
  font-family: "Times New Roman", serif;
  /* Breaking free from the inherited font */

  span {
    color: white;
    /* The typographic equivalent of
       dying your hair a wild color */
  }
}

It's an act of declaration. Of individuality. Of saying, "I respect where I came from, but I'm not bound by it."

The Unintended Inheritances

Not all inherited traits are welcome. Sometimes, we inherit CSS properties we didn't ask for—just like those family quirks we never requested. A nested <div> might suddenly find itself with margins or paddings it never wanted, a digital echo of those family dynamics where you unexpectedly find yourself carrying forward someone else's emotional baggage.

Modern CSS gives us powerful tools to manage this — 3 values we can use to control inheritance: initial, inherit and unset.

initial is disowning the family legacy completely — "I'm starting fresh, no family history here."

inherit is fully embracing your roots — "I am exactly like my parents, proud and unchanged."

unset is the nuanced family member who says, "I'll keep what works from our family story, but I'm free to redefine the rest." It respects the inheritance where it makes sense, but isn't afraid to break the pattern when needed.

It's like family therapy, but for your stylesheet.

.going-rogue {
    all: initial;
    /* Complete reset! */
}

.embrace-roots {
    color: inherit;
    /* Proudly continue the family legacy. */
}

.all-about-balance {
    all: unset;
    /* Mindfully balance inheritance and individuality. */
}

A Profound Metaphor

Inheritance in CSS is more than a technical mechanism. It's a reflection of how traits, memories, and experiences flow through systems—be they familial, cultural, or digital.

Some traits we cherish and preserve. Some we modify. Some we reject entirely. But they all start somewhere, passed down through unseen connections, shaping what comes next.

Cascading
Style
Sheet

Yup! You are welcome 😌

In CSS, as in life, we are never truly starting from scratch. We are always building upon something that came before. Inheritance is the silent storyteller of our stylesheets, the foundational thread that connects elements like generations through the cascade, giving CSS its dynamic, interconnected nature.

Reflection Questions

What "inherited traits" do you carry in your code?
How deliberately are you choosing which styles (and which emotional legacies) you pass forward?
When was the last time you consciously "overrode" an inherited pattern—in your stylesheet or in your life?

I'm eager to hear from you - share your answers in the comments.

Next week: "Flexbox & Grid: A Love Story About Compromise"

Share your inheritance stories—both CSS and personal—in the comments below.

As usual, here's the CodePen used to design the banner 😊

About the Author

Emmanuel Imolorhe (EIO) is a Frontend Engineer passionate about CSS.
Check out my CSS videos on YouTube.

Connect with me

Twitter • Bluesky • Mastodon • LinkedIn • Website

Did this post help you? Have thoughts to share? Let's continue the conversation in the comments below!

CSS is Emotional: The Box Model of Personal Space

EIO • Emmanuel Imolorhe — Sun, 01 Dec 2024 16:00:00 +0000

We are living, breathing websites – each of us a complex layout system constantly negotiating space. Our boundaries flex like responsive design, expanding and contracting with every human interaction. Some of us stretch to max-width: 100%, eager to connect. Others contract to display: none, retreating from the world's overwhelming complexity.

The Algorithm of Human Connection

Every interaction is a silent calculation, an intricate CSS algorithm playing out in real-time. We are constantly rendering and re-rendering our personal boundaries, adjusting our emotional layouts with each social encounter.

Margins: The Invisible Force Fields

Have you ever felt that inexplicable discomfort when someone stands just a little too close? That's margins in action – the invisible buffer zones that determine exactly how close is too close.

Think about the last time you stood in an elevator. That unspoken distance between strangers? Pure margin implementation. Nobody taught you to leave exactly one foot and six inches between bodies, yet everyone instinctively knows the rule. And this is not a covid thing. It's a human margin: auto – naturally centered, perfectly distant.

In web design, margins prevent elements from colliding. In human interaction, they prevent emotional bruising. They are the diplomatic zones, the neutral territories where self-preservation negotiates with social connection.

Borders: Defining Emotional Territory

Borders are declarations. Clean, explicit lines that define territory. They're the unspoken rules of queuing, the subtle head shake that prevents unwanted conversations, the polite "no" that maintains personal integrity.

Padding: The Comfort Zone

Padding enters as the soft armor of self – the gentle cushion between vulnerability and the world's sharp interactions. It's how you use small talk to ease into difficult conversations. Too little padding, and every interaction feels like raw exposure. Too much, and you become an insulated element, disconnected from the larger layout of human experience.

Imagine padding as the layer of politeness in a tough conversation, the buffer of humor when tensions rise, the gentle "how are you" before diving into serious topics.

Compassionate Coding

Understanding our personal layout is an act of self-compassion. We are not static websites, but dynamic, responsive systems constantly adapting to new inputs, new contexts, new connections.

Each interaction is a moment of recompilation, a chance to adjust our emotional stylesheet, to refine our boundaries with greater understanding and grace. Just as a skilled developer knows that the most elegant code is not about perfection, but about adaptability and empathy, so too are our most meaningful human connections built on the same principles of flexible, thoughtful design.

So, the next time you're writing CSS, remember: you're not just defining a layout. You're mapping emotional territory, one pixel at a time.

Next week: Inheritance – The Family Drama of CSS

Here's the CodePen used to design the banner 😊

About the Author

Emmanuel Imolorhe (EIO) is a Frontend Engineer passionate about CSS.
Check out my CSS videos on YouTube.

Connect with me

Twitter • Bluesky • LinkedIn • Website

Did this post help you? Have thoughts to share? Let's continue the conversation in the comments below!

CSS is Emotional: A Series About Code, Feelings, and the Space Between

EIO • Emmanuel Imolorhe — Sun, 24 Nov 2024 20:41:20 +0000

We tend to think of CSS as a purely technical tool — a means to an end, a way to make websites look pretty. But after years of writing css, debugging layouts, and battling with specificity, I've come to a different conclusion:
CSS is deeply, inherently emotional ✨

I'm not talking about the frustration of centering a div (though we'll get to that) or the css-in-js library everyone knows 🙃
I'm talking about how CSS, at its core, reflects fundamental human experiences. Every property, every declaration, every cascade mirrors something deeply personal about how we interact with the world and each other.

Think about it 🤔

What is the box model if not a metaphor for personal space? What is inheritance if not a reflection of family dynamics? What are media queries if not lessons in adaptation and resilience?

Over the next 10 weeks, we'll explore these parallels in detail. We'll dive into how flexbox teaches us about compromise, how z-index reflects our desire for attention, and how debugging CSS can be an unexpected journey of self-discovery 💫

This series isn't just about becoming a better CSS developer (though you will 😎). It's about understanding how our technical tools reflect our human experiences, and how acknowledging this connection can make us both better developers and more empathetic humans.

Here's what's coming up:

The Box Model of Personal Space
Inheritance: The Family Drama of CSS
Flexbox & Grid: A Love Story About Compromise
The Psychology of Specificity
z-index and the Hierarchy of Needs
Media Queries: Adapting to Change
The Hidden Emotions of CSS Animations
CSS Custom Properties: The Art of Self-Expression
Debugging CSS: A Journey of Self-Discovery
Technical Debt: The Emotional Baggage of CSS

Each week, we'll explore one of these topics in depth, drawing parallels between technical concepts and emotional experiences. We'll share stories, examine code, and maybe even learn something about ourselves in the process 🥹

Whether you're a seasoned developer or just starting your journey with CSS, I invite you to join me in this exploration of the more human side of our stylesheets. Because at the end of the day, CSS isn't just about making things look good — it's about understanding the invisible boxes, relationships, and feelings that shape our digital and emotional worlds 💫

Welcome to "CSS is Emotional" — New posts every Sunday.
Subscribe to follow along.
I'd love to hear which topic you're most excited about! Drop a comment and let me know 😊

See you next week for our first deep dive — the emotional world of The Box Model 🎉

Here's the CodePen used to design the banner 😊

About the Author

Emmanuel Imolorhe (EIO) is a Frontend Engineer passionate about CSS.
Check out my CSS videos on YouTube.

Connect with me

Twitter • Bluesky • LinkedIn • Website

Did this post help you? Have thoughts to share? Let's continue the conversation in the comments below!

DEV Community: EIO • Emmanuel Imolorhe

CSS is Emotional: A Conversation with Eric Meyer

CSS: A Language of Its Own

The Human-Centered Web

Rebecca Purple: When Humanity and Technology Meets

Bringing Our Humanity to Our Work

Looking to the Future

Moving Forward

About the Author

Connect with me

CSS is Emotional: Technical Debt - The Emotional Baggage of CSS

Later never comes

And with debt came dread

But there is another way

In the smallest change, there is potential

And with clarity, comes confidence

Out of imperfection mastery will arise

About the Author

Connect with me

CSS is Emotional: Debugging CSS - A Journey of Self-Discovery

Confronting Reality: The First Step to Better CSS

The Inspector: Looking Beneath the Surface

Eureka!

The Methodical Approach

The Importance of Rest

The Community Connection

The Evolution of Approach

The Ongoing Journey

About the Author

Connect with me

CSS is Emotional: CSS Custom Properties - The Art of Self-Expression

Lesson 1: Naming is Power

Lesson 2: The Cascade of Emotion

Lesson 3: Computed Values Create Relationships

Lesson 4: Dynamic Updates Reveal Adaptability

Lesson 5: @property - Defining Emotional Boundaries

Lesson 6: Contextual Emotional Scoping

Lesson 7: The Maintenance Reality

Conclusion: Code as a Canvas of Self-Expression

About the Author

Connect with me

CSS is Emotional: The Hidden Emotions of CSS Animations

Time Dilation (Hello Einstein 👋)

The Mathematics of Emotion

The Scrolls of Time

Time's Accessibility Matrix

100% {...}

About the Author

Connect with me

CSS is Emotional: Media Queries - Adapting to Change

Different Screens, Different Needs

Breaking Points Are Actually Turning Points

The Art of Progressive Enhancement

The Code We Live By

About the Author

Connect with me

CSS is Emotional: z-index and the Hierarchy of Needs

z-index: 6 | Understanding z-index

z-index: 5 | The Struggle for Significance

z-index: 4 | The Hidden Complexity of Visibility

z-index: 3 | The Paradox of Stacking Contexts

z-index: 2 | Finding Balance in the Stack

z-index: 1 | The Liberation of Letting Go

z-index: 0 | Kairos and Purpose

About the Author

Connect with me

CSS is Emotional: The Psychology of Specificity

The Weight of Words

The Struggle for Identity

The !important Declaration: Nuclear Powers

Finding Balance

The Art of Flexible Specificity

The Path Forward

About the Author

Connect with me

CSS is Emotional: Flexbox & Grid - A Love Story About Compromise

Different Paths, Same Love

Adaptive Love

The Compromise

Beyond Code

z-index: 6 | Understanding `z-index`

The `!important` Declaration: Nuclear Powers