Month: June 2019

The LUUM Temple Was Designed with Bamboo Arches by CO-LAB

The Meteorite Watch by David Rutten


The (Developer’s) Growth Model

I really like the post “The Designer’s Growth Model” by Dennis Hambeukers. Dennis just invented this model, but it’s based on some existing ideas and it all rings true for me. Let me try to summarize the five stages as he lays them out for designers.

  1. Producers: You learn how to design. You learn fundamentals, you practice, you get good at doing design work and producing beautiful functional things. Then you have this “crisis” moment before the next stage where you find you can’t do enough work on your own and that you need to be able to scale your efforts, with multiple human beings and working on systems — and that’s an entirely new skill.
  2. Architects: Now that you’ve succeeded in scaling through team building and systems thinking, the next crisis moment is that that this the work still might be isolated, and too focused on internal thinking. To grow, you’ll need to work with people outside the design bubble, and understand problems more holistically.
  3. Connectors: Now that you’ve succeeded in being more collaborative across an entire organization and being a real problem solver, the next crisis moment is when everything becomes organizationally complicated. Just delivering products isn’t enough, because you’re involved deeply across the organization and you’re responsible for the success of what is delivered.
  4. Scientists: Now, you measure everything. You know what works and what doesn’t because you test it and can prove it, along with using all the skills you’ve honed along the way. Your next crisis is figuring out how to translate your work into actual change.
  5. Visionaries: You’re a leader now. You have an understanding of how the whole organization ticks, and you are a force for change.
From The Designer’s Growth Model

I think this can applies just as well to web development, with very little change. I can relate in many ways. I started plucking away at building sites alone. I found more success and was able to build bigger things by working with other people. At some point, it was clear to me that things don’t revolve around development. Development is merely one part of a car that doesn’t drive at all without many other parts. Even today, it’s clearer to me that I can be more effective and drive more positive change the more I know about all of the parts.

Not that I’ve completed my journey. If I had to map myself directly onto this model, I’m probably barely on step three — But a model is just a model. It’s not meant to be a perfect roadmap for everybody. Your own career path will be twistier than this. You might even experience bits from all the levels in different doses along the way.

The post The (Developer’s) Growth Model appeared first on CSS-Tricks.


, ,


Matthias Ott, relaying an idea he heard from Derek Sivers:

Many personal websites, including this one here, have an “about” page. It’s a page that tells you something about the background of a person or about the services provided. But what this page often doesn’t answer – and neither do Twitter or Facebook pages – is what this person really is up to at the moment. A page that answers questions like: What are you focused on at this point in your life? What have you just started working on that excites you like nothing else? Did you just move to a new town? Did you start a new career as a Jengascript wrangler? To answer all those questions, Derek suggests to create a “now page”. A page that tells visitors of your site “what you’d tell a friend you hadn’t seen in a year.”

Very cool idea! Derek has a directory page of people who have done this.

I have more scattered thoughts:

  • It’s funny how social media sites aren’t very helpful with this. You’d think looking at someone’s social media profile would be the quickest and easiest way to catch up with what they are doing right now, but it just ain’t. That’s true for me, too. Random statements of what you’re working on don’t make very good social media posts. Maybe a pinned tweet could be like a “now” page, though.
  • I wonder if more homepages on people’s personal sites should be this. As I browse around some of the sites, I like a lot of the “now” pages more than I like the homepage.
  • I went with a “what I want you to do” section on my personal site. It’s a different vibe, but it almost doubles as a “now” page, as the things I want you to do are fairly related to the things I’m doing. Maybe the idea of a do page has some legs.

Direct Link to ArticlePermalink

The post Nownownow appeared first on CSS-Tricks.



Weekly Platform News: Event Timing, Google Earth for Web, undead session cookies

Šime posts regular content for web developers on

In this week’s news, Wikipedia helps identify three slow click handlers, Google Earth comes to the web, SVG properties in CSS get more support, and what to do in the event of zombie cookies.

Tracking down slow event handlers with Event Timing

Event Timing is experimentally available in Chrome (as an Origin Trial) and Wikipedia is taking part in the trial. This API can be used to accurately determine the duration of event handlers with the goal of surfacing slow events.

We quickly identified 3 very frequent slow click handlers experienced frequently by real users on Wikipedia. […] Two of those issues are caused by expensive JavaScript calls causing style recalculation and layout.

(via Gilles Dubuc)

Google Earth for Web beta available

The preview version of Google Earth for Web (powered by WebAssembly) is now available. You can try it out in Chromium-based browsers and Firefox — it runs single-threaded in browsers that don’t yet have (re-)enabled SharedArrayBuffer — but not in Safari because of its lack of full support for WebGL2.

(via Jordon Mears)

SVG geometry properties in CSS

Firefox Nightly has implemented SVG geometry properties (x, y, r, etc.) in CSS. This feature is already supported in Chrome and Safari and is expected to ship in Firefox 69 in September.

See the Pen
Animating SVG geometry properties with CSS
by Šime Vidas (@simevidas)
on CodePen.

(via Jérémie Patonnier)

Browsers can keep session cookies alive

Chrome and Firefox allow users to restore the previous browser session on startup. With this option enabled, closing the browser will not delete the user’s session cookies, nor empty the sessionStorage of web pages.

Given this session resumption behavior, it’s more important than ever to ensure that your site behaves reasonably upon receipt of an outdated session cookie (e.g. redirect the user to the login page instead of showing an error).

(via Eric Lawrence)

The post Weekly Platform News: Event Timing, Google Earth for Web, undead session cookies appeared first on CSS-Tricks.


, , , , , , , , ,

The Flying Drone Lamp by Kazuhiro Yamanaka


Which CSS IS AWESOME makes the most sense if you don’t know CSS well?

Peter-Paul posted this question:

Note the interesting caveat: only vote in the poll if you don’t know CSS well.

The winning answer was D! You gotta wonder if the result would have been different if the request for non-CSS experts wasn’t there.

I like to think I know CSS OK, so I didn’t vote. My brain goes like this:

  1. I think he’s asking “by default,” so the answer may assume there’s no other CSS doing anything to that text.
  2. I wish I knew why the box was that particular width, but I guess I’ll just assume it’s a set width.
  3. It’s not B because ellipsis stuff requires extra stuff, and doesn’t work on multiple lines like that — unless we’re talking line clamping, which is even weirder.
  4. It’s not C because that requires hiding overflow which is never really a default — that is, except off the top and left of the browser window, I guess. Or in an iframe.
  5. It’s not D because words just don’t break like that unless you do pretty specific stuff.
  6. A actually makes decent sense. It’s weird to look at, but I’ve been dealing with stuff busting out of containers my whole career. C’est la vie.

Remember, we’ve done a deep dive into CSS IS AWESOME before and how it interestingly captures the weirdness of CSS.

The post Which CSS IS AWESOME makes the most sense if you don’t know CSS well? appeared first on CSS-Tricks.


, , , , , ,

Using Percy to add visual testing to a Jekyll site

Visual testing is the automated process of reviewing software from a purely visual standpoint. Instead of testing the code underneath, visual testing is all about what end users actually see and interact with.

Similar to functional testing, however, visual testing fits directly into your stack and workflow. And with Percy, it’s easy to add snapshots to and run visual reviews for anything that runs in a browser.

Let’s set up an app to test

In this tutorial, we’re going to clone an example Jekyll site, add Percy snapshots, make some visual changes, and review them in Percy.

Before we add Percy, let’s set up our example app:

git clone

Navigate to your local app, install dependencies, then build and run the site:

cd example-percy-jekyll/ bundle install bundle exec jekyll build bundle exec jekyll serve

Note: Ruby >= 2.3 is required

Open and click around the site locally to see what we’ll be taking Percy snapshots of.

Shoutout to CloudCannon for the Hydra theme.

Next, if you haven’t already, sign up for a free Percy account and create an organization and a new project:

Percy projects correspond to the web application, component library, or static site you’re testing. In this case, we’ll be connecting our Percy project to our Jekyll site.

Generating Percy snapshots

To authenticate your local environment with your new Percy project, copy the PERCY_TOKEN environment variable from the new project screen or your project settings, then run:

$  export PERCY_TOKEN=aaabbbcccdddeee $  npx percy snapshot _site/

Note: Be sure to replace the token with your project-specific token.

You’ll see output like this:

