This week I was working on transferring the designs for the project I am on from Figma to a Drupal theme, when I came across a CSS property I’d never encountered before: mix-blend-mode.

WTF is mix-blend-mode?
Even though I’ve been doing front-end work for over 20 years, in my defense there are at least 520 different CSS properties, so coming across a new one shouldn’t be that surprising really.

mix-blend-mode is actually a pretty cool property:

… sets how an element’s content should blend with the content of the element’s parent and the element’s background.

• MDN

So it’s basically a way to make the text or other elements blend in with the background image/color that you are applying to it’s parent element. It can do a lot of really neat things like lighten, darken, multiply, hard and soft light and a bunch more (really, checkout the MDN link for some cool examples).

Which is all fun and good, except what if you need to blend the background but don’t want the text to blend in?

Here’s what I was dealing with:

The styling scenario is that the client wanted the textured background all across the footer, but for the “utility links” and the copyright, they should also have the background but with a darker overlay on top of it. The designer didn’t provide a separate file for that part of the background in Figma (grr…) but used mix-blend-mode instead.

In case you can’t make it out (and I don’t blame you), the arrow in the screenshot is pointing to the utility links that, thanks to mix-blend-mode, are impossible to read.

So if you have to use mix-blend-mode but you need the text to appear as normal, what do you do?

Enter another (new to me) CSS propery: isolation.

Isolate all the things!

In essence, I think about isolation similar to the stacking principal of z-index in that you are isolating an element from it’s parent, a la putting an element atop of another one with z-index.

That’s basically exactly how MDN describes it as well:

The isolation CSS property determines whether an element must create a new stacking context.

It works different from the normal box model of CSS though, and is a bit more like CSS @container in my mind, in that you are taking something within another element and pulling it out and away from the styling of it’s parent. It’s less about positioning like z-index would be, and more about controlling what gets applied to a more general container with a background image/color. Again, that’s how I think about it, you may see it differently :)

The isolation property has a default of auto and can also use standard items like inherit, initial, revert, revert-layer (for CSS @layers) and unset . But the one that you’re gonna want to use in many cases is simply isolation: isolate;

One of the keys to using it though, is that you need to set it to position: relative in order for it to take effect. Doing that should isolate your text from the background color/image of the parent and make it stand out.

In my specific use case though, with only part of the parent element having the mix-blend-mode (specifically mix-blend-mode: color-burn) applied, since the rest of the footer needed to have the standard background image without any color change, I had to get a little bit trickier.

I wrapped the two divs, .utility-links and .copyright into a separate div wrapper called .bottom-footer-wrapper. I gave it a position: relative property and then, using the :before pseudo class on .bottom-footer-wrapper, applied the mix-blend-mode to that part specifically.

Within the pseudo class, I set it to be absolutely positioned and a width/height of 100%, and to ensure it appeared, set content: ""; . After that, it’s just applying the mix-blend-mode and we are all set.

Here is a quick Codepen example that I whipped up, since Micro.blog ain’t the best at displaying chunks of code:

See the Pen Isolating elements within mix-blend-mode by Adam Varn (@hotsauce) on CodePen.

And here is my finished example, with white links and proper styling!

Hopefully this post will help others who may have had the same problem I did in the past, but also show that there are still so many undiscovered CSS properties out there that we can use!

I’ve been a “front of the front” front-end developer for over 20 years now, and it has been so refreshing lately to see a lot of respected FEDs like Andy Bell and Jared White push back on the idea of how every site should be built using a JS framework.

My relationship with JavaScript has always been very mixed. I never formally sat down to learn it until about 18 months ago, getting by with just hacked together scripts from Stack Overflow or help from other developers (such as the awesome other FEDs at Lullabot where I work). Lullabot knew this when they hired me but fortunately, my skills with CSS, HTML and Drupal theming (where I primarily work) were enough for them to take me on, and for that I am forever grateful.

Part of the reason I never dove into vanilla JS was that I was busy. For 11 years, I ran my own Drupal development company as a solo developer and on top of that, was a partial stay at home dad for my two kids. Learning something new that I didn’t always see the practical purpose for on a project was never front of mind, I would much rather spend the weekend with my kids than studying docs, and I was thankfully able to get by without it.

But that didn’t mean I wasn’t aware. Starting in 2015 or so, the idea of using a JS framework to build a website really began to spread in the dev circles I was in, and it made me feel less-than as a developer. If everyone else was using this really awesome thing, and I wasn’t, did that mean I was going to get left behind, become a dinosaur of a past era and thus unemployable? It was always a thought in my mind, causing a sort of internal anxiety that still persists today. Having technical knowledge debt is one thing but knowing you have that debt as you continue your day to day job is something all together. It felt like JS frameworks were going to eat the web, and I was going to be gobbled up too.

But as Andy points out in his blog post, that simply didn’t happen. Citing a study from W3Techs, it turns out that React and other frameworks still aren’t doing much gobbling of anything at all.

