This weeks’s theme is and, quite predictably, CSS. Let’s dive right in! Or if you just wanna look at some wonderfully executed Halloween-themed front end design, check out our favorite Pens.
 
From the blog

✻ To kick things off, this week Sarah Drasner described two methods for maintaining styles by comparing them to two different programming paradigms: functional and object-oriented. There’s a lot of quote-worthy bits in this piece, but here’s our favourite:

The worst code is code that behaves a way that you can’t predict, quietly, all over the place.

Sarah argues that we don’t need rockstars or JavaScript ninjas to help us keep large applications consistent and beautiful, instead we need janitors, diligent folks that will clean up a codebase as time passes without any hubris or chutzpah.

✻ Next, over on the MediaTemple blog, Chris wrote about carousels:

What I am here to talk about is the situation where you do want a carousel and to resist the temptation to reach for a wheelbarrow full of code to do so. I guarantee there are people who’ve picked an entire CMS because they thought they needed it to make a carousel. No shame. We’re all learning.

I have good news: Carousels don’t have to be complicated. They don’t have to require a ton of code or do anything that you can’t wrap your head around with basic HTML, CSS, and JavaScript knowledge.

✻ With a helpful combination of media queries and the background-image property, Chris then looked at how to implement responsive images in CSS:

The term “responsive images” has come to mean “responsive images in HTML”, in other words, the srcset and sizes attribute for and the element. But how do the capabilities that these things provide map to CSS?

CSS generally wasn’t really involved in the responsive images journey of the last few years. That’s for good reason: CSS already has the tools. Responsive images was, in a sense, just catching up to what CSS could already do. Let’s take a look.

✻ Geoff Graham wrote about constructive criticism and how to get it:

Something that has been on my mind lately is how we talk about the deliverables we work on as designers and developers. There are plenty of times when we want feedback on our projects and turn to our friends, co-workers, colleagues, Twitter, and all kinds of other people for their honest opinions about the quality of our work.

But this can be problematic. The feedback we get is often not what we hoped for. In some cases, it can feel personal, which is almost never what we hope for.

✻ Chris then takes a look at the differences between preprocessor and CSS variables. The neatest thing about CSS variables in particular is the ability to manipulate them in JavaScript, as shown in this demo by Rob Dodson where you can change the number of columns and the size of the margins, simply by manipulating a variable:

✻ Returning to our theme of festive spookiness, Chris also explored weird CSS Selectors like the lobotomized owl, the Mr. Ghost selector and the scariest monster selectors that you’re likely to ever see:

✻ Sarah Drasner followed this spooky series up by digging into the scary UX patterns she notices on the web. Here’s Sarah’s thoughts on the infuriating modals we experience on a daily basis, for instance:

(Unexpected) modals are the spookiest pattern of them all. They are my personal least favorite UX pattern, because they instantaneously break focus and spatial awareness while your brain is trying to understand and map the UI. I tend to close them immediately as an annoyance, sometimes to realize I needed the information in them. They are an example of what I call “brute force UX”, the idea behind which is an example of thinking that’s a bit too lateral: “we need the user to see this, we’re going to totally disrupt them to force it in their faces”. Modals that a user triggers aren’t so bad, as they initiated an interaction, but modals that appear on a timer out of nowhere are distracting and can be infuriating.


What we’ve been reading, listening and watching

In August, Philip Walton wrote about decoupling HTML, CSS and JavaScript and he points to several flaws that developers might find themselves replicating. Namely, complex selectors and JavaScript functions that are bound to CSS selectors. He notes this particular problem:

It’s not always obvious when front-end code is tightly coupled. And this is compounded by the fact that what may seem like loose coupling from one perspective is actually tight coupling from another.

✻ ✻ ✻

Fukol is a simple flexbox grid system that is surprisingly versatile and useful, despite the slightly NSFW name and logo.

✻ ✻ ✻

Ahmad Shadeed made a great post about the :empty pseudo selector with CSS. This selector checks to sees whether an element has any content and, if it doesn’t, then it gives developers the ability to style a component differently.

Ahmad made this great example that shows what might happen if we have an element that is dependent on content:

With :empty we can remove the padding in our figcaption or otherwise hide the background color beneath the image. This makes our design more flexible and, dare I say, progressive.

✻ ✻ ✻

Jarno Rantanen made 8 simple rules for a robust, scalable CSS architecture:

This is the manifest of things I’ve learned about managing CSS in large, complex web projects during my many years of professional web development. I’ve been asked about these things enough times that having a document to point to sounded like a good idea.

✻ ✻ ✻

GitHub released Projects for Organizations. It’s sort of like Trello, where you can store all the various issues and pull requests into a single card and thereby tidy up your project.

What have you learnt this week?

Robin Rendle: This weekend I rewatched Maciej Ceglowski’s thorough and excellent talk on the web obesity crisis. He criticizes bad web performance and bad design, but it was this part in particular that made we wince with acknowledgement:

To channel a famous motivational speaker, I could go out there tonight, with the materials you’ve got, and rewrite the sites I showed you at the start of this talk to make them load in under a second. In two hours.

Can you? Can you?

Of course you can! It’s not hard! We knew how to make small websites in 2002. It’s not like the secret has been lost to history, like Greek fire or Damascus steel.

But we face pressure to make these sites bloated.

I bet if you went to a client and presented a 200 kilobyte site template, you’d be fired. Even if it looked great and somehow included all the tracking and ads and social media crap they insisted on putting in. It’s just so far out of the realm of the imaginable at this point.

This had me wondering whether we can change these expectations and start a new sort of emphasis on web performance over other priorities that a business might have. Much like the early days of CSS and HTML, where prolific web designers banded together to explain why decoupling these technologies was important, we need a new movement for web performance. 

Although, perhaps we don’t need a movement outside an organization that coordinates these efforts. Instead, as designers and developers we can agree upon a set of underlying principles that influences all of the decisions that might go into making a website.

In this way, I tend to think of a website much like Maslow’s hierarchy of needs: a list of requirements that people need to live a successful life:

I’m not sure about the soundness of this research or of the idea in general, but I like the way in which certain requirements are more important than others. Specifically, I like the idea if we apply it to web design. How do we balance all of the conflicting opinions and needs of designers, developers and businesses? Well, I think that organizations should write the most essential, vital information that needs to be sent across the wire.

So, let’s say you’re a publisher for a newspaper, your hierarchy of user needs might look like this:

This isn’t new at all, it’s progressive enhancement in another form, but what’s most exciting is that with this information at hand, designers, developers and product managers can make decisions faster because they’ve already declared their allegiance to a specific problem. What happens if a designer wants to add a new feature but it compromises the speed with which the text of the story renders to the screen? Well, sorry, but that feature simply isn’t as important. It needs to be redesigned or we need to adjust our hierarchy of needs entirely.

The root cause of poor web performance is the same cause of bad interface design. 

Take carousels, for instance; they often reflect an organization’s inability to compromise, to make the hard decisions and prioritize one feature over another. Yet! If we have this hierarchy set in place then we might be more capable of arguing on behalf of our users, and our decisions will more regularly align with their best interests.

***

Chris Coyier: Just a baby thought from me. 

I feel like maybe five years ago there used to be a whole crapton of "web design gallery" sites. Now it feels like there aren't. You can find some, for sure, but it's not like it was. Then I thought, maybe it's just me. Maybe I was more tuned into that scene back then and less-so now, so it only seems like there are less of them to me but really it's the same as ever. Or maybe people figured out it was hard to justify building and maintaining a site like that? Or maybe it's easier to find inspiration out there on other kinds of sites? Or maybe there is less source material out there because web design is less experimentally exciting? 

Unanswerable questions are like my hobby.

Until next time!
Team CSS-Tricks

(Did you know CodePen has a 14-day free trial for the PRO features? You can activate it any time, regardless of when you signed up.)
Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list