Web Standards

Monitoring unused CSS by unleashing the raw power of the DevTools Protocol

Css Tricks - Fri, 01/05/2018 - 10:38am

From Johnny's dev blog:

The challenge: Calculate the real percentage of unused CSS

Our goal is to create a script that will measure the percentage of unused CSS of this page. Notice that the user can interact with the page and navigate using the different tabs.

DevTools can be used to measure the amount of unused CSS in the page using the Coverage tab. Notice that the percentage of unused CSS after the page loads is ~55%, but after clicking on each of the tabs, more CSS rules are applied and the percentage drops down to just ~15%.

That's why I'm so skeptical of anything that attempts to measure "unused CSS." This is an incredibly simple demo (all it does is click some tabs) and the amount of unused CSS changes dramatically.

If you are looking for accurate data on how much unused CSS is in your codebase, in an automated fashion, you'll need to visit every single URL on your site and trigger every possible event on every element and continue doing that until things stop changing. Then do that for every possible state a user could be in—in every possible browser.

Here's another incredibly exotic way I've heard of it being done:

  1. Wait a random amount of time after the page loads
  2. Loop through all the selectors in the CSSOM
  3. Put a querySelector on them and see if it finds anything or not
  4. Report those findings back to a central database
  5. Run this for enough time on a random set of visitors (or all visitors) that you're certain is a solid amount of data representing everywhere on your site
  6. Take your set of selectors that never matched anything and add a tiny 1px transparent GIF background image to them
  7. Run that modified CSS for an equal amount of time
  8. Check your server logs to make sure those images were never requested. If they were, you were wrong about that selector being unused, so remove it from the list
  9. And the end of all that, you have a set of selectors in your CSS that are very likely to be unused.

Clever, but highly unlikely that anyone is using either of these methods in a consistent and useful way.

I'm a little scared for tools like Lighthouse that claim to audit your unused CSS telling you to "remove unused rules from stylesheets to reduce unnecessary bytes consumed by network activity." The chances seem dangerously high that someone runs this, finds this so-called unused CSS and deletes it only to discover it wasn't really unused.

Direct Link to ArticlePermalink

Monitoring unused CSS by unleashing the raw power of the DevTools Protocol is a post from CSS-Tricks

`font-size` With All Viewport Units

Css Tricks - Fri, 01/05/2018 - 8:39am

We've covered fluid type a number of times. This page probably covers it in the best detail. It's a little more complicated than simply using a vw unit to set the font-size since that's far too dramatic. Ideally, the font-size is literally fluid between minimum and maximum values.

Someday there will be min-font-size and max-font-size (probably), but until then, our fluid type implementations will probably need to resort to some @media queries to lock those mins/maxes.


Around a year ago Matt Smith documented a technique I had missed. It calculates font-size using a little bit of vw, a little bit of vh, and a little bit of the smaller of the two...

:root { font-size: calc(1vw + 1vh + .5vmin); }

Of course, it depends on the font and what you are doing with it, but it seems to me this tempers the curve such that you might not really need a min and max.

Direct Link to ArticlePermalink

`font-size` With All Viewport Units is a post from CSS-Tricks

A Round-Up of 2017 Round-Ups

Css Tricks - Fri, 01/05/2018 - 5:03am

This week marked the beginning of a new year and with it came a slew of excellent write-ups from folks in our industry reflecting on the year past. We thought it would be nice to compile them together for easy reference. If you know of any others that should be on everyone's radar, please leave it in the comments.

Now on to the round-up of round-ups!

Rachel Andrew

Having been wandering the globe talking about CSS Grid for almost five years, Grid finally shipped in browsers in 2017. This was good, as I didn’t really want to be some kind of CSS vapourware lady. I knew Grid was important the first time I read the initial spec. I had no idea how my championing of the specification would change my life, and allow me to get to work with so many interesting people.

Read More

Geri Coady

One of my biggest achievements this year was the release of my second book, Color Accessibility Workflows, published by A Book Apart. I’m hugely grateful for any opportunity to talk about color and how it can impact people in the digital world, and writing for A Book Apart has long been a dream of mine.

Read More

Monica Dinculescu

You can tell I hate writing year in reviews because this one is really, really late. I tend to hate bragging, and I definitely hate introspective and, in particular, I always think I am underperforming (and that’s fine). However, that’s usually not true, and writing a year in review forces me to see the awesome things I did, so even if I did end up underperforming, at least I can learn from that. That’s the whole point of post-mortems, right?

Read More

Sarah Drasner

This year has been a surreal one for me. I’ve had years that were particularly tough, years that trended more cheerfully, but 2017 was unique and bizarre because I felt an immense guilt in my happiness.

I think this might have been the year I found the most personal happiness, but the giant caveat in everything was watching the world divide, watching racism, sexism and hatred rise, and seeing some real damage that incurred on people’s lives around the world.

Read More

Brad Frost

Throughout 2017, when people asked how I was doing, I’d say “Great…for the things I can control.” 2017 was a rough year at a macro level for everybody, and I found myself coping with the state of the world in a number of different ways. But on a personal level, I had a rewarding year full of a lot of work, a lot of travel, and even some major life changes.

Read More

Geoff Graham

It feels kind of weird to include my own round-up, but whatever.

I've typically set goals for myself at the start of each year and followed up on them somewhere towards the end of the year. Unfortunately, the last time I did that out loud was in 2014. I’ve been pretty quiet about my goals and general life updates since then and it’s certainly not for lack of things to write about. So, I’m giving this whole reflection thing the ol’ college go once again.

Read More

Jeremy Keith

Jeremy published 78 blog posts in 2017 (or 6.5 per month as he calculates it) and noted his personal favorites.

Read More

Zach Leatherman

I had an incredibly productive year of side projects, learning, and blog posts—I can attribute almost all of that rediscovered time and energy to quitting Facebook very early in the year. It’s also been amazing to see my daughter grow and learn—she turned two this year and I really love being a dad. We now have our own secret handshake and it’s my favorite thing.

Read More

Ethan Marcotte

And finally, one of the things I’m most proud of is, well, this little website, which I launched hastily just over a year ago. And over the last entirely-too-eventful year, I’ve surprised myself with just how much it helped to be blogging again. Because while the world’s been not-so-lightly smoldering, it felt—and feels—good to put words in a place where I can write, think, and tinker, a place that isn’t Twitter, a place that’s mine.

Read More

Eric Meyer

While this is not so much a reflection on the past year, Eric did mark the new year with a livestream redesign of his personal website—the first design update in 13 years.

My core goal was to make the site, particularly blog posts, more readable and inviting. I think I achieved that, and I hope you agree. The design should be more responsive-friendly than before, and I think all my flex and grid uses are progressively enhanced. I do still need to better optimize my use of images, something I hope to start working on this week.

Read More

Dave Rupert

My big work task this year was building a Pattern Library and it’s exciting to see that work beginning to roll out. The most gratifying aspect is seeing the ultimate Pattern Library thesis proven out: Speed. Pages load faster, CMS integrations are faster, and we can successfully turn out new production pages within a 1-day turnaround.

Read More

David Walsh

David used the new year to think about and plot upcoming goals.

Every turn of the year is a new opportunity to start over, set goals, and renew optimism that time can heal wounds and drive us to change and achieve. For me 2018 is my most important year in a long time; 2018 needs to serve as a turning point for this blog and my career.

Read More

Trent Walton

Dave, Reagan, and I celebrated our 10th official year as Paravel. In addition to some shorter-term projects, we undertook a large-scale pattern library and front-end update that is rolling out in phases this year. We’ve also enjoyed bringing in 6+ collaborators/teams to assist with projects when the need has arisen. I bet we do more of this in 2018—collaborating with friends has been fun.

Read More


Think we'd leave out our own round-up? Of all the site stats Chris shared in this post, this one nicely summed up the action around here in 2017:

We were on a publishing roll 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.

Read More

A Round-Up of 2017 Round-Ups is a post from CSS-Tricks

Front-End Performance Checklist

Css Tricks - Thu, 01/04/2018 - 10:01am

Vitaly Friedman swings wide with a massive list of performance considerations. It's a well-considered mix of old tactics (cutting the mustard, progressive enhancement, etc.) and newer considerations (tree shaking, prefetching, etc.). I like the inclusion of a quick wins section since so much can be done for little effort; it's important to do those things before getting buried in more difficult performance tasks.

Speaking of considering performance, Philip Walton recently dug into what interactive actually means, in a world where we throw around acronyms like TTI:

But what exactly does the term “interactivity” mean?

I think most people reading this article probably know what the word “interactivity” means in general. The problem is, in recent years the word has been given a technical meaning (e.g. in the metric “Time to Interactive” or TTI), and unfortunately the specifics of that meaning are rarely explained.

One reason is that the page depends on JavaScript and that JavaScript hasn't downloaded, parsed, and run yet. That reason is well-trod, but there is another one: the "main thread" might be busy doing other stuff. That is a particularly insidious enemy of performance, so definitely read Philip's article to understand more about that.

Also, if you're into front-end checklists, check out David Dias' Front-End Checklist.

Direct Link to ArticlePermalink

Front-End Performance Checklist is a post from CSS-Tricks

26 Fabulous Scripts Fonts

Css Tricks - Thu, 01/04/2018 - 6:24am

(This is a sponsored post.)

Just $9.

They are nicely constructed as well, with stylistic alternates, ligatures, punctuation, extra characters, and multilingual support.

Direct Link to ArticlePermalink

26 Fabulous Scripts Fonts is a post from CSS-Tricks

Fun Times With Sizing Grid Elements

Css Tricks - Thu, 01/04/2018 - 6:24am

Chris showed us a little while back that CSS grid areas and their elements are not necessarily the same size. It's an interesting point because one might assume that putting things into a grid area would make those things occupy the entire space, but grid areas actually reserve the space defined by the grid and set the element's justify-content and align-items properties to a stretch value by default.

So... yes, they are the same size, but not necessarily.

Chris ended his post by asking "who cares?" while indicating no one in particular. The point was much more geared toward calling this out as a starting point for folks who need to align content in the grid.

I'm not sure I have a better answer, but it made me think it would be fun if we could leverage those auto-assigned stretch values to adapt a user interface in interesting ways.

I'm not saying any of these are great use cases. In fact, they may be downright silly. That said, maybe they can be the starting point for other ideas.

Stretching Form Fields

One idea is to add some interaction to form fields. If our <form> is the grid container then we can set text inputs where they start at their default width using the start value and then expanding them to the full width of the container by switching to the stretch value on a :focus state:

.grid__form { display: grid; } .grid__input { justify-self: start; } .grid__input:focus { justify-self: stretch; }

See the Pen CSS Grid: Grid Child Stretch on Focus by Geoff Graham (@geoffgraham) on CodePen.

Then again, we can already do something similar with Flexbox but with the benefit of the flex being an animated property:

See the Pen Flexbox: Child Stretch on Focus by Geoff Graham (@geoffgraham) on CodePen.

I'm honestly not sure where expanding form fields on focus would make for great UX but it's certainly fun to play with.

Curtain Opening Effect Re-Visited

We posted a good ol' fashioned CSS trick last year that uses the checkbox hack to create the effect of a curtain opening to reveal content behind it.

See the Pen OXJMmY by Geoff Graham (@geoffgraham) on CodePen.

That used widths and positioning to move things around on click, but we could have done something similar with Grid. Again, this is less robust because it lacks animation and the does not allow the curtain to fully open, but it does show how we can leverage the stretch, start and end values of a grid element and its sizing to achieve some interesting ideas.

See the Pen CSS Grid Curtain Reveal by Geoff Graham (@geoffgraham) on CodePen.

What Else?

The fact that grid elements are not always the size of the grid area is a nice tip to keep in our back pockets as we develop layouts. I'd bet we can come up with more ideas to take that concept to another level and have fun with it as a group. Share 'em if you have 'em!

Fun Times With Sizing Grid Elements is a post from CSS-Tricks

CodePen’s Most Hearted of 2017

Css Tricks - Wed, 01/03/2018 - 2:26pm

The most fun year-end list there is, if you ask me.

Direct Link to ArticlePermalink

CodePen’s Most Hearted of 2017 is a post from CSS-Tricks

Array Explorer and Object Explorer

Css Tricks - Wed, 01/03/2018 - 9:38am

Sarah made these incredibly handy interactive code reference... thingers.

The idea is perfect. I'm in this position regularly. I know what I have (i.e. an array or an object). I know what I want to do with it (i.e. get an array of all the keys in my object). But I forget the actual method name. These thingers guide you to the right method by letting you tell it what you got and what you wanna do.

Array Explorer

See the Pen Array Explorer by Sarah Drasner (@sdras) on CodePen.

Object Explorer

See the Pen Object Explorer by Sarah Drasner (@sdras) on CodePen.

Array Explorer and Object Explorer is a post from CSS-Tricks

Improving the Accessibility of 24 ways

Css Tricks - Wed, 01/03/2018 - 4:41am

I’ve been thinking recently about the nature of my work and which aspects of it I enjoy the most. In a role that will often straddle the realms of design and development, whether editing copy, evaluating the design of an interface or refactoring code, I've come to realize that my interests lie in the act of review and refinement.

My work on 24 ways is a case in point. Since Drew McLellan asked me to redesign the site in 2013, I’ve stayed on as part of the team, helping to review, edit and format articles. But I’ve also been able to fulfil the desire I expressed upon launching the redesign:

I'm a big believer in iteration and not treating a website as ever being finished. I hope what’s been released this year can act as a foundation, and that the design will evolve in the years to come.

In the intervening years, as tools have improved and best practices have matured, I've tweaked the design and refactored the code, and developed a component library in the process.

The 24 ways home page A Focus on Accessibility

This year I've been listening to people like Laura Kalbag talk about accessibility in terms of universal design, and followed blogs like Heydon Pickering’s Inclusive Components, which covers how to design and implement common interaction patterns with an inclusive mindset. All of a sudden, the thorny subject of accessibility has felt more approachable and less dogmatic.

With all this knowledge digested, I was keen to see how 24 ways would fare when put under the microscope. In this article, I will cover five areas where I was able to make improvements:

  • Page structure
  • Labelling of elements
  • Keyboard navigation
  • Aural experience
  • General usability

Before I start, a note of thanks. After making an initial set of changes, I asked my friend and accessibility expert Francis Storr to review my work. He uncovered a number of additional issues, partly the result of his experience in this area, but also from having tested the site with a range of different assistive tools.

Rethinking Page Structure

The original design had adopted a mobile-first approach. The navigation was deprioritized and placed towards the bottom of the page. To ensure that it could be accessed from the top of the page in non-JavaScript scenarios, I added a skip to navigation link. If JavaScript was available, this link was co-opted to reveal a navigation drawer, which would slide in from the top or right, depending on the width of the viewport. This resulted in the following page structure:

<header class="c-banner">…</header> <a class="c-menu" href="#menu">Jump to menu</a> <main class="c-main">…</main> <nav class="c-navigation" id="menu"> <div class="c-traverse-nav">…</div> <div class="c-navigation__drawer"/>…</div> </nav> <footer class="c-contentinfo">…</footer>

In retrospect, this was problematic in a number of ways:

  • The menu button (.c-menu) was not adjacent to the element it controlled (c-navigation-drawer). Moving focus around the page like this can be confusing, especially if it’s not managed properly.
  • All navigation on the site was grouped together, even though each set of links served a different purpose.
  • The drawer behaviour relied on having a link behave like a button. However, the first rule of ARIA states:

    If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so

    Last year, I updated the JavaScript so that this link would be replaced by a button, yet this complexity was a hint that my original solution was sub-optimal.

Here's the structure I arrived at today:

<header class="c-banner"> … <a class="c-banner__skip" href="#main">Skip to content</a> </header> <div class="c-menu"> <button class="c-menu__button">…</button> <div class="c-menu__drawer">…</div> </div> <main class="c-main" id="main">…</main> <nav class="c-traverse-nav">…</nav> <footer class="c-contentinfo">…</footer>

Moving the navigation towards the top of the page meant the button and drawer were now adjacent to each other. The menu button is no longer two-faced; it is and always will be a button.

A downside to this approach is that the navigation can be heard every time you visit a new page. Again, we can use a skip link, but this time one that points to the content block (#main). Rather than hide this focusable element from certain users, it becomes visible on focus.

This structure may be less ideologically pure, but it’s far more pragmatic. This became a recurring theme. Indeed, having given up any hope of the HTML5 outline algorithm ever being supported by browsers, I stopped using h1 for section headings and followed the recommendation that heading ranks should be used to convey document structure instead.

Improving Keyboard Navigation

As the most interactive component on the site, the menu was the unsurprising focus of my review. The design dictates that the navigation drawer should behave like a dialog, an interface pattern that brings with it a number of assumptions. These are described in detail in eBay's MIND pattern, but essentially a dialog draws focus away from other elements on the page and is modal; only elements within it can be operated while it is open.

I had previously cobbled together various bits of JavaScript to handle focusing (cobbling which at various points produced the odd bug such as failing to draw focus to the first element in the dialog), but had neglected to indicate the menu’s role. Having fixed these issues (adding role='dialog' when the menu is open), Francis pointed out that screen readers could still access links outside the dialog when it was open. In macOS VoiceOver for example, pressing CTRL + OPT + CMD + L to navigate links within the menu, would in fact announce every link on the page.

The solution was to mark everything outside the dialog as "inert". Rob Dodson describes this in more detail in his video Accessible Modal Dialogs. Implementing this can be a little bit fiddly, but a proposal to introduce an inert attribute would make this easier to manage. In the meantime, the proposal provides a polyfill so you can use this feature today.

I’ve found that by thinking about an interface in terms of common interaction patterns, and how they should operate in order to be widely understood, has helped me avoid complexity, and write more robust code. In fact, stepping into the world of accessibility has uncovered a wealth of useful resources, with well-written JavaScript examples a plenty. Given my difficult relationship with the web’s programming language, these have proven invaluable.

Properly Labelling Elements

A good amount of accessibility comes down to labelling things that rely on visual appearance alone to convey meaning. Much like the alt attribute allows us to describe images, aria-label (and its relations) extend this ability to other elements.

Navigation component that allows users to move between articles in a series.

Here is the markup I was using in the navigation element that allows users to traverse previous and next articles within a series:

<div class="c-traverse-nav"> <a rel="prev" href="/2016/we-need-to-talk-about-technical-debt/" data-sequence-title="We Need to Talk About Technical Debt"> <svg width="20" height="20" viewBox="0 0 200 200" role="img"> <path d="M50 100l85 85 7-7-78-78 78-78-7-7"/> </svg> <span class="u-hidden">Previous article</span> </a> <a rel="next" href="/2016/what-the-heck-is-inclusive-design/" data-sequence-title="What the Heck Is Inclusive Design?"> <span class="u-hidden">Next article</span> <svg width="20" height="20" viewBox="0 0 200 200" role="img"> <path d="M150 100l-85 85-7-7 78-78-78-78 7-7"/> </svg> </a> </div>

While I had provided text content for these links, this component still had a number of issues:

  • No indication was given as to the role these links play and their relationship to each other.
  • Using role='img' on the SVG icons, but not providing any accessible names, was akin to including images without alt attributes.
  • Useful information, in this case the title of the previous and next article, was hidden within a data- attribute. This attribute was used in the stylesheet to add content that is shown in animated ‘flaps’ that appear on hover:
.c-traverse-nav a[rel=prev]:hover::after { content: 'Previous: \A' attr(data-sequence-title); } .c-traverse-nav a[rel=next]:hover::after { content: 'Next: \A' attr(data-sequence-title); }

Meaningful content in CSS? That should have been a red flag. I revised this component as follows:

<nav class="c-traverse-nav" aria-label="Articles"> <a rel="prev" href="/2016/what-the-heck-is-inclusive-design/" aria-label="Previous: We Need to Talk About Technical Debt"> <svg width="20" height="20" viewBox="0 0 200 200" focusable="false" aria-hidden="true"> <path d="M50 100l85 85 7-7-78-78 78-78-7-7"/> </svg> </a> <a rel="next" href="/2016/what-the-heck-is-inclusive-design/" aria-label="Next: What the Heck Is Inclusive Design?"> <svg width="20" height="20" viewBox="0 0 200 200" focusable="false" aria-hidden="true"> <path d="M150 100l-85 85-7-7 78-78-78-78 7-7"/> </svg> </a> </nav>

The first thing I did was give this set of links a label. I originally choose Articles navigation. However, in testing VoiceOver would announce: navigation, Articles navigation. As the nav element already describes the role, we need only provide additional information about the type of navigation this is.

Secondly, on the advice of Francis, I added focusable='false' to all inline SVG markup. This is due to a bug in IE11 where SVGs are keyboard focusable by default.

Regarding the labelling of the SVG icons, I had two choices. I could either move the hidden text content to these icons using aria-label, or remove them from the accessibility tree entirely using aria-hidden. In considering the second option, I realised I could merge the hidden text with that in the data- attribute, and use this combined information within an aria-label attribute. All of a sudden, my CSS became much simpler:

.c-traverse-nav a:hover::after { content: attr(aria-label); }

Accessible markup is useful markup.

Considering the Aural Experience

Navigating the site using a screen reader lead to me making a few other small changes as well. For example, a few links on the site include a right-pointing arrow, a visual flourish created using the following CSS:

.c-continue::after { content: ' \203A'; /* Single Right-Pointing Angle Quotation Mark */ }

However, screen-readers typically announce generated content. When these links were read out, you’d hear nonsense like this:

link, more articles by drew single right-pointing angle quotation mark.

Adding speak: none had no effect (CSS aural properties have little support). However, I could create a similar arrow using CSS borders:

.c-continue::after { display: inline-block; vertical-align: middle; height: 0.375em; width: 0.375em; border: 0.1875em solid; border-color: currentColor currentColor transparent transparent; transform: rotate(45deg); content: ''; } Continue links before and after improvements. While they look similar, the revised design sounds much better.

I also made improvements to the styling of author names in article summaries. Originally, these were distinguished from the rest of the excerpt by styling them as uppercase text. Francis pointed out that some screen readers will spell out uppercase letters (regardless of whether they appear in the HTML or have been altered by CSS) if they don’t spell a known word. For example VoiceOver and NVDA have trouble with Chris Coyier's surname, so his name would be read aloud as Chris C-O-Y-I-E-R. The simple fix was to distinguish names using emboldened text instead.

If I'm honest, I’ve been somewhat arrogant in the past, thinking that by using semantic markup and progressive enhancement, I needn’t worry too much about accessibility. While using the right elements, and considering an interface not only in visual terms is important, this is the absolute bare minimum. An understanding of different assistive technologies, and willingness to test with them, is just as important.

Reviewing General Usability

Thinking about accessibility led to me improve overall usability, too.

For this years set of articles, we no longer link to author's websites from article excerpts. This historical holdover was poorly resolved previously; if you happened to click on the author’s name you would be taken to their website, not the article as you would expect. We also included comment counts that were linked to the comment section on the article page (which itself linked to a separate comments page). Madness!

Now, each article has one link; to the article. A home page that once involved tabbing through 24×3 links, is now less noisy and much easier to navigate for everyone.

Other refinements included ensuring the site is responsive in terms of height, as well as width, ensuring the navigation menu can be dismissed when you click outside of it, and a review of overall performance. These might not be considered accessibility improvements, but I’m not so sure. To suggest this would be to think accessibility is an entirely separate concern. In fact, making changes that benefit one set of users will typically benefit all.

Creating something new will always attract attention and admiration, but there’s an under-celebrated nobility in improving what already exists. While not all changes may be visual, they can have just as much impact. I know that, had we decided to redesign the site this year, many of these improvements would not have been made. Hopefully, this overview will encourage you to look at your own projects and think about similar changes you might make.

Having a growing awareness of the issues, and expanding your knowledge of the tools available is an essential requirement of working on the web. However, don’t keep that knowledge saved up for the future; if you can, go back and fix your older projects too.

Improving the Accessibility of 24 ways is a post from CSS-Tricks

You are what you document

Css Tricks - Tue, 01/02/2018 - 11:42am

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

Css Tricks - Tue, 01/02/2018 - 5:37am

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

Thank You (2017 Edition)

Css Tricks - Mon, 01/01/2018 - 6:12am

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 roll 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

Css Tricks - Sat, 12/30/2017 - 5:26am

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

Wed, 12/31/1969 - 2:00pm
Syndicate content
©2003 - Present Akamai Design & Development.