React is used by 4.0% of all the websites whose JavaScript library we know. This is 3.3% of all websites.

That’s…not a lot of sites, especially when WordPress alone makes up 53% of all websites. So then why the anxiety? As Andy discusses, it was just a very loud, very vocal minority of developers who presented the need for a better DX (Developer Experience) over all else, and - for a while - JS frameworks were the things to do that. Everywhere I looked, from Dev Twitter to blog posts to general conversation, everyone was talking about how this or that framework was the best way forward for making better sites, it made things better for developers, unicorns and rainbows etc etc.

But in hindsight, what I thought was just me languishing in my own embarrassment over not learning the hottest new thing, was really just me being stuck in a dev echo chamber with people I respected telling me something I just had to know and me just…well, feeling bad for not learning it.

Had I stopped to really think about this, I would have seen that everything wasn’t all unicorns and rainbows; the web is made up of a lot of different tools, doing a lot of different things, and no one tool is perfect for every job or need. I had many scenarios when I ran my company where someone wanted a custom website and while I could have probably sold them on using Drupal, it would have been way overkill for what their needs were, adding unneeded layers of complexity, and instead I would steer them towards using Wordpress or something like SquareSpace or Wix.

That’s what’s at the core of choosing any tool for a project: what is the need for the client. Because at the end of the day, most stakeholders in a project don’t generally care how the thing is built, just that it is built and is built in a way that they like and can use. Developers and the companies they work for sell a product, an experience, an expectation. And unless they have a stakeholder who is just enraptured with a hot new thing, chances are any sort of explanation of compiling and first-paint and on and on will just go right over their heads. They hire us to be the experts, not to show off why we are experts.

That’s not to say that I am 100% adverse to learning new things. I remember years ago when CSS pre-processers first started taking root, first with LESS then with SASS. I jumped on learning those because they DID enhance my skills, and made my life easier, without sacrificing anything for my clients (I even presented on SASS back in 2014 . And today, I’m proud that I have built a foundation for myself in vanilla JS, even if it’s years later.

And yes, as developers, discovering a new tool for our toolbox is incredibly exciting, especially in the world of open source. It still gives me a little thrill when I find something that I know I will A) like working with and B) will meet a need, professionally or personally. But what I like to work with, at the end of the day, should NOT cloud how I approach a project.

When it comes to whose experience should matter the most, it should go something like this:

1). END USERS

2). CLIENTS

3). SUPPORT TEAM

453.) DEVELOPERS

Sustainability on a project should also be paramount too. Besides the cores of writing good documentation, adding comments throughout and making sure that the knowledge of how something works is embedded in multiple people should someone get hit by a bus, we shouldn’t be building things that make making changes more cumbersome than they have to be.

I (think) I see the value in something like CSS-In-JS but what happens if you just need to make a quick styling change? Rather than just editing a single line and pushing that up, you have to make the change, verify your tests, recompile everything, etc and adding extra steps to what should not be a complicated process. If we continue to focus on the best DX possible, we are hamstringing ourselves later for those who know how something works by adding unneeded work, and further mystifying a project for someone new (or not as knowledgeable) to come in after the fact.

And yes, knowing how complex systems work might also seem like built in job security for a lot of people. But it isn’t sustainable in the long run, when everyone moves on to the next shiny thing and hiring folks are left scrambling to find someone new to refactor or redo entirely a project because the winds of dev trendiness have changed. I would argue instead that it lessens job security because a company that chases the newest thing is likely to continue to do that and it puts more burden on the developer to keep up or get let go, in a much shorter time frame. The tortoise can sometimes still win the race.

I remember when Angular was the thing. Then it became React. Now it’s TypeScript. All of which made me feel like less-than as a developer, until suddenly…they didn’t. The in-crowd moved on to the next thing and I stayed where I was, growing my skills slowly, and I had a hard time even determining where I should try to focus, if I was going to attempt it at all, because the vocal minority was always carnival barking me in different directions.

But in the end, I didn’t chase the new for many years and you know what? I was able to stay in business, live comfortably enough to give my kids (most of) what they wanted and deal with genuinely happy and satisfied clients. Maybe I was an outlier and someone who got lucky, but I don’t think so. I think there are more of us out there than people realize, who had the same conflicted feeling as me.

Back to that echo chamber for a second. As Jared points out in his post, we should have realized sooner that the onus wasn’t on us to keep up with the front-end framework race but rather for those loud voices to explain why we need to run the race in the first place.

The Burden of Proof is On You, Frontend Framework Stans, Not the Vanilla Web!

So then, I ask:

• Explain to me why I need to abandon what I know to be a better developer

• Explain to me why this or that tool is going to be better for my project

• Explain to me why clients should ignore any FOUC on their site in favor of a slightly cooler experience or any other “gotchas” that come along with any tool

It’s like that line in Jurassic Park when it comes to trying to push us all towards frameworks

You don’t have to have JavaScript on your website. JS is the third leg of an already stable table, along with HTML and CSS, that makes the web work. So why are we offloading entire websites into just one? It just doesn’t make sense. Frameworks have a purpose but (again to quote Jared), the web is a polyglot of technologies that make it work and none of us should be made to feel like we have to all follow just one of them to be successful.

So yes, I’m glad - very, very glad - that other people are finally speaking up about the echo chamber a lot of us were stuck in and pointing out the flaws in always following the crowd. As I continue to grow as a web developer, I’m sure that I will adapt and learn new things as I need them. But never again will I just beat myself up for not being on the cutting edge. It’s just not worth the anxiety and stress.

I’m still here as a successful front-end developer. And I didn’t get eaten by JS frameworks.

I have a very, very low ICQ number (670140). The problem is, I can’t login to access it anymore, as the email address tied to it is long, long gone.

For people of a certain age like me, who came of age on the internet in the late 90s/early 2000s and at the end of dial-up and the lowering of walled gardens like AOL/Prodigy/Compuserve, there is a whole portion of the internet, of our younger lives, that seems to be gone forever.

We were the people who shared our of-the-moment thoughts in AIM away messages. We would spin up a new blog on Xanga, with no expectation of an audience, doing it just because we wanted to. Social media wasn’t the omnipresent force it is today, and we would just write and share, love and laugh with strangers or friends, as we settled ourselves in this emerging digital world.

To be in your teens or 20s back then was to feel like an explorer, discovering new places to express and be yourself without thought of engagement or follows or anything like that. Sure, it was nice if someone read and commented on your post but how great was it discovering a real-life friends LiveJournal and really getting a feeling of what made them, them ? We were young, we were free, and we were traipsing everywhere to plant our flag on our tiny little corner of this awesome new thing called the Internet.

Reminiscing over the old days of social media now is like the “Old Man yells at cloud” meme from The Simpsons, and that’s not what this post is about. Rather, what I’m realizing now as I become that old man yelling at the actual Cloud, is that a key part of my digital life is gone forever.

We tell our kids today that “what goes on the internet, stays on the internet” and in many ways that’s 100% true. Most social media sites let you archive and export your data; the Wayback Machine keeps an ungodly amount of information. If you post something today, it’s likely to remain online for a long, long time.

But what about the ephemeral stuff, the things that would be called “content” today but was really just a text file back then?

Where are our AIM chat logs, our ICQ conversations with now-deceased friends and long broken-up with ex’s? Did anyone ever save those IRC chats with the Quake “clan” you used to spend weekends playing at LAN parties with? Probably not.

It all just disappeared as these services merged, got bought, shut down or just changed business focus, users be damned. Today, our phones can hold 10x as many pictures as our computers at the time ever could, but in those days even if you were lucky enough to have a digital camera, you didn’t take many pictures and what you did take were shit.

Maybe if you dig hard enough, you can turn up a copy of your first website, or remember the password to that long forgotten but somehow still up blogging service, so you can frantically delete your bad poetry from your first relationship, but probably not. You’ve moved through too many computers, devices or just plain moved and threw away your Password Book (remember those?) to ever find that info again.

Humans have never been able to save every scrap of detail about our lives of course. Billions of people have come and gone on Earth with barely a record of their existence. But today, most of the world is sharing and saving and posting everything they can, as if we are all doing it like we are running out of time and there is just so.much.stuff . We’ve made so much that we can never truly know what we have.

And yet having become digitally aware before all of that, before we the world truly went over the waterfall of the Internet, is very bittersweet. People younger than me now can remember it all because everyone works to remember and the pieces are all there. But I can’t.

Admittedly, a lot of the stuff back then would probably make us all cringe today, and most wouldn’t ever really be worth saving. But I wish I could at least look, at least have the opportunity to curate it. I might be able to find a scrap of something here, an old screenshot there, but that’s it – the rest is all gone.

We tend to think of a relic as something old, from long ago. But a relic can also mean something cherished or prized. For me, those relics from 20+ years ago exist only in vague memories, in “remember posting on ____” conversations, and will never be something tangible again like you get from exporting your Twitter tweets archive.

In some ways it’s better now than back then, to be drowning in a record of ourselves, but to me it will always feel incomplete. There is no “memories” suggestion on my phone for what I was chatting about or listening to in 2002, because no one (including ourselves) ever thought to save it. And I’ve come to accept it I guess, knowing that part of me won’t really be around for someone to know, but it still leaves at least a small hole in me in making up who I am.

Today, I hoard digital pictures of my kids, putting them online in a private place but also backed up to my phone, hard drive and a remote cloud service. Not just because they are pictures of them growing up, but because I know what happens if you don’t take the time to save stuff like that. How quickly we can lose the ephemeral parts of our day to day lives that don’t mean anything then, but could mean the world to us later, without even realizing that it’s gone.

Yep, started a blog.

Let’s see how it goes.