Archiwum kategorii: CSS

Small Tweaks That Can Make a Huge Impact on Your Website’s Accessibility

Post pobrano z: Small Tweaks That Can Make a Huge Impact on Your Website’s Accessibility

For a beginner, accessibility can be daunting. With all of the best intentions in the world, the learning curve to developing compliant, fully accessible websites and apps is huge. It’s also hard to find the right advice, because it’s an ever-changing and increasingly crowded landscape.

I’ve written this post to give you some tips on small things that can make a big difference, while hopefully not affecting your development process too much.

Let’s dive in!

Document Structure and Semantics

It probably doesn’t come as much of a surprise that structuring your HTML in an organized, semantic way will make a big difference. Screen readers rely on a well-structured document in order to follow a coherent narrative, so make sure that you’re using the elements that the HTML5 spec provides responsively and effectively.

If you’re unsure about how to markup your work correctly, check out resources such as HTML5 Doctor, Code Academy and of course, CSS-Tricks. You can also check out articles like “Writing HTML with accessibility in mind” and “Semantic Structure” to get you going in the right direction.

Let’s look at three specific things that can help ensure a well-structured and semantic document.

Use a Single <main> Element

A good example of building a responsible, semantic document structure is only using one <main> element. This should serve as a signpost for the most important content of the page for your user.

Add an ID to it and offer a skip link in your main <header> like so:

<header role="banner">
  <h1>Your main page title</h1>
    <a href="#main-content">Skip to the main content</a>
 </header>
    
<!-- Further down the document -->
<main id="main-content">
  <!-- Put your main body of content in here and other really important stuff -->
</main>

This little trick should help your screen reader users out in a big way, because they can go ahead and skip the fancy bits and dive right into your important content. It’s also great for keyboard users for the same reason.

Another nice touch is to add a :focus style to the skip link that makes it visible. Try pressing your tab key on GitHub.com. Pretty neat, right?

Use Elements Appropriately

So, <button> elements are a pain in the butt to style right? That doesn’t mean you should attach your JavaScript events to a <div> or an <a href="#"> though. You see, when you use a <button>, you get keyboard events for free. You’re also helping screen reader users out because it’ll announce the element correctly. Check out this example:

document.getElementsByTagName('button')[0].addEventListener('click', evt => {
  alert('Oh, hey there!');
});

If a user focused on that button and hit the enter key, that event would fire. That makes both yours and the users’ lives a bit easier. Well worth it, right?

See the Pen Button click example by Andy Bell (@hankchizljaw) on CodePen.

Get Your Heading Hierarchy Locked-Down

It’s really common for screen reader users to navigate a page by using the heading structure. That means we should help them out and create a nice hierarchy for them. Let’s take a look at a standard blog post:

<main id="main-content">
  <article>
      <!-- The page title is up in the main <header> in this instance -->
      <h2>My awesome blog post</h2>
      <p>Vestibulum id ligula porta felis euismod semper.</p>
      <p>Vestibulum id ligula porta felis euismod semper.</p>

      <h3>A sub-section of this post</h3>
      <p>Vestibulum id ligula porta felis euismod semper.</p>

      <h4>A sub-section of the sub-section</h4>
      <p>Vestibulum id ligula porta felis euismod semper.</p>
  </article>
</main>

With that sample, the user can navigate to the start of „My awesome blog post” and then have the ability to skip to sub-sections and nested sub-sections easily. They can also skip back up. It’s just a nice way of helping them consume the content you’ve produced as easily as possible.

It can be recommended that a page has a single <h1> element, even though the W3C HTML5 spec says you can have many. I personally agree with the use of a single <h1>, but you can have many, as long as you follow a nice structure and hierarchy. That’s the key here.

Get Your Color Contrast Right

To be WCAG 2.0 AA compliant, you need to have a contrast ratio of 4.5:1 for normal text. This is your paragraphs, buttons, navigation, etc. You need to go for a ratio of 3:1 for larger text, such as headings. I’d say this should be your minimum as it’s incredibly achievable with tools such as Tota11y, Contrast and the WebAim contrast checker. You can still get plenty of color balance and variation in your design too.

The reason that contrast is so important is because there’s so much variation in environment that you probably don’t even consider, such as bright sunlight and poor quality displays. Add this to a visual impairment or, say, a migraine and you’re potentially causing problems for your users.

Getting the contrast right will have a huge, positive effect across a wide spectrum of your users.

Responsible Text Labels

We’ve all built out a list of items with a non-descriptive, but visually appealing „More” button, right? More what though? We need to be more responsible with this and provide some context.

One way to achieve this is by visually hiding descriptive text with CSS and hiding the non-descriptive text from screen readers. It’s tempting to use display: none;, but screen readers can ignore elements with that set, so we need to be more creative. I use something like this little helper:

.visually-hidden { 
  display: block;
  height: 1px;
  width: 1px;
  overflow: hidden;
  clip: rect(1px 1px 1px 1px);
  clip: rect(1px, 1px, 1px, 1px);
  clip-path: inset(1px);
  visibility: hidden;
  white-space: nowrap;
  position: absolute;
}

With this CSS in place, we can do something like this:

<a href="/link-to-your-page">
  <!-- This is hidden from a screen reader, but visible visually -->
  <span aria-hidden="true">More</span>

  <!-- This is visible to a screen reader, but visually hidden -->
  <span class="visually-hidden">Continue reading: "Your post title here"</span>
</a>

A sighted user will only see “More” and a screen reader user will hear “Continue reading: 'Your post title here.'” Both sets of users are happy.

You can also achieve the above by using an aria-label on the <a> tag. This will override the text within for a screen-reader:

<a href="/link-to-your-page" aria-label="Continue reading: 'Your post title here'">
  More
</a>

Small Typography Tweaks With a Big Impact

It’s always worth remembering that people with a visual impairment or learning difficulty could be trying to read your content, so some small tweaks to your typography can go a long way.

A body of content such as an article should be sized at 16px (or equivalent unit) at a minimum. It’s also worth increasing your line-height to around 1.5 too. Space between lines can help readers with dyslexia to understand your content better. The combination of size and space is also great for older people and/or short-of-sight people. Even small summaries and aside content should be at least 12px (or equivalent unit). Anything smaller than that will alienate users who struggle to read.

Another trick is to highlight key words and phrases if your content is quite complex. This not only benefits users who are slightly slower at processing content but it also helps people who like to scan over an article, like I do.

Lastly on this section, I’d advise you to be careful with your font choices. Fonts with complex ligatures and decorative elements can be really distracting, so maybe limit the usage of those to key, large headings only. It’s also been advised that sans-serif fonts are better for readers with dyslexia. Check out this article for more on that and other text formatting tips.

Enhance Keyboard Support

There are a few little tweaks you can do to help users who primarily use their keyboard to navigate your website.

Say you’ve got a little button that shows a dialogue when you click it. You should attach an event to the escape key that hides it. Here’s a sample snippet:

document.addEventListener('keyup', (evt) => {
  if(evt.keyCode === 27) {
    // Run whatever code hides your dialogue
  }
});

See the Pen Escape key demo by Andy Bell (@hankchizljaw) on CodePen.

Another tweak you can do for our keyboard-navigating buddies is not hiding focus from them. Browsers give us focus states for free with outline. I know it can look ugly, but hot-damn it’s useful for keyboard users. If you want to get rid of that blue glow, I get it—just please use the :focus pseudo selector to add an obvious state change to it instead. Here’s a sample:

.your-element {
  background: red;
}

.your-element:focus {
  outline: none; /* Reset the default */
  box-shadow: 0 0 0 3px black; /* A very obvious state change */
}

Don’t Rely on Color Alone to Communicate State Changes

Let’s end on a really important one. Color shouldn’t be relied upon alone to communicate state changes. Take this scenario as an example:

You’ve got a button that posts a form. You wrote some neat JavaScript that makes it go grey while it sends the data. It then either turns green or red, depending on what the status is.

For a colorblind user, this is a nightmare. To them, the button may have barely changed enough for them to notice, so they may just keep clicking and clicking while getting really frustrated. This isn’t ideal.

So, instead of relying on color, let’s enhance that with a status message that supports the button’s state on response.

See the Pen Enhanced state change communication demo by Andy Bell (@hankchizljaw) on CodePen.

That sample is a great way to quickly communicate to the user that something has changed and the use of color, text and iconography clearly communicates that change. Disabling the button whilst the response is processed is also a great help to the user.

Wrapping Up

These little tips should make a big difference to your users, and I hope you dive into your projects and implement some of them.

You should also keep learning about accessibility. I recommend following people such as Heydon Pickering, Scott O’Hara, Laura Kalbag, and Rob Dobson on Twitter. I also recommend that you check out resources such as Inclusive Components and the A11y Project.

The greater your knowledge gets, the better your websites and products will be for a much wider audience. That can only be a good thing, right?


Small Tweaks That Can Make a Huge Impact on Your Website’s Accessibility is a post from CSS-Tricks

​Incapsula’s Global DDoS Threat Landscape Report

Post pobrano z: ​Incapsula’s Global DDoS Threat Landscape Report

(This is a sponsored post.)

The newly released Q3 2017 Global DDoS Threat Landscape Report features insights on attacks and mitigation. These are some of the key findings:

  • Bitcoin was one of the most targeted industries
  • High packet rate attacks grew more common
  • A third of network layer attacks were highly persistent
  • Botnet activity out of India and Turkey continued to climb

Learn about the top attacked countries, industries, and vectors here and how to protect your site with Incapsula.

Direct Link to ArticlePermalink


​Incapsula’s Global DDoS Threat Landscape Report is a post from CSS-Tricks

WordPress User Survey Data for 2015-2017

Post pobrano z: WordPress User Survey Data for 2015-2017

A grand total of 77,609 responses from WordPress users and professionals collected by Automattic between 2015 and 2017. The stats for 2015 and 2016 have been shared at the annual State of the Word address and 2017 marks the first time they have been published on WordPress News.

A few items that caught my attention at first glance:

  • Between 66% and 75% of WordPress users installed WordPress on their own. In other words, they were savvy enough to do it without the help of a developer. Hosting providers were next up and clocked in at 13-14% of installs.
  • WordPress professionals described their clients as large and enterprise companies only 6-7% of the time. I guess this makes sense if those companies are relying on in-house resourcing, but I still would have pegged this higher.
  • What do users love most about WordPress? It’s simple and user-friendly (49-52%). What frustrates them most about it? Plugins and themes (19-28%). Seems like those two would go hand-in-hand to some degree.

I’m not a statistician and have no idea how much the results of these surveys accurately reflect the 26% of all sites on the internet that are powered by WordPress, but it sure is interesting.

Direct Link to ArticlePermalink


WordPress User Survey Data for 2015-2017 is a post from CSS-Tricks

Careful Now

Post pobrano z: Careful Now

Tom Warren’s „Chrome is turning into the new Internet Explorer 6” for The Verge has a title that, to us front-end web developers, suggests that Chrome is turning into a browser far behind in technology and replete with tricky bugs. Aside from the occasional offhand generic, „Chrome is getting so bad lately,” comments you hear, we know that’s not true. Chrome often leads the pack for good web tech.

Instead, it’s about another equally concerning danger: developers building sites specifically for Chrome. In theory, that’s not really a thing, because if you build a website with web standards (of which there isn’t really much of an alternative) it’ll work in Chrome like any other modern web browser. But it is a thing if you build the site to somehow block other browsers and only allow Chrome. Warren:

Google has been at the center of a lot of “works best with Chrome” messages we’re starting to see appear on the web. Google Meet, Allo, YouTube TV, Google Earth, and YouTube Studio Beta all block Windows 10’s default browser, Microsoft Edge, from accessing them and they all point users to download Chrome instead. Google Meet, Google Earth, and YouTube TV are also not supported on Firefox with messages to download Chrome.

I wouldn’t call it an epidemic but it’s not a good trend. Best I can tell, it’s server-side UA sniffing that entirely blocks the sites:

Sheesh.

If anything, I’d think you’d just let people use the site and display a warning if you’re really worried some particular feature might not work. Or even better, fix it. I have no behind-the-scenes knowledge of why they made the choice to block certain browsers, but it’s hard to imagine a technical limitation that would force it. And if it is, I’d suggest letting it be very publicly known to incentivize the other browsers to support what is needed, assuming it’s an established standard.

Even more concerning than browser-specific websites is seeing browsers ship non-standardized features just because they want them, not behind any vendor prefix or flag. There was a time when web developers would have got out the pitchforks if a browser was doing this, but I sense some complacency seeping in.

These days, the vibe is more centered around complaining about other browsers lack of support for things. For example, one browser ships something, we see one green dot in caniuse, and we lambast the other browsers to catch up. Instead, we might ask, was it a good idea to ship that feature yet?

No modern browser is shipping vendor prefixes anymore since we all ultimately decided that was a bad idea. A side effect of that is that shipping a new feature in CSS or JavaScript is all the riskier. I would think shipping an unprefixed feature to a stable version of the browser would mean the feature is standardized and not going to significantly change. Yet, it’s been happening.

In CSS, Chrome shipped motion-* properties, but then that all changed to offset-*, and the old motion-* properties just stopped working. That’s more than just annoying, that kind of thing helps developers justify saying, „I just build this site for Chrome, if you wanna use it, use Chrome.” Fine for a demo, perhaps, but bad for the web industry as a whole. Again, I have no special insight into why this happens, I’m just a developer looking in from the outside.

Here’s another CSS one I just saw the other day. People are excited about text-decoration-skip: ink; because it looks great and helps people. They are using it a lot. But apparently, that’s not the correct name for it? It’s been changed to text-decoration-skip-ink: auto; and so Chrome 64 is canning text-decoration-skip: ink;. This stuff is hard to keep up with even while actively trying.

Chris Krycho had a take on it recently as well:

Over the past few years, I’ve increasingly seen articles with headlines that run something like, “New Feature Coming To the Web” — followed by content which described how Chrome had implemented an experimental new feature. “You’ll be able to use this soon!” has been the promise.

The reality is a bit more complicated. Sometimes, ideas the Chrome team pioneers make their way out to the rest of the browsers and become tools we can all use. Sometimes… they get shelved because none of the other browsers decide to implement them.

Many times, when this latter tack happens, developers grouse about the other browser makers who are “holding the web back.” But there is a fundamental problem in this way of looking at things: Chrome isn’t the standard. The fact that Chrome proposes something, and even the fact that a bunch of developers like it, does not a standard make. Nor does it impose an obligation to other browsers to prioritize it, or even to ship it.

This isn’t all to throw Chrome under the bus. I’m a Chrome fan. I’m sure there are examples from all the major vendors in the same vein. I’d just like my two cents to be careful now. The web is the best platform to build for and generally heading in a direction that makes that even truer. The easiest way to screw that up is not being careful with standards.


Careful Now is a post from CSS-Tricks

Tales of a Non-Unicorn: A Story About the Roller Coaster of Job Searching

Post pobrano z: Tales of a Non-Unicorn: A Story About the Roller Coaster of Job Searching

Hey there! It’s Lara, author of the infamous„Tales of a Non-Unicorn: A Story About the Trouble with Job Titles and Descriptions” from a couple years back. If you haven’t read that original article, I recommend skimming it to give you some context for this one, but I think you’ll still find value here even if you don’t.

A lot has happened since I wrote that article in 2015, and this follow-up has been in the works for a good six months. I ended up, not with a solution for the job titles conundrum or a manifesto about the importance of HTML and CSS, rather a simple, honest story about my roller coaster ride.

Okay, enough dilly-dally. Let’s go!

<story>

In the aftermath of the FizzBuzz drama in 2015, I doubled down on my freelance business and did really well. I got a great contract gig with startup in New York refactoring a Haml/Bootstrap situation that paid the bills and then some. I hired an assistant and started the Tackle Box, an online school sort-of-thing where I taught web development and WordPress. I made a little money off that one, too. I spoke at a handful of conferences and meetups, taught a bunch of classes, and generally had the pedal to the metal.

Then I got really, really tired.

I was sick of writing emails, sick of sending invoices, and sick of being on the computer all the damn time. I wanted to go to work and then leave work at work; something that is very hard to do in our industry, and extra difficult when you are your own boss. I enjoyed coding sometimes, but it was all about the billable hour. Why should I write code or be on the computer at all if I’m not being paid for it? This was burnout, that thing that’s become a weird, convoluted rite of passage in our industry.

I wanted to shut down Lara Schenck, LLC and be a ski bum. And you know what? I did. It was time for a break, and I took one for about six months.

Ski Bum Sabbatical

I left New York City in August of 2016 and moved back to my family’s farm near Pittsburgh. I got a job cleaning horse stalls for $7/hr at the stable where I used to ride when I was a kid. My plan was to gradually ramp down business while I lived rent-free and prepared myself for the simple life. That December, I would be starting work as a bartender at Goldminer’s Daughter Lodge in Alta, Utah, a tiny ski town outside of Salt Lake City. Room and board were included in the job; I’d make enough pocket money for booze, and my life would consist of skiing, sleeping, and socializing. No emails.

Image of a sign for the Town of Alta, population 370, elevation 8,460
Just down the winding road from Alta Ski Area.

The simple life was okay for a little bit, but bartending at a 3:2 beer bar and skiing every day wasn’t as fulfilling as I’d hoped. I cut the season short and moved to Los Angeles in March with my partner at the time. We had a mutual friend with an open room in Hollywood, and I was starved for city-living. (I have since learned that LA is not the city-living I expected, at all, but that’s another conversation.)

Time to Get a Job (for real this time)

I formally announced I was back on the scene, reached out to old clients and people from my New York network, and was even on a podcast out of the gate. None of that translated into much paying work. Luckily, I had a cushion of savings to float me for a few months (Freelancing Rule #1: You must have savings), but my heart just wasn’t in the freelance hustle this time. The prospect of negotiating contracts and engaging new leads was nauseating rather than exciting, and the small business website work I did was no longer the challenging and invigorating experience it had been before.

I decided to get a full-time job, for real this time. Once again, I wanted to work on a team and on bigger projects. I was tired of doing everything myself, and I wanted to learn from and share my experience with others. And, you know, a regular paycheck.

I set to work applying for jobs, putting long hours into carefully crafted cover letters. I had several promising interviews, got my hopes way up a couple of times, and received zero job offers. For one particular role, I’d gotten as far as discussing salary requirements and start dates, and was expecting an offer letter within the week. Then, the next week they were all of a sudden no longer hiring. I didn’t run into any FizzBuzz, for better or for worse.

I started to question why my designer/developer skillset appeared to hold so little value now when I’d felt so in demand just a year ago. I stubbornly refused to learn React just so I could have it on my resume—I’m great at other important things, why can’t people see that?! I wondered whether the five years of self-employment was a hindrance, or was there something fundamentally wrong with how I interviewed? Did I shoot myself in the foot with this whole „non-unicorn” thing in the first place?

These months were a major ego-check. It turns out, full-time jobs aren’t something you can just „get.” It’s just not that easy, for me at least.

The Value of HTML and CSS

Responding to job posts with those carefully crafted cover letters had a very low return on investment so I decided to change my approach. Instead of putting my time into writing said cover letters, I would focus on writing about real things and becoming a better developer, and the jobs would come to me. I launched a well-thought-out redesign of my website, published a Reverse Job Post, and buckled down on my JavaScript studies.

This was right around the time Mandy Michael wrote „Is there any value in people who cannot write JavaScript?” which hit the nail on the head. I wrote a question into ShopTalk show about this phenomenon and mentioned to Chris that I’d love to come on the show and talk about it if they’d like. The next day, Chris invited both Mandy and me to come on the show and hash it out:

HTML and CSS are valuable, but intimate knowledge of them has become more of a specialist role. Perhaps, one can position their skills as HTML, CSS, plus something else (e.g. UI design or WordPress). The nature of products and rapid feature releases deem quality HTML and CSS an afterthought at many companies so at the moment, maybe the demand just isn’t there. Perhaps the rise in accessibility awareness, design systems, and time lost debugging bad CSS will change the tide?

The episode was well received; I was obviously not the only one struggling with this issue. I made a Github repository called Front-end Discourse with the intention of gathering and synthesizing opinions and coming up with a plan of action on the job titles front. Chris even wrote about the job titles conundrum here on CSS-Tricks. The momentum was there; this could be my thing!

But then…I let it die.

An Unexpected Twist

A few days after the ShopTalk episode came out, I received this tweet:

Image of tweet asking Lara if she is still looking for a job, with a link to job post at careers.google.com/jobs

Umm…that’s a link to a Google job post.

I thought it was a joke at first, but nope, the tweet author sent me an email later that day, and it was the real deal! They’d been referred to me by a benevolent figure in the web industry whom I’d never met. I had a call with them and another member of their team, and it was magical. They told me all about a new team starting within Developer Relations at Google that would be working to improve the „Web Content Ecosystem.” Web Content Ecosystem? That’s WordPress! And they were recruiting me! Holy sh#t, this actually happens!

This was my dream job, not a front-end designer/developer role. I didn’t even know this was a job! I had already been doing this work on my own time for several years: teaching and speaking about WordPress, writing informational blog posts, recording videos, and helping people use WordPress more responsibly. And they would move me to San Francisco! I was not a huge fan of Los Angeles.

Unfortunately, Google doesn’t just „give” people jobs…you have to interview.

Computer Science Bootcamp

Now we have me, the designer who applied for a JS job and failed FizzBuzz, preparing for the Google interview otherwise known as the grandparent of all technical white-boarding interviews. It was time to swallow any feelings I had toward this interviewing style and get to work.

I had three weeks until a „coaching call” that would unofficially determine whether or not I could skip the technical phone screening and jump straight to the day of on-site interviews because, duh, this was meant to be. Luckily, this coincided with a lull in freelance work, which had also been picking up, so for about a week and a half, I put myself through a self-directed computer science bootcamp. On the way, I wrote a bunch of blog posts about what I learned.

Oh, how I longed to write that Tales of a Non-Unicorn: I GOT A JOB AT GOOGLE, F@#KERS!!! follow-up for all those Reddit haters after it was said and done!

The day of the coaching call arrived, and it was fantastic! I was a little slow on the coding question, but it wasn’t as hard as I’d thought, I aced the role-related questions, and the interviewer was excellent. I heard back from the recruiter who was coordinating with me, and he said I could go straight to the on-site interviews.

In the meantime, I went to WordCamp US in Nashville where this particular team at Google was a sponsor. I got to meet a few of the folks I’d be working with, and it seemed like such a great fit. This Google interest and being at WordCamp made me question why, at the beginning of my job search, I had seen my knowledge of WordPress as such a secondary skillset. WordPress is everywhere! And its awesome! I mean, sure, it’s not that „cool” yet, but mark my words, it will be in the „cool” ranks soon enough.

The Non-Unicorn Interviews at Google

In the week leading up to the interview, I focused on researching the role and beefing up my passion for improving WordPress and helping those who work with it. This was not a software engineering role, after all; in Developer Relations, passion for and knowledge of your subject is more important than knowing binary tree traversal, right?

Google flew me to San Francisco and put me up in a nice hotel. I had a full day of four interviews—usually, it’s five, one was canceled—and a long, enjoyable lunch with the folks I’d been in touch with from the get-go. I didn’t feel great about my performance in the technical parts of the interviews, but I did my best and my strategy was to come off as a great coworker who knows when to ask for help. When in doubt, I remembered the strong correlation between „hard interview” and „received offer” on Google’s Glassdoor profile.

Back in LA, freelance work kept me busy while I waited for a verdict, which wasn’t long. I felt relatively zen about the whole thing. Yes, I had my hopes up, but if it didn’t work out, I at least had work to pay the bills, and it wasn’t going half-bad. I’d been contracting with an agency and learning a lot; it wasn’t the small business WordPress sites I’d been building all by myself previously.

The Thursday after my Monday interview, I got a call from my recruiter contact. They were not going to proceed with the approval process at this time. He said I showed some very promising „Google-y” qualities, but my performance in the coding portion of the interviews wasn’t strong enough. He said he had it in his calendar to reconnect with me in six months, and that he would keep an eye out for less technical roles that might be a better fit.

…oof.

Incredibly, I was able to fend off the majority of the anger and the „I’m a failure and I suck at everything” thoughts that go hand-in-hand with rejection, maybe in part because I received such a nice email from one of the people I’d been in touch with throughout the process. He had applied three times before he got a job there—which apparently is not uncommon—and this simply meant I’d be taking a slightly different path. They were all bummed I didn’t make it.

This brings us back to the present. I don’t feel sour about algorithms or white-boarding interviews…I have another one to get ready for in six months! Unless, of course, another really awesome opportunity comes my way in the meantime. Who knows.

This whole job search has been such a ridiculous roller coaster of hopes slowly going up then crashing down. If there’s one thing I’ve learned, it’s that I still don’t know where I’ll end up, but I’m doing my best and I’ll keep doing it until the right thing comes along.

Silhouette of a car on a roller coaster about to go down a large hill

</story>

Whew, that was a lot! Thanks for making it this far. A+ for you, reader!

Post-Mortem

Before I wrap this thing up, I want to make a few observations about this whole job searching process that I hope can help others on their roller coaster ride.

  1. Algorithms and white-boarding interviews aren’t necessarily bad. I think they can be implemented badly. The Big Tech Companies are fully aware that they miss out on great candidates because of algorithm questions, but this interviewing strategy is so good at filtering out bad candidates that they keep it around. It sucks for us, but I don’t see that changing anytime soon. Plus, I learned a hell of a lot of stuff preparing for it, and it’s made me a better developer and better human being.
  2. Write a „Reverse Job Post.” I don’t recall where I learned about it, but here’s mine for reference. Even if no one reads it, it’s a great way to figure out what type of job and company you are looking for, and you could totally paste a link to it in the cover letter field for an application and call it a day.
  3. Learn computer science fundamentals. I know we are already inundated with things to learn, so it’s hard to preach this, but having context for what the tools we use actually are has helped me a lot. For example, two months ago I would have had a hard time wrapping my mind around GraphQL, but in my interview preparation I learned about graphs and tree data structures, so I was able to understand the concept relatively easily. Cracking the Coding Interview is not a good place to start, BaseCS and the Impostor’s Handbook are. Also, stay tuned for some relevant articles here on CSS-Tricks, from yours truly!
  4. Don’t spend all of your time on job boards. It’s a crapshoot. I think there are great job boards, but in general, no matter how quality the listing, whether or not the position is actually available or accurately represented in the post is a toss-up.
  5. Be vocal. I doubt any of this Google stuff would have happened if I hadn’t written into ShopTalk show and asked Chris to have me on the episode. If you have an impulse to write something or have a question or feel the urge to tweet at someone you don’t know, do it (but be a good person about it, obviously). The more web people that know you exist, the more likely it is that something will come your way.

Those are some things that helped me, but I still don’t have a job, so maybe don’t listen to what I say. I don’t know. It’s an incredibly difficult and demeaning process, and there’s no secret sauce that works for everyone. Our industry is a young one, and as far as I’m aware, there is no such thing as a surefire career path in web development.

I hope I don’t write another „Tales of a Non-Unicorn” installment. The whole idea of a „unicorn” is bogus, anyway. We are all just people, with different levels of knowledge in different areas, and if you can honestly say you’re doing your best then I think that’s all you can do.

What I will be writing, however, are some „Computer Science Study Guides” for the self-taught developer, here on CSS-Tricks, and maybe some stuff about how cool WordPress is nowadays. At the very least, „Intro To Algorithms” will be coming at you, soon!

How about you, reader?

Have you been on this roller coaster ride, too? Where did you end up? What advice can you offer to those of us who are still in the midst of our journey?


Tales of a Non-Unicorn: A Story About the Roller Coaster of Job Searching is a post from CSS-Tricks

Making CSS Animations Feel More Natural

Post pobrano z: Making CSS Animations Feel More Natural

It used to be that designers designed and coders coded. There was no crossover, and that’s the way it was. But with the advent of CSS transitions and animations, those lines are blurring a bit. It’s no longer as simple as the designer dictating the design and the coder transcribing—designers must now know something about code, and coders must know something about design in order to effectively collaborate.

As an example, let’s say a designer asks a developer to make a box bounce. That’s it—no additional instruction. Without some cross-knowledge and a common vocabulary, both sides are a little lost in this communication: the developer doesn’t have enough information to fully realize the designer’s vision, but the designer doesn’t really know what the options are and how to communicate them. With a very basic interpretation, you might end up with something that looks like this:

See the Pen Bouncing Box 1 by Brandon Gregory (@pulpexploder) on CodePen.

Not very exciting. Although, to be fair, this does meet all of the criteria given. We can definitely do better than this, though.

The first thing to look at is the timing function. In the above example, we’re using a linear timing function, which means that the box is constantly moving at the same speed. In some cases, this is desirable; however, in the real world, motion usually doesn’t work like that.

An easy fix is to simply change the timing function to ease. This makes the beginning and ending of each animation a little slower than the middle part, which adds a more natural look to some animations. Here’s the box with the easing function turned on:

See the Pen Bouncing Box 2 by Brandon Gregory (@pulpexploder) on CodePen.

This is a slight improvement, but there’s still a lot of work to be done. The box still looks mechanical and stiff, with the same animation occurring in the same timeframe over and over. Adding a slight delay between bounces adds some visual contrast that seems a little more natural:

See the Pen Bouncing Box 3 by Brandon Gregory (@pulpexploder) on CodePen.

The box now looks like it’s jumping rather than simply moving up and down. There’s a little wind-up and cool-down between jumps that mimics what a live creature might do if given the same instruction. Even though we have no reference for what a jumping box would look like, we all have a pretty good idea of what a jumping creature would look like. Because we know what would happen in nature, by mimicking that, the animation feels more natural. But we can do more to make that wind-up feel a little more weighty.

If you watch cartoons, you’ll notice that natural movements are often exaggerated, creating a caricature of real life. When done well, this can feel just as natural as something in the real world, with the added bonus of infusing a little charm and character into the animation.

At this stage, collaboration between the designer and developer is crucial — but many designers may not even be aware that these options exist. It may be up to the developer to pitch this possibility to the designer.

By adding some subtle distortion to the scale of the box, we can add a lot to the animation:

See the Pen Bouncing Box 4 by Brandon Gregory (@pulpexploder) on CodePen.

Now, the box has character. It feels alive. There are many things to tweak, but this is already moving much farther than the original instruction — in a very good way!

We’re going to go a step further and add a little rebound at the end of the jump:

See the Pen Bouncing Box 5 by Brandon Gregory (@pulpexploder) on CodePen.

The second bounce is making this feel more alive, but something still seems off. The bounce looks stiff compared to the rest of the animation. We need to add another bit of distortion like we did for the wind-up:

See the Pen Bouncing Box 6 by Brandon Gregory (@pulpexploder) on CodePen.

That subtle distortion at the end makes the rebound seem much more natural. Overall, a huge improvement from our basic linear bounce in the first example.

That right there may be exactly what we’re looking for, but further tweaks to the rate of movement can be made with a custom cubic Bézier curve:

See the Pen Bouncing Box 7 by Brandon Gregory (@pulpexploder) on CodePen.

Without both the designer and the developer aware of basic animation principles and controls, this level of customization is impossible. Really, this article just scratches the surface of both fields. If you’re a web designer or a web developer who works with designers, I’d strongly urge you to read up on both.

For animation principles, The Illusion of Life: Disney Animation by Ollie Johnston and Frank Thomas is a great primer on how to make that caricature of real life seem alive and real. With that common language in place, communication and collaboration between designers and developers becomes much easier.

For the technical controls and variations of CSS animation, the possibilities are nearly endless. Delay and timing are simple to adjust. As mentioned, if you don’t like the out-of-the-box ease timing function, it’s very possible to create your own using a cubic-bezier(). You can also adjust the level of distortion you want to bring the animation closer to or further from reality. The important thing is that both the designer and developer are thinking about these variations rather than blindly taking everything without customization. Shared knowledge and collaboration can make even simple animations into great ones.

More Resources


Making CSS Animations Feel More Natural is a post from CSS-Tricks

Thank You (2017 Edition)

Post pobrano z: Thank You (2017 Edition)

As 2017 comes to a close, as we do each year, let’s take a numbers-based glance back at CSS-Tricks. And more importantly, tip our collective hat to all y’all that come here and read the site.

We really do think of the site as somewhere you come and read. While a lot of people’s experience with CSS-Tricks is a place that shows up in search results to find the answer to some web design/dev question (and that’s awesome), another way to experience the site is to read it like a magazine. We publish an article (or a couple) nearly every day, from a variety of authors, with the hope that it’s interesting and exposes us all to new ideas.

According to Google Analytics, which we’ve had installed and reported from anonymously since day 1 around here, we had 75 million pageviews this year. Very little of CSS-Tricks makes use of any kind of „single page app” type tech, so that’s pretty accurate to people visiting and clicking around. It’s down from 77 million last year. I’d like to think that’s because of ad blockers, which often block Google Analytics, are up in usage for the visitors of CSS-Tricks, but it’s just as likely we’re just down a smidge this year. Sessions are also down a smidge at 54 million but Users steady at 21 million.


We were on a publishing role though! We published 595 posts, blowing away last year with only 442, the previous record. We also published 50 pages (i.e. snippets/videos/almanac entries) beating 43 last year. Certainly, we’re in favor of quality over quantity, but I think this is a healthy publishing pace when our goal is to be read, in a sense, like a magazine. That has been more clear to me this year. We produce content with complementary goals and one of those goals is that of a magazine. We hope the site is worth reading day after day and week after week. The other is that the content lasts and is referenceable for many years to come. Hopefully thinking of things that way can be a guiding light, balancing news and reference content, while avoiding stuff that is neither.

I always wished there was an easy way to figure out what the most popular articles published that year were, but I still don’t have a great way to do that. The top 10 is dominated by our big guides, things like our Guides to Grid, Flexbox, SVG, and centering.

Those top 10 make up about 15% of total traffic, which is a massive slice, but that leaves 85% of traffic as part of the „long tail”. That’s a satisfying thought when you’re in it for the long haul as we are. Not every article is a huge top 10 smash hit, but does contribute to the long tail which is a much bigger slice collectively anyway.


For the last bunch of months, we’ve been using Algolia for search. My plan only has 7 days of analytics retention, which isn’t enough data to expose major trends. In looking at a week of data though, you can see some surprising top terms like React, SVG, grid, flexbox, font, border… Another thing that’s clear is that on-site search is quite important. Algolia reports ~15,000 queries a day. I don’t think that represents „user typed in a thing and submitted it” because the search happens in real-time, so each character typed can result in a query. Still, likely hundreds or low-thousands of searches a day.

I’m going to convert us back to using Google search. I think Algolia is a fantastic product, I just don’t have the developer time right now to give it the work it needs.


The location of y’all seems to be spreading out internationally little by little. The United States is down to 22% of traffic from 23% and India back to down to 11% from 12% (meaning more traffic came from elsewhere). Those are the top 2, then it goes UK, Germany, Canada, France, Netherlands, Poland, Russia, Brazil. What would be really interesting is to figure out visitors per-capita. For example, Singapore has a population of 5.6 million and had 111,319 unique users, so you could say about 2% of Singaporeans visited CSS-Tricks last year. Lols probably not, but hey that’s what the back-of-the-napkin math shows. Whereas with the 4.6 million unique visitors from the US compared to the 323 million population means only 1.5% has visited.


We gained about 10,000 newsletter subscribers this year for a total of 31,376. That’s about a third of the entire list size. I love our newsletter. I think it has a ton of potential and is always worth reading. To be perfectly honest I’d like to see our newsletter subscriber numbers be higher than our Twitter followers, but that’ll be a tall hill to climb.


Search is the origin of 86.6% of the traffic we get. Direct visits and referral links result in another 5% each. Social media just 2.5%. Whenever I look at that I’m reminded of the disproportionate amount of energy spent on it. Still, it aligns with our goal of being a publication people regularly read and being a source of news, so it feels worth it.


Speaking of social media, we rose 44,000 follows on Twitter last year, again an astonishing number, but it’s down year-over-year for the last several years. 71,900 likes on Facebook, only rising about 3,000, which isn’t bad considering we do hardly anything at all on Facebook. Growth is much more explosive on YouTube. We’re at 40,123 subscribers there from 32,174 last year, despite only posting a paultry 6 videos.

This is a classic loop in my head: maybe we should have a dedicated social media person! But even part-time employees are expensive… is it worth it? How much more potential is there? Could they add so much value they pay for themselves? What else could they do? And then the questions swirl around in my head so quickly the idea fizzles out. I guess I’ll just say if that kind of thing interests you, reach out!


For once, mobile traffic is actually up. 6.2% this year from below 5% last year. Industry-wide, that’s rock bottom. CSS-Tricks is just weird that way. A lot of developers b searching stuff at work, unsurprisingly. Less than 1% is tablets. 30% of the mobile traffic is iPhones.


Y’all left about 5,040 comments on the site this year, which is a smidge down year over year from the past few years, but it actually feels significantly up to me, since we’ve been much more stringent about what comments we publish this year. I do the vast majority of comment moderation and I trash a lot more than I used to. Anything that off-topic, rude, or unhelpful doesn’t see the light of day. I hope that doesn’t scare you off from commenting. In fact, I hope it encourages it. Anything on-topic and helpful will absolutely be published and won’t be lost in a sea of junk.

We’ve had 20,238 people use our contact form. Don’t worry, I love email.

Goal Review

Double newsletter subscribers. We didn’t double but we grew by a third, which is pretty strong. Especially since we did little to nothing to promote it. We probably need to do a better job of promoting it and somehow incentivizing signups, especially since it’s such a good way to reach people.

More pairing videos. Pretty hard fail here. The main difficulty is scheduling multiple people together, combined with the pressure of producing something worth watching. It’s one thing for an audio podcast like ShopTalk where we can schedule someone and just chit-chat about tech. It’s another thing to ask someone to pair with you and essentially do live coding. It’s still a good idea, it just needs a more serious time commitment and leader. And honestly, probably a sponsor so that it can be worth everyone’s time.

Maintain a mostly-daily publishing schedule. Check and check! This is the first year we’ve actually kept an honest to god schedule, structured after daily posting. We’ll be moving forward with that for sure.

Assemble content in more useful ways. We got a good start on this with Guides. We haven’t done a ton with them yet, but we have given ourselves a way to build these without too much effort, and I think the potential in them is fantastic.

New Goals

Publish something in a new format. We have a lot of publishing power around here with lots of writers and a solid platform. Let’s use it to publish a book or something book-like.

More editorial vision. Admittedly, what we published each day is a bit random. That’s not a terrible thing since the site has a niche anyway, but I’d call it a good goal to exert some editorial guidance to what we publish and when. Meaning commissioning and shepherding work that is a good fit for this site and publishing it with timing that makes some sort of sense.

Interesting sponsorship partners. The most rewarding and powerful partnerships between sponsors and publications are ones of mutual respect and admiration. There are loads of businesses out there I think are doing a terrific job of building what the build, and I’d like to forge relationships with them to promote what they do. And do that promotion in a way that we are uniquely able to do. Get in touch if you think you’re a part of that company.

Create another very popular page. It’s just a matter of time and topic. I’d like to find at least one web development topic that could really use a strong reference page and spend a good amount of time making what we consider a perfect fit for that, with the goal of it really resonating with developers.

Most importantly

Thank you, again, for being a part of this community.

See the Pen Text Animation with CSS – thank you screen! by Nooray Yemon (@yemon) on CodePen.


Thank You (2017 Edition) is a post from CSS-Tricks

What You Build

Post pobrano z: What You Build

I tweeted this yesterday and it seemed to resonate with some folks:

Just a little reminder that it’s about 100 times more important what you build than how you build it.

— Chris Coyier (@chriscoyier) December 10, 2017

What I was feeling when I wrote that was a little tired of endless discussions on tech minutia and yearning for more focus on what we are building and discussion about why.

If you’re a reader of this site, you and I live in the same bubble. It’s a nice bubble. It’s full of smart people who like to chat about web design and development. I live it and love it.

It’s easy to get into a heated discussion about frameworks, what type of class names make the most sense, which optimization techniques are most important, or what part of your code base is should be responsible for styling. Those are great discussions that guide our industry.

But what is more important? The naming convention you chose or if your user can actually book a flight? Which state store library you picked or if you actually had the scarf your user was looking for? Which command line tool pulled your dependencies or whether someone was able to find and read the instructions to send in their court appeal?

I was trying to encourage people to build and think about what they are building rather than get too discouraged about the how. You’re building things for people and that’s such a big responsibility. One that outweighs technical choices, as important as they seem.

I enjoyed the pushback I got on it though.

Most of it centered around the fact that if you make poor tech choices, that limits the quality of what you build and slows your ability to change and adapt to changing user needs. Fair enough.

Good tech just might lead to directly better features and UX for your users. Fair enough. Good tech might be a differentiator between you and your competition. Fair enough.

My favorite was calling out the story of the three little pigs. If you aren’t familiar, there is a Big Bad Wolf that is trying to eat the piggies. Each of them built a house to protect themselves. I imagine you can guess which of the pigs did better: the one who built their house out of hay, or the pig who built their house out of bricks.

Fair enough.

Drew McLellan gets into this in All That Glisters, but focuses on the old vs new tech issue:

There are so many new tools, frameworks, techniques, styles and libraries to learn. You know what? You don’t have to use them. You’re not a bad developer if you use Grunt even though others have switched to Gulp or Brunch or Webpack or Banana Sandwich. It’s probably misguided to spend lots of project time messing around with build tool fashions when your so last year build tool is already doing what you need.

And this gem:

Software, much like people, is born with a whole lot of potential and not much utility. Newborns — both digital and meaty — are exciting and cute but they also lead to sleepless nights and pools of vomit.

He goes on to say that what you are building might help dictate your tech choices. Ah yes, the what. Not only is what your things does litearlly the only thing people care about, it also helps guide tech choices.


What You Build is a post from CSS-Tricks

You are what you document

Post pobrano z: You are what you document

There are so many little gems in this piece by Yevgeniy Brikman all about documentation. He digs into a lot more than simply documenting code though and focuses on how we can document every phase of our work, from design to process and beyond.

Here’s my favorite lines that made me sit back and shout “Wahoo!”:

When a developer uses your code, they are really learning a new language, so choose the words in it wisely.

…programs must be written for people to read, and only incidentally for machines to execute.

I like how Yevgeniy suggests that there are kinda two different mindsets that we have to get into when writing code: one for making the dang thing work in the first place, and another for explaining how and why we did a specific way. There’s context-switching that takes place between those different stages of work.

Anyway, when seen in this light, documentation could be much more than a nice-to-have. Instead, it might just be 50% of the work.

Direct Link to ArticlePermalink


You are what you document is a post from CSS-Tricks

Additive Animation with the Web Animations API

Post pobrano z: Additive Animation with the Web Animations API

These features have not landed in any stable browsers at the time of writing. However, everything discussed is already in Firefox Nightly by default and key parts are in Chrome Canary (with the Experimental Web Platform Features flag enabled), so I recommend using one of those browsers (when reading this article) to see as many of the features in action as possible.

Regardless your preferred method of animation on the web, there will be times that you need to animate the same property in separate animations. Maybe you have a hover effect that scales an image and a click event that triggers a translate — both affecting the transform. By default, those animations do not know anything about the other, and only one will visually be applied (since they are affecting the same CSS property and the other value will be overridden).

element.animate({
  transform: ['translateY(0)', 'translateY(10px)']
}, 1000);

/* This will completely override the previous animation */
element.animate({
  transform: ['scale(1)', 'scale(1.15)']
}, 1500);

The second animation in this Web Animations API example is the only one that would be visually rendered in this example as both animations play at the same time and it was the last one defined.

Sometimes we even have grander ideas where we want a foundational animation and then based on some user interaction change in state we smoothly modify the animation a bit midway without affecting its existing duration, keyframes, or easing. CSS Animations and the current Web Animations API in stable browsers today cannot do this out of the box.

A New Option

The Web Animations specification introduces the composite property (and the related iterationComposite). The default composite is 'replace' and has the behavior we have had for years now where an actively animating property’s value simply replaces any previously set value — either from a rule set or another animation.

The 'add' value is where things change from the previous norms.

element.animate({
  transform: ['scale(1)', 'scale(1.5)']
}, {
  duration: 1000,
  fill: 'both'
});
element.animate({
  transform: ['rotate(0deg)', 'rotate(180deg)']
}, {
  duration: 1500,
  fill: 'both',
  composite: 'add'
});

Now both animations will be seen as the browser on the fly figures out the appropriate transformation at a given point in the element’s timeline accounting for both transformations. In our examples, the easing is 'linear' by default and the animations start at the same time, so we can break out what the effective transform is at any given point. Such as:

  • 0ms: scale(1) rotate(0deg)
  • 500ms: scale(1.25) rotate(60deg) (halfway through first animation, 1/3 through second)
  • 1000ms: scale(1.5) rotate(120deg) (end of first, 2/3 through second)
  • 1500ms: scale(1.5) rotate(180deg) (end of second)

See the Pen Animation Composite by Dan Wilson (@danwilson) on CodePen.

So Let’s Get Creative

An individual animation does not just consist of a start state and end state — it can have its own easing, iteration count, duration, and more keyframes in the middle. While an element is mid animation you can throw an additional transformation on it with its own timing options.

See the Pen Add more transform animations by Dan Wilson (@danwilson) on CodePen.

This example lets you apply multiple animations on the same element, all affecting the transform property. To keep from going all out in this example, we limit each animation to a single transformation function at a time (such as only a scale), starting at a default value (such as scale(1) or translateX(0)), and ending at a reasonable random value on that same transformation function, repeated infinitely. The next animation will affect another single function with its own randomized duration and easing.

element.animate(getTransform(), //e.g. { transform: ['rotate(0deg), 'rotate(45deg)'] }
{
  duration: getDuration(), //between 1000 and 6000ms
  iterations: Infinity,
  composite: 'add',
  easing: getEasing() //one of two options
});

When each animation starts, the browser will effectively find where it is in its previously applied animations and start a new rotation animation with the specified timing options. Even if there is already a rotation going in the opposite direction, the browser will do the math to figure out how much a rotation needs to happen.
Since each animation has its own timing options, you are unlikely to see the exact same motion repeated in this example once you have added a few. This gives the animation a fresh feel as you watch it.

Since each animation in our example starts at the default value (0 for translations and 1 for scaling) we get a smooth start. If we instead had keyframes such as { transform: ['scale(.5)', 'scale(.8)'] } we would get a jump because the didn’t have this scale before and all of a sudden starts its animation at half scale.

How are values added?

Transformation values follow the syntax of in the spec, and if you add a transformation you are appending to a list.

For transform animations A, B, and C the resulting computed transform value will be [current value in A] [current value in B] [current value in C]. For example, assume the following three animations:

element.animate({
  transform: ['translateX(0)', 'translateX(10px)']
}, 1000);

element.animate({
  transform: ['translateY(0)', 'translateY(-20px)']
}, { 
  duration:1000,
  composite: 'add'
});

element.animate({
  transform: ['translateX(0)', 'translateX(300px)']
}, { 
  duration:1000,
  composite: 'add'
});

Each animation runs for 1 second with a linear easing, so halfway through the animations the resulting transform would have the value translateX(5px) translateY(-10px) translateX(150px). Easings, durations, delays, and more will all affect the value as you go along.

Transforms are not the only thing we can animate, however. Filters (hue-rotate(), blur(), etc) follow a similar pattern where the items are appended to a filter list.

Some properties use a number as a value, such as opacity. Here the numbers will add up to a single sum.

element.animate({
  opacity: [0, .1]
}, 1000);

element.animate({
  opacity: [0, .2]
}, { 
  duration:1000,
  composite: 'add'
});

element.animate({
  opacity: [0, .4]
}, { 
  duration:1000,
  composite: 'add'
});

Since each animation again is 1s in duration with a linear easing, we can calculate the resulting value at any point in that animation.

  • 0ms: opacity: 0 (0 + 0 + 0)
  • 500ms: opacity: .35 (.05 + .1 + .2)
  • 1000ms: opacity: .7 (.1 + .2 + .4)

As such, you won’t be seeing much if you have several animations that include the value 1 as a keyframe. That is a max value for its visual state, so adding up to values beyond that will look the same as if it were just a 1.

See the Pen Add more opacity animations by Dan Wilson (@danwilson) on CodePen.

Similar to opacity and other properties that accept number values, properties that accept lengths, percentages, or colors will also sum to a single result value. With colors, you must remember they also have a max value, too (whether a max of 255 in rgb() or 100% for saturation/lightness in hsl()), so your result could max out to a white. With lengths, you can switch between units (such as px to vmin) as though it is inside a calc().

For more details, the specification outlines the different types of animation and how the result is calculated.

Working with Fill Modes

When you are not doing an infinite animation (whether you are using a composite or not) by default the animation will not keep its end state as the animation ends. The fill property allows us to change that behavior. If you want to have a smooth transition when you add a finite animation, you likely will want a fill mode of either forwards or both to make sure the end state remains.

See the Pen Spiral: Composite Add + Fill Forwards by Dan Wilson (@danwilson) on CodePen.

This example has an animation with a spiral path by specifying a rotation and a translation. There are two buttons that add new one second animations with an additional small translation. Since they specify fill: 'forwards' each additional translation effectively remains part of the transform list. The expanding (or shrinking) spiral adapts smoothly with each translation adjustment because it is an additive animation from translateX(0) to a new amount and remains at that new amount.

Accumulating animations

The new composite option has a third value — 'accumulate'. It is conceptually in line with 'add' except certain types of animations will behave differently. Keeping with our transform, let’s start with a new example using 'add' and then discuss how 'accumulate' is different.

element.animate({
  transform: ['translateX(0)', 'translateX(20px)']
}, {
  duration: 1000,
  composite: 'add'
});
element.animate({
  transform: ['translateX(0)', 'translateX(30px)']
}, {
  duration: 1000,
  composite: 'add'
});
element.animate({
  transform: ['scale(1)', 'scale(.5)']
}, {
  duration: 1000,
  composite: 'add'
});

At the 1 second mark (the end of the animations), the effective value will be:

transform: translateX(20px) translateX(30px) scale(.5)

Which will visually push an element to the right 50px and then scale it down to half width and half height.

If each animation had been using 'accumulate' instead, then the result would be:

transform: translateX(50px) scale(.5)

Which will visually push an element to the right 50px and then scale it down to half width and half height.

No need for a double take, the visual results are in fact the exact same — so how is 'accumulate' any different?

Technically when accumulating a transform animation we are no longer always appending to a list. If a transformation function already exists (such as the translateX() in our example) we will not append the value when we start our second animation. Instead, the inner values (i.e. the length values) will be added and placed in the existing function.

If our visual results are the same, why does the option to accumulate inner values exist?

In the case of transform, order of the list of functions matters. The transformation translateX(20px) translateX(30px) scale(.5) is different than translateX(20px) scale(.5) translateX(30px) because each function affects the coordinate system of the functions that follow it. When you do a scale(.5) in the middle, the latter functions will also happen at the half scale. Therefore with this example the translateX(30px) will visually render as a 15px translation to the right.

See the Pen Visual Reference: Transform Coordinate Systems by Dan Wilson (@danwilson) on CodePen.

Therefore, with accumulation we can have an order that is different then when we always append the values to the list.

Accumulating for Each Iteration

I mentioned before that there is also a new related iterationComposite property. It provides the ability to do some of the behaviors we have already discussed except on a single animation from one iteration to the next.

Unlike composite, this property only has two valid values: 'replace' (the default behavior you already know and love) and 'accumulate'. With 'accumulate' values follow the already discussed accumulation process for lists (as with transform) or are added together for number based properties like opacity.

As a starting example, the visual result for the following two animations would be identical:

intervals.animate([{ 
  transform: `rotate(0deg) translateX(0vmin)`,
  opacity: 0
}, { 
  transform: `rotate(50deg) translateX(2vmin)`,
  opacity: .5
}], {
  duration: 2000,
  iterations: 2,
  fill: 'forwards',
  iterationComposite: 'accumulate'
});

intervals2.animate([{ 
  transform: `rotate(0deg) translateX(0vmin)`,
  opacity: 0
},{ 
  transform: `rotate(100deg) translateX(4vmin)`,
  opacity: 1
}], {
  duration: 4000,
  iterations: 1,
  fill: 'forwards',
  iterationComposite: 'replace' //default value
});

The first animation is only bumping up its opacity by .5, rotating 50 degrees, and moving 2vmin for 2000 milliseconds. It has our new iterationComposite value and is set to run for 2 iterations. Therefore, when the animation ends, it will have run for 2 * 2000ms and reached an opacity of 1 (2 * .5), rotated 100 degrees (2 * 50deg) and translated 4vmin (2 * 2vmin).

See the Pen Spiral with WAAPI iterationComposite by Dan Wilson (@danwilson) on CodePen.

Great! We just used a new property that is supported in only Firefox Nightly to recreate what we can already do with the Web Animations API (or CSS)!
The more interesting aspects of iterationComposite come into play when you combine it with other items in the Web Animations spec that are coming soon (and also already in Firefox Nightly).

Setting New Effect Options

The Web Animations API as it stands in stable browsers today is largely on par with CSS Animations with some added niceties like a playbackRate option and the ability to jump/seek to different points. However, the Animation object is gaining the ability to update the effect and timing options on already running animations.

See the Pen WAAPI iterationComposite & composite by Dan Wilson (@danwilson) on CodePen.

Here we have an element with two animations affecting the transform property and relying on composite: 'add' — one that makes the element move across the screen horizontally and one moving it vertically in a staggered manner. The end state is a little higher on the screen than the start state of this second animation, and with iterationComposite: 'accumulate' it keeps getting higher and higher. After eight iterations the animation finishes and reverses itself for another eight iterations back down to the bottom of the screen where the process begins again.

We can change how far up the screen the animation goes by changing the number of iterations on the fly. These animations are playing indefinitely, but you can change the dropdown to a different iteration count in the middle of the animation. If you are, for example, going from seven iterations to nine and you are seeing the sixth iteration currently, your animation keeps running as though nothing has changed. However, you will see that instead of starting a reverse after that next (seventh) iteration, it will continue for two more. You can also swap in new keyframes, and the animation timing will remain unchanged.

animation.effect.timing.iterations = 4;
animation.effect.setKeyframes([
  { transform: 'scale(1)' },
  { transform: 'scale(1.2)' }
]);

Modifying animations midway may not be something you will use every day, but since it is something new at the browser level we will be learning of its possibilities as the functionality becomes more widely available. Changing iteration counts could be handy for a game when a user get a bonus round and gameplay continues longer than originally intended. Different keyframes can make sense when a user goes from some error state to a success state.

Where do we go from here?

The new composite options and the ability to change timing options and keyframes open new doors for reactive and choreographed animations. There is also an ongoing discussion in the CSS Working Group about adding this functionality to CSS, even beyond the context of animations — affecting the cascade in a new way. We have time before any of this will land in a stable major browser, but it is exciting to see new options coming and even more exciting to be able to experiment with them today.


Additive Animation with the Web Animations API is a post from CSS-Tricks