$  npx percy snapshot _site/ Downloading Chromium r662092 - 88.3 Mb [====================] 100% 0.0s  [percy] created build #1: [percy] percy has started. [percy] serving static site at http://localhost:5339/ [percy] snapshot taken: '/404.html' [percy] snapshot taken: '/index.html' [percy] snapshot taken: '/about/index.html' [percy] snapshot taken: '/blog/index.html' [percy] snapshot taken: '/contact/index.html' [percy] snapshot taken: '/contact-success/index.html' [percy] snapshot taken: '/pricing/index.html' [percy] snapshot taken: '/category/marketing/index.html' [percy] snapshot taken: '/category/sales/index.html' [percy] snapshot taken: '/category/tips/index.html' [percy] snapshot taken: '/sales/2016/07/20/the-process-for-direct-sales/index.html' [percy] snapshot taken: '/marketing/2016/08/12/the-history-of-marketing/index.html' [percy] snapshot taken: '/sales/2016/08/06/definition-of-sales/index.html' [percy] snapshot taken: '/sales/tips/2016/07/28/effective-upselling-techniques/index.html' [percy] snapshot taken: '/sales/tips/2016/08/02/sales-effectiveness/index.html' [percy] shutting down static site at http://localhost:5339/ [percy] stopping percy... [percy] waiting for 15 snapshots to complete... [percy] done. [percy] finalized build #1:

Click the build link or head over to your Percy project to check out your first build.

What’s going on behind the scenes?

Once npx percy snapshot _site/ was called, Percy captured the DOM snapshots for each page of your Jekyll site. Percy then recreated the snapshots to compare against baseline snapshots and determine which pixels have changed.

Since this is the first build, there isn’t anything to compare it to. It has also been auto-approved because the commit was on master and we assume that master builds are production-ready.

Making and reviewing visual changes

Now that you’ve pushed your first build and established a baseline to compare your next snapshots to, let’s make a visual change to review.

Let’s make a wide sweeping CSS change. Head over to the cloudcannon.scss file and change the brand colors:

$ brand-color: #ff8a00; $ secondary-brand-color: #da1b60;

Since we’re pushing these changes directly to master, be sure to disable auto-approve on master branches from your Percy project settings.

Once those changes are saved, build your site and run Percy again:

$  bundle exec jekyll build $  npx percy snapshot _site/

Head back to Percy or click the Percy build link to see the visual changes!

If you haven’t been following along, you can check out the build.

What’s going on in the Percy UI?

The red areas in the right panel represent pixels that have changed—the visual diffs. Clicking that area (or pressing “d”) will toggle between the underlying snapshot and the overlaid diff so you can easily see what exactly has changed. You’ll also notice that the first several diffs have been matched and grouped to make it easier and faster to review.

Each snapshot has been rendered across both Chrome and Firefox, and at mobile and desktop widths. Rendering your site across these variations helps you detect subtle differences caused by browser rendering or responsive bugs.

Now that we’re happy with our fresh new look, hit “Approve All.” ✅

You’ve done your first visual review! Visual testing is great not only for catching visual bugs, but also for knowing the exact impact of any given code change. Seeing your UI visualized during code reviews is invaluable, helping you fix regressions before they make their way to production, or to deploy with complete confidence.

Configuring your snapshots

You can configure how and where Percy runs for each build by creating a global .percy.yml file in the root of your project.

You can customize the responsive widths at which your snapshots are rendered. For example, if you want to add a super wide snapshot in addition to our mobile and desktop widths:

version: 1 snapshot: 	widths: [375, 1280, 1920]

You can also ignore certain pages. For example, if you’d like to ignore multiple pages with the same layout like blog categories posts:

version: 1 static-snapshots: 	ignore-files: "/blog/category/*"

Learn more about Percy SDK configuration in our docs).

Adding Percy to your workflow

What we’ve done so far demonstrates how Percy generates snapshots and detects visual changes locally, but to get the most value out of automated visual testing, we recommend integrating Percy with your CI service.

For instructions and to see all of our supported CI services, check out our CI setup documentation. Here are a few of our most popular supported services:

Visual testing is best when done alongside code reviews. We support integrations with GitHub, GitLab, and Bitbucket (coming soon)! With an integration enabled, Percy will show up in your checks commit and pull request checks, notifying you if visual changes are detected:

Clicking “Details” will take you right to the Percy build where you can review visual changes.
After snapshots are approved, your commit status will change to green and the pull request can be merged.

With continuous visual reviews on every feature branch, it’s easy to have 100% confidence the visual changes you’ll be deploying.

We hope this tutorial has helped you get acquainted with Percy’s visual review platform and workflow. To learn more about how Percy works, feel free to check out these docs:

Happy testing! 💜

The post Using Percy to add visual testing to a Jekyll site appeared first on CSS-Tricks.


, , , , ,

Different Approaches for Creating a Staggered Animation

Animating elements, at its most basic, is fairly straightforward. Define the keyframes. Name the animation. Call it on an element.

But sometimes we need something a little more complex to get the right “feel” for the way things move. For example, a sound equalizer might use the same animation on each bar, but they are staggered to give the illusion of being animated independently.

See the Pen
Apple Music Sound Equilizer in SVG
by Geoff Graham (@geoffgraham)
on CodePen.

I was recently building a dashboard and wanted the items in one of the widgets to flow into view with a staggered animation.

Just like the sound equalizer above, I started going down the :nth-child route. I used the unordered list (<ul>) as the parent container, gave it a class and employed the :nth-child pseudo selector to offset each list item with animaton-delay.

.my-list li {   animation: my-animation 300ms ease-out; }  .my-list li:nth-child(1) {   animation-delay: 100ms; }  .my-list li:nth-child(2) {   animation-delay: 200ms; }  .my-list li:nth-child(3) {   animation-delay: 300ms; }  /* and so on */

This technique does indeed stagger items well, particularly if you know how many items are going to be in the list at any given time. Where things fall apart, however, is when the number of items is unpredictable, which was the case for the widget I was building for the dashboard. I really didn’t want to come back to this piece of code every time the number of items in the list changed, so I knocked out a quick Sass loop that accounts for up to 50 items and increments the animation delay with each item:

.my-list {   li {     animation: my-animation 300ms ease-out;            @for $  i from 1 through 50 {       &:nth-child(#{$  i}) {         animation-delay: 100ms * $  i;       }     }   } }

That should do it! Yet, it feels way too hacky. Sure, it doesn’t add that much weight to the file, but you know the compiled CSS will include a bunch of unused selectors, like nth-child(45).

There must be a better way. This is where I would normally reach for JavaScript to find all of the items and add a delay but… this time I spent a little time exploring to see if there is a way to do it with CSS alone.

How about CSS counters?

The first thing I thought of was using a CSS counter in combination with the calc() function:

.my-list {   counter-reset: my-counter; }  .my-list li {   counter-increment: my-counter;   animation-delay: calc(counter(my-counter) * 100ms); }

Unfortunately, that won’t work because the spec says counters cannot be used in calc()):

Components of a calc() expression can be literal values or attr() or calc() expressions.

Turns out a few people like this idea, but it hasn’t gone further than the draft stage.

How about a data attribute?

Having read that excerpt from the spec, I learned that calc() can use attr(). And, according to the CSS Values and Units specification):

In CSS3, the attr() expression can return many different types

This made me think; perhaps a data attribute could do the trick.

<ul class="my-list">   <li data-count="1"></li>   <li data-count="2"></li>   <li data-count="3"></li>   <li data-count="4"></li> </ul>
.my-list li {   animation-delay: calc(attr(data-count) * 150ms); }

But my hopes were dashed as the browser support for this is diabolical!

This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.


Chrome Opera Firefox IE Edge Safari
No No No No No No

Mobile / Tablet

iOS Safari Opera Mobile Opera Mini Android Android Chrome Android Firefox
No No No No No No

So, back to the drawing board.

How about custom properties?

The next idea I had was using CSS custom properties. It’s not pretty, but it worked 🙂

See the Pen
CSS variables animation order
by Dan Benmore (@dbenmore)
on CodePen.

Turns out it’s pretty flexible too. For example, the animation can be reversed:

See the Pen
CSS variables reverse animation order
by Dan Benmore (@dbenmore)
on CodePen.

It can also do something completely random and animate elements at the same time:

See the Pen
CSS variables random animation order
by Dan Benmore (@dbenmore)
on CodePen.

We can even push it a bit further and do a diagonal swoosh:

See the Pen
Set animation stagger with CSS properties / variables
by Dan Benmore (@dbenmore)
on CodePen.

The browser support isn’t all that bad (pokes stick at Internet Explorer).

This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.


Chrome Opera Firefox IE Edge Safari
49 36 31 No 16 9.1

Mobile / Tablet

iOS Safari Opera Mobile Opera Mini Android Android Chrome Android Firefox
9.3 46 No 67 75 67

One of the great features of CSS is that it will ignore things it doesn’t understand, thanks to the cascade. That means everything will animate in into view together. If that’s not your bag, you can add a feature query to override a default animation:

.my-list li {   animation: fallback-animation; }  @supports (--variables) {   .my-list li {     animation: fancy-animation;     animation-delay: calc(var(--animation-order) * 100ms);   } }

Vanilla CSS FTW

The more I stop and ask myself whether I need JavaScript, the more I’m amazed what CSS can do on its own. Sure, it would be nice if CSS counters could be used in a calc() function and it would be a pretty elegant solution. But for now, inline custom properties provide both a powerful and flexible way to solve this problem.

The post Different Approaches for Creating a Staggered Animation appeared first on CSS-Tricks.


, , , ,

Minimalist Packaging Design for Alex Carro