I’ve been hearing a lot about design tokens lately, and although I’ve never had to work on a project that’s needed them, I think they’re super interesting and worth jotting down a few notes about. As I understand it, the general idea is this: design tokens are an agnostic way to store variables such as typography, color, and spacing so that your design system can be shared across platforms like iOS, Android, and regular ol’ websites.
Design tokens are starting to gain a bit of momentum in the design systems community, but they’re not an entirely new concept. There’s a great talk with Jina Anne and Jon Levine from 2016 where they talk about how design tokens are used in the Lightning Design System at Salesforce. They describe the complexity of the world we’re living in where a single organization that is building multiple web apps and native applications need to feel and look the same whilst not slowing down the development team. Jina also has made an in-depth video course about design tokens and in the preview for that she writes:
With design tokens, you can capture low-level values and then use them to create the styles for your product or app. You can maintain a scalable and consistent visual system for UI development.
Let’s take just one example: you probably have a typographic scale that you want to be identical across a bunch of platforms. Instead of storing the values for that scale in a CSS file and replicating them in every app or website, they can be stored in a JSON file that will then be transformed into the code needed for all those other platforms. Something like this:
You could write your own code to take this JSON file and convert it into all the variables you might need, for example, a Sass file would depend upon these tokens and might consume them as variables to be used elsewhere in a web app. One example of a tool that can do a lot of the hard work for us is Amazon’s Style Dictionary and here’s an example of how that works in practice:
I think this is ridiculously neat stuff. And I can see how it saves a ton of duplicate code and confusion across multiple teams since it serves as a single source of truth as opposed to having several codebases that have the same design requirements and their own stylesheets to maintain. Cristiano Rastelli also wrote about managing design tokens with Style Dictionary a little while ago and goes into a lot more depth on how to get started.
Your source of truth doesn’t even have to be a JSON file! In a post from earlier this year, Pavel Laptev shows us how to make these design tokens in Figma and, by using their API, abstract those values out of design mockups and use them in a codebase.
Pavel broke up his Figma doc into separate pages for his grid, spacers, palette and typography like this:
Right now, it seems like this requires a ton of effort to set up, but I reckon that tools like Sketch and Figma are only going to make stuff like this way easier for us in the near future – they probably want the source of truth to be in their specific design tool instead of some other tool.
The last thing I want to mention is this post by Brent Jackson where he wrote up some thoughts about interoperability when it comes to design systems. Specifically, he argues that there should be a specification for design tokens so that any CSS-in-JS library could consume that code in any format or style:
Design system tokens are meant to be flexible and work cross-platform, which means different teams, different implementations, and different libraries will name things differently. This is where this specification would fit in. A lot of interoperability could be realized, if we all, for example, named our color palette colors and named the font sizes we use fontSizes. What you do beyond that and what data format you use to store these values, is up to you. It’s trivial to convert JSON to ES modules to YAML or even TOML, if that’s your thing. It’s also just a data structure, so transforming between other data structures (e.g. design tools or a GraphQL API) should also be possible. This standard also wouldn’t try to solve the extremely complex problems of how to name the colors themselves.
Brent then went ahead and created a theme specification to solve this very problem. It looks like having a single standard for writing all our variables and settings would help us if we wanted to switch from one CSS-in-JS library to another, or if we wanted to switch to some other system that we haven’t imagined yet.
Anyway, I believe that design tokens are only starting to become mainstream and their popularity is about to increase as these tools, workflows, and standards become better with time — it’s all thoroughly exciting stuff!
This is a fantastic post by Ahmad Shadeed. It digs into the practical construction of a header on a website — the kind of work that many of us regularly do. It looks like it’s going to be fairly easy to create the header at first, but it starts to get complicated as considerations for screen sizes, edge cases, interactions, and CSS layout possibilities enter the mix. This doesn’t even get into cross-browser concerns, which have been somewhat less of a struggle lately, but is always there.
It’s sometimes hard to explain the interesting and tricky situations that define our work in front-end development, and this article does a good job of showcasing that.
These two illustrations set the scene really well:
That’s not to dunk on designers. I’ve done this to myself plenty of times. Plus, any designer worth their salt thinks about these things right off the bat. The reality is that the implementation weirdness largely falls to the front-end developer and the designer can help when big choices need to be made or the solutions need to be clarified.
We rolled out a new site design on January 1! This is the 17th version of CSS-Tricks if you can believe that. The versions tend to evolve a decent amount beyond the initial launch, but we archive screenshots on this design history page. Like I said in our 2018 thank you post:
This is easily the most time, effort, and money that’s gone into a redesign since the big v10 design. There are a lot of aesthetic changes, but there was also quite a bit of UX work, business goal orientation, workflow tweaking, and backend development work that went along with it.
This is a big one! The reception so far has been pretty great, but please know that we’ll be refining it and squishing a lot of bugs here in the early days.
Here are some notes about who was involved, how it happened, and things to notice.
Kylie led this project
Kylie Timpani was the lead designer and really whole project lead on this.
I first reached out to her in April 2017, we chatted in May, and kicked off the work in June. From my perspective, this was a pretty casual process, as I had no particular deadlines and fairly loose goals. Let’s make an attractive site that does better in all ways than we do them now.
Kylie was super organized and had a very thoughtful process around every aspect of this. Just in the first block of time that Kylie allocated for this project she:
Took a complete content inventory
Dug into analytic data to understand users, traffic, and usage at a high level
Created, distributed, and analyzed a reader survey to understand readers better and answer specific questions she had for them
Chatted with all the staff members of CSS-Tricks to understand their roles, workflows, and ideas
Kylie’s obviously not the kind of the designer that just whips open a design tool and starts noodling around. As great of a visual designer as she is, the work was highly informed. She went on to speak with our advertising agency, clearly identify the site’s current strengths and weaknesses, and do light wireframing.
I’ve been using Figma for visual design stuff, and Kylie was happy to use that as the design tool. That was nice since we both have Team level access and were able to use it collaboratively. For me, it was mostly useful for being able to see and reference everything, and make notes on the designs.
We also used Asana to track what was being worked on and ultimately as a place to track bugs and places where the design implementation needed attention.
Thanks so much, Kylie for all your excellent work on this project! If anything is a bit off or buggy about the site, it’s my poor implementation. And good luck! ⤵️
⚡️ So! Speaking of big life changing news… in just a couple of weeks I'll be moving to San Francisco! I'm so SO excited to be joining @nrrrdcore and her truly incredible team over at Apple! 👩🏻💻✨
I’ll let y’all explore the design for yourself to find all the little touches we put in, but I’ll give a shout out to a few of them where there is a technical detail you might enjoy.
Clearly, we went all dark mode on this design. It’s nothing to do with the new media query, although that reminds me we might consider alternations for those who specifically set prefers-color-scheme: light;.
The brand/accent/action colors are orange and pink, which looks quite striking against the darkness but works on light backgrounds as well.
I made a quickie little Sass @mixin that allowed me to use those colors (with variations, if needed) at different angles as backgrounds:
There is something about headers that always bring out more complexity than you might expect. I recently went through this with the new CodePen header/sidebar and it as complicated for this site. Part of what complicated this one was:
It has its own set of unique breakpoints. The header is pretty full, so the breakpoints are pretty specific and unique to it.
We wanted a fixed-position (but minified) header that showed up as you scroll down.
When you’re logged in, there is a WordPress admin bar also fixed to the top of the page. I wanted to accommodate for that.
At one point, it was getting pretty messy and I wound up deleting all the CSS for the entire thing and re-wrote it, taking all the states into consideration, and writing media queries that used logic to clearly specify styles in each of those states.
The idea of a not-always-fixed-position header is interesting in and of itself. It means that:
You need to determine when to apply the fixed position
You need to make sure the shift from not-fixed to fixed (and back) doesn’t cause layout shifting
I was dead nervous about attaching an onscroll listener and doing math and such to determine when to do the switch. I’m sure it can be done responsibly, but I haven’t had great luck with that. Instead, I placed a tiny one-pixel element to the screen and attached an IntersectionObserver to it and reacted to that. That gave me the power to adjust where that is in CSS, which was a nice little touch.
One very cool feature of this design is the Mixup area on the homepage. It was one of Kylie’s ideas to show and remind people of the variety and depth of content that is here on CSS-Tricks.
The line that goes through it needs to depend on the height of the HTML content in each of those boxes. The boxes are set on a CSS grid, but they can and should still expand as needed for titles and such. Rather than try to SVG this somehow, the line is essentially stitched together though border and border-radius on individual boxes. To make it line up, I occasionally had to nudge them around with transform.
There was some z-index involved too. It was fun making mistakes along the way:
I’m kinda in love with native scroll snapping. The cards kinda have a fun animation on desktop, revealing the entire card on hover/focus, and then on mobile you can see the whole card, but are easy to thumb through:
The design called for these curved line separators:
I have a small degree of confidence with the SVG path syntax, so I took the first crack at it. I was able to design it in a way that it could draw that line OK and keep the stroke at the desired width, but it didn’t scale quite right.
I brought in SVG expert Amelia Bellamy-Royds to help me get it right. Feel free to inspect the site to see how it was done. It involves masking and nested SVGs and rectangles and transforms and all sorts of fun stuff. Amelia actually created four variations of the code and carefully noted all the pros and cons of each one. Ultimately, we went with this:
Another thing Amelia helped with was the “circle of text” design element. Kylie had these instances mocked out and I thought they were so cool and I definitely wanted to pull it off. There is a really elaborate way to do it by splitting the characters in to spans and transforming them, but that’s a bit messy compared to SVG’s <textPath>. I knew I wanted to go the SVG route, but perhaps abstract it away into a reusable component so that it wasn’t a heaping pile of code every time I want to use one.
It occurred to me that a web component might be the best way to go here because I can kind of invent the API myself. What I wanted a circle-of-text component to do:
Pass in the text to set on the circle
Declare the radius of the circle
Rotate the circle so I can start the text at any point along the circle
That makes perfect sense as a web component:
<circle-text r="3em" rotate="-90deg"> CSS is super fun & cool & I like CSS!!!
My expertise with web components is limited, so I reached out to Amelia again who is great both with web components and SVG—a perfect match! This is what she was able to do, which I easily integrated easily into this design.
Another design thing that Kylie cooked up that I was a bit perplexed by was this line:
I thought maybe SVG again, but I really wanted to nestle regular HTML content in there nicely. I was hoping to pull it over with borders or something CSS-y. I reached out to Ana Tudor who is fantastic at tricky design situations and solving them with native browser tech. Ana was able to whip up a good solution here using multiple gradient backgrounds in the main area and a border for the top right bit that flies off.
Fonts are a unique part of the loading experience of websites in that their presence (or lack of), how they appear, and how they change all play major roles in the perceived performance of the page.
I’ve had the good fortune of being able to chat with Zach Leatherman about font loading before, but I still don’t feel entirely comfortable with what the best practices are in any given situation. For this design of CSS-Tricks, I made the call to use the system font stack for most of the body copy. That has the major benefit of being instantly available to render and aesthetically seems to work well on a technical site, not to mention generally pairing well with Rubik, our header font.
But we still needed to deal with Rubik. There will be an upcoming article from Zach going into this in more details, but the gist is:
Create a minimal subsetted version of Rubik that handles the majority of usage
<link rel="preload" ... > it
Use it with @font-face using font-display
Load a more robust version in an async second stage
Nice job everyone that worked on the @css relaunch!
Look at those web fonts showing up on that 2.09s Fast 3G first render 🎉
The Forums is such a complicated area of the site to design and maintain, what I’ve done is just loaded the default bbPress styling for them, instead of trying to override things or start from scratch. I think that’ll be the best route going forward.
There is a Gallery section of this site, but I’m not even linking to it anymore as we didn’t really keep it up to date very well nor did it get used much. The URL’s still work though. Maybe it can make a return someday, but for now, I’m enjoying the reduction of some technical and content debt.
It’s somewhat boring. It’s about the same thing I’ve done forever. It’s a stock install of WordPress with a custom theme, a dozen or so plugins, and a bit of custom-coded functionality, like having the images powered by Cloudinary. It’s running on a custom Media Temple-built box so it can have PHP 7 and MySQL 5.6, plus a firewall that also acts as a CDN. It’s nice to have a pretty snappy foundation, so it’s on me as a front-end dev to keep it that way.
I used SVG for the icons, Sass for the styling, and Babel to write jQuery-based functionality in ES6. I wrote up a Gulp file to do all that processing and run the local BrowserSync dev server. Local WordPress via Local by Flywheel.
I’m actually pretty happy with the stack as it felt quick and productive to me. But I admit, part of me wishes I dug a little harder into new tech, like building webpack-based processing or trying to go all-in on a server-rendered and React-powered headless WordPress via GraphQL kinda thing. The reason I didn’t is because boring has served me so well and time is a major factor since I’m developing alone (my budget doesn’t exactly make available a whole development team). My guess is a major front-end infastructure overhaul would have tripled the dev time for questionable benefits. It still sounds like fun and might open up future doors, but hey, another time.
My last regret is that I wish I had spun up a real pattern library system from the start. I think I did OK in breaking things up into reusable parts, but the site isn’t truly componentized. As I approached the finish line, I started to see how this could have gone a bit smoother for me should I have worked with true components that accepted data and had variations and such. Native PHP isn’t great for that, so it would have forced me into some kind of templating system, and I probably wouldn’t have regretted it. If I stay in PHP next time, maybe I’d use something like Timber and Twig for all the components, and then Fractal for the pattern library since it supports Twig. I kind of dig the way Timber abstracts the data stuff from the views.
Project Wallace is a project aimed at gaining insights in your CSS over a longer period of time. It started a couple of years ago as a frustration with existing CSS analyzers that only do a one-time only analysis. As time went by, more and more features were added and now Wallace is place to go for developers who want to know if their complexicity has increased or for a designer who wants to know if all the correct colors and fonts are being used.
Bart Veneman set it up to watch CSS-Tricks, and you can see a before/after comparison and charts over time. Bart blogged about the numbers for us as well. Thanks Bart!
The true usefulness of CodePen Embed Themes came out here. The whole point of an embed theme is that you can use them to match the design of where the Pens will be embedded, and if you need to change that design, you can change them all in one fell swoop. There are probably thousands of embedded Pens on this site, and they all got updated at once with one theme change.
There are a few special things that I’ve done with CodePen embeds on this site:
The are resizable from the bottom right corner. Used jQuery. Like this.
They have a placeholder height. When you embed a Pen, you can choose how tall you want it to be. That’s how tall the <iframe> will come in as. But I’ve adjust it so that the <p> that is there before the iframe comes in will be that same height, so there is no reflow jank.
We’re gonna bring that feature to CodePen itself real soon. Notice in that RegEx above I’m also forcing the theme id. That way, all embedded Pens definitely have the correct theme, even if we forget.
Achievement unlocked: The custom scrollbar is the new feature that everyone either loves or hates
If there has been one constant in every CSS-Tricks design, it’s that there’s at least one feature people either love or hate. This time, I’m happy to announce it’s the custom scrollbar. In a sense, it’s for myself. I manually use scrollbars quite a bit and it feels both fun and highly usable to grab onto this big beefy chunk of pink love.
It’s also a little inspired by VS Code, which features a pretty beefy scrollbar itself:
There are general usability considerations about custom scrollbars for sure, but I don’t feel like they’ve been breached too heavily here, if at all. I’ve heard some “don’t mess with my browsers UI” feedback, which I sorta get, but does that mean we shouldn’t style any form controls, or even use CSS at all? (LOL.) And don’t scrollbars come from the system, not the browser?
We have plenty of bug fixing and polishing to do still on this design. If you’ve emailed or tweeted or communicated with us in some way about it, I’ve probably seen it and have been log it all to make sure it’s all addressed the best we can. Plus stay tuned for some fun new features!
Flickr announced not long ago that they are limiting free accounts to 1,000 photos. I don’t particularly mind that (because it seems like sound business sense), although it is a bit sad that a ton of photos will be nuked from the internet. I imagine the Internet Archive will swoop in and get most of it. And oh hey, the Twitter account @FlickrJubilee is showcasing Flickr users that could really use a gifted pro account so their amazing photos are not lost, if you’re feeling generous and want to contribute.
This change doesn’t affect pro accounts. I’ve been pro forever on Flickr, so my photos were never at risk, but the big change has me thinking it’s about time to spin down Flickr for myself. I’ve been keeping all my photos on iCloud/Photos for years now anyway so it seems kind redundant to keep Flickr around.
I went into the Flickr settings and exported all my photos, got a bunch of gigabytes of exported photos, and loaded them into Photos. Sadly, the exported photos have zero metadata, so there will forever be this obnoxious chunk of thousands upon thousands of photos in my Photos collection that all look like they were taken on the same day and with no location.
Anyway, that was way too long of an intro to say: I found a bunch of old website screenshots! Not a ton, but it looks like I used Flickr to store a handful of web designs I found interesting in some way a number of years back. What’s interesting today is how dated they look when they were created not that long ago. Shows how fast things change.
Here they are.
It’s not terribly surprising to me to hear people push back on the same-ness of web design these days, and to blame things like frameworks, component-driven architecture, and design systems for it. It wasn’t long ago when it seemed like we were trying harder to be fancy and unique with our designs — things like shadow treatments, reflective images and skeuomorphic enhancements. I don’t mean to make sweeping generalizations here… merely a difference between what we considered to be boring and fancy work back than compared to now, of course.
We’ve all seen articles like “The Top 5 Ways To Fix Your Sign Up Flow and Get On With Your Life.” Articles like this aren’t wrong or bad, they are just shallow and a bit junk food-y and BuzzFeed-y. Of course, a designer’s actual job is complicated, nuanced, and difficult. But deep dives into all that are far less common.
Khoi Vinh has been writing about this and points to some heavy self-reflection from Fabricio Teixeira and Caio Braga, publishers of the very popular UX Collective.
It’s clear that the currency of design discourse is really concerned with the “how” of design, not the “why” of it. As Teixeira and Braga write:
While designers tend to be skeptical of magic formulas—we’re decidedly suspicious of self-help gurus, magic diets, or miraculous career advice—we have a surprisingly high tolerance for formulaic solutions when it comes to design.
That’s a pointed criticism but, from my perspective, it’s also quite accurate.
Direct Link to Article — Permalink
The post Why Designers Don’t Want to Think When They Read appeared first on CSS-Tricks.
Part of the job of being a front-end developer is applying different techniques and technologies to pull off the desired lovely Dribbble shot for a Food Recipe Website from Riko Sapto Dimo.
It’s a very appealing design, and there is loads in there to think about from a front-end web design and development standpoint.
We’re going to mostly be talking about design pattern choices and HTML/CSS tech choices. There is much more to the job of front-end development. Accessibility! Performance! Semantics! Design systems! All important stuff as well.
Multi-line padded text
Ah yes, that look where text has a background that follows the length of the lines of text. We’ve called that Multi-Line Padded Text in the past and looked at a number of ways to do it. The easiest and most modern way to handle it is with box-decoration-break.
See the Pen Multiline Padding with box-decoration-break by Chris Coyier (@chriscoyier) on CodePen.
That header area is just begging for flexbox. It’s a single-direction layout with elements of different sizes and different space between them. Expressing that in flexbox is going to be easier than any other method and not require any fixed sizing or magic numbers — not to mention flexible!
The overall page layout here could be expressed nicely with CSS grid. Remember that flexbox and grid are not at odds. An element placed in a grid cell can be flexbox! Like the header above, that makes perfect sense. The main content area and footer, as grid cells, could probably go either way.
Not the most obvious thing to pull off! Your best bet is using writing modes. Jen Simmons has written about this, and here’s a demo:
See the Pen Writing Mode Demo — Headline by Jen Simmons (@jensimmons) on CodePen.
Looks like we have some truncation going on here. General performance-wise, we’d probably be wanting the data being sent only be a few lines long. But the front end can help with this too, if it has to. Three lines of text are shown here with ellipsis at the end. Perhaps the design really needs the copy to always be a maximum of three lines. That’s called line clamping.
See the Pen Line Clampin’ by Chris Coyier (@chriscoyier) on CodePen.
Like most sites these days, this design is coated in custom web fonts. With a design this striking, I’d be very careful about my font loading technique. My gut tells me I’d be more into FOIT than FOUT here, and ideally I’d cache that font file as hard as I could so that we’d have neither as often as possible.
Text over images
That text “Dinner Menu” is squarely over some busy photographic imagery below. It’s still readable though, largely because of the bright white of the text over a darkened image. We’ve covered thinking this through in the past in detail. White text over a darkened image is generally the way to go, and darkened enough such that just about any image will be OK. There are other options though, like gradients and blurring (which is also in use here in the footer)
See the Pen ByKwaq by Chris Coyier (@chriscoyier) on CodePen.
SVG icons / Star ratings
There are a number of simple, vector icons scattered around the design. Those are a sure-bet for an SVG icon system. This is my current recommendation for approaching an SVG icon system. Inline the SVG. Simple and powerful.
Those star ratings are probably SVG territory as well. Here’s a good collection of options. Progressively enhancing from radio buttons always seems like a smart way to go:
See the Pen CSS: Radio Input Stars by Jake Albaugh (@jakealbaugh) on CodePen.
It might seem a little superfluous on a large screen design like this, especially as there is navigation already visible. But hey, it’s hard to avoid these days and there is something to be said about training users where site navigation can happen regardless of where you’re looking at the site.
Here’s a collection of those type of menus.
See the Pen Hamburger menu flip with text change by Eric Grucza (@egrucza) on CodePen.
Anything else in the design I didn’t mention that your mind goes to right away?
The post Your Brain on Front-End Development appeared first on CSS-Tricks.
The team at Kapwing has collected a lot of images from the Internet Archive’s Wayback Machine and presented a history of how the homepage of popular websites like Google and the New York Times have changed over time. It’s super interesting.
I particularly love how Amazon has evolved from a super high information dense webpage that sort of looks like a blog to basically a giant carousel that takes over the whole screen.
Direct Link to Article — Permalink
The post Museum of Websites appeared first on CSS-Tricks.
There has long been an unfortunate disconnect between visual design for the web and web design and development. We’re over here designing pictures of websites, not websites – so the sentiment goes.
A.J. Kandy puts a point on all this. We’re seeing a proliferation of design tools these days, all with their own leaps forward. Yet…
But, critically, the majority of them aren’t web-centric. None really integrate with a modern web development workflow, not without converters or plugins anyway; and their output is not websites, but clickable simulations of websites.
Still, these prototypes are, inevitably, one-way artifacts that have to be first analyzed by developers, then recreated in code.
That’s just a part of what A.J. has to say, so I’d encourage you to read the whole thing.
Do y’all get Clearletter, the Clearleft newsletter? It’s a good one. They made some connections here to nearly a decade of similar thinking:
Jason Santa Maria: A Real Web Design Application
Jeffrey Zeldman: An Indesign for HTML and CSS?
Jon Gold: The Evolution of Tools
I suspect the reason that nobody has knocked a solution out of the park is that it’s a really hard problem to solve. There might not be a solution that is universally loved across lines. Like A.J., I hope it happens in the browser.
Direct Link to Article — Permalink
The post A DevTools for Designers appeared first on CSS-Tricks.
CSS grid, along with a handful of other new CSS properties, are revolutionizing web design. Unfortunately, the industry hasn’t embraced that revolution yet and a lot of it is centered around fear that we can trace back to problems with the current state of CSS grid tutorials.
The majority of them fall into one of two categories:
Re-creating classic web design patterns. Grid is great at replicating classic web design patterns like card grids and “holy grail” pages.
Playing around. Grid is also great for creating fun things like Monopoly boards or video game interfaces.
These types of tutorials are important for new technology. They’re a starting point. Now is the time, as Jen Simmons says, to get out of our ruts. To do that, we must cast off our design fears.
Fear 1: Asymmetry
We’ve been trained in the era of frameworks that symmetric and orderly designs are better. It’s true that for many applications a symmetric design or an orderly grid of items is preferred. Yet, asymmetry has the ability to capture the eye and mind in a way that symmetry never will. Asymmetry is interesting in its disorder. If you’re nervous, you can always start small.
See the Pen Asymmetric Promo Grid by Bryan Robinson (@brob) on CodePen.
In this example, we have a simple promotional space. By using an asymmetric vertical and horizontal layout, we can make a stronger visual match between our icon and our button. This isn’t a large space, but it’s not afraid of using whitespace to draw the user’s eye where we want it to go.
Speaking of whitespace…
Fear 2: Negative Space
As we left the early 2000s, we decided it was OK if users had to scroll. We began introducing whitespace into our designs and most of this fell between rows of content. This made our designs much cleaner, but is vertical whitespace the only valid option?
In this example, the design incorporates negative space to create a sense of exploration through the page. By not using traditional content rows, the user’s eye is given a chance to scan and take things in at a slower pace.
See the Pen Experimental Homepage by Bryan Robinson (@brob) on CodePen.
Fear 3: Punk Rock?
There’s no shortage of design talks focused on the print layouts of the 1970s. It was a time of great stability in design tooling, which allowed creativity to bloom. With that came inspired and avant-garde design work that centered around the punk-rock scene.
So my question is this: Can we be punk rockers in web design?
In this example, the design doesn’t care about your preconceptions. Text overlap is a bug? Nope, it’s a feature. Images shouldn’t compete with each other? Survival of the fittest!
See the Pen Grid Overlap and Punk Rock Meditation by Bryan Robinson (@brob) on CodePen.
As this example asks, is this a good idea? It’s completely up for debate. What I know is this: our tools have matured and become more stable; now is the time for experimentation. Do we want the web to look the same year after year, or do we want to dream up new and exciting patterns?
Fear 4: New Sources of Inspiration
Sources of inspiration shouldn’t cause fear, but they do often cause headaches. Remember, inspiration doesn’t mean a 1:1 translation of a concept.
Punk rock graphic design
I mentioned earlier the amazing designs that came out of the ’70s and ’80s. Here are some links to continue researching punk-rock design:
The Art of Punk Posters by Sean O’Hagan
The Art of Chaos: Punk Rock’s Timeless Influence on Graphic Design by Simon Martin
Vintage movie graphic design
Studying film in college gave me a great appreciation for vintage movie graphic design. One of my professors once told me: “You should be able to tell the tone and subject of a film by its title cards.”
This is especially true of post-World War II films. Their title sequences and posters are a treasure trove of design ideas for setting a scene.
The Graphic Art of Film Title Design Throughout Cinema History by Rebecca Gross
Saul Bass on His Approach to Designing Movie Title Sequences by The Academy of Motion Picture Arts & Sciences
Learn how to create graphic design grids
Graphic designers have been using grids for layout for centuries, and there’s a lot of great literature on the creation of these grids:
Video: Mark Boulton | Designing Grids | CSS Day 2017
Guity Novin’s A History of Graphic Design: Chapter 58, History of Layout Design and Modern Newspapers and Magazines
Layout Essentials: 100 Design Principles for Using Grids by Beth Tondreau
Fear 5: Fallbacks
It’s true that Grid has only 74% support in the U.S. (at the time of this writing).
That should not stop you from pushing your designs forward. There are plenty of strategies for starting with support for all browsers and then pushing forward into new patterns.
Using CSS Grid: Supporting Browsers Without Grid by Rachel Andrew
Video: Progressing Our Layouts by Jen Simmons
Falling Forward — Rethinking Progressive Enhancement, Graceful Degradation and Developer Morality by Bryan Robinson
It falls to each of us to push our industry forward. The technology is in place to challenge ourselves to create new and interesting designs. This doesn’t have to be as pointed and intense as some of these examples. It starts by realizing we can do amazing things … or we can stagnate.
How will you push the industry forward?
Five Design Fears to Vanquish With CSS Grid is a post from CSS-Tricks