The Tragicomedy: CSS Color Names

The Tragicomedy: CSS Color Names

The CSS “Named Colors” section of the CSS Color Module Level 4—the latest specification for color values and properties within the Cascading Style Sheets language—are 141 standard colors. Each has its own name, so beyond the essentials of “black” and “white” are shades like “papaya whip,” a warm orange pastel; “lemon chiffon,” a faint, milky yellow; and “burlywood,” which has likely made an appearance on a safari tour guide’s shorts.

At first glance, these names seem fluffy, and they bear connotations of sugary, whimsical romanticism. Where do such abstract names come from, and why are they a part of something as methodical as writing code?

The answer to these questions begins in 1980s Massachusetts. Originally, the colors were a product of the X Window System (X), a graphical user interface (GUI) released by MIT in 1984. In June of 1986, the first list of GUI colors, which was tuned to the DEC VT240 series terminal, shipped with the third release of X’s tenth version (X10R3). It comprised 69 basic shades, with 138 entries to account for different cases in the color names (e.g., lowercase with spacing like “dark red” versus camel case like “DarkRed”).

In 1988, X11R2 arrived with the addition of three colors, including the identical shades “gray” and “grey.” According to Austin-based developer Alex Sexton, discussing the colors at a JavaScript Conference last year, programmers at Hewlett-Packard couldn’t remember the proper spelling (which was originally with an ‘a’). Including two names, it was thought, would prevent errors.

The most substantial release, created by Paul Raveling, came in 1989 with X11R4. This update heralded a slew of light neutral tones, and it was a response to complaints from Raveling’s coworkers about color fidelity. (In the ‘80s, colors could vary dramatically from monitor to monitor, depending on the machine vendor. As if to illustrate this, a particularly baffled employee exclaimed, “That’s Wheat???!!!” upon the sight of the hue in the previous text file.) In this version, programmers were introduced to the aforementioned “papaya whip” and “lemon chiffon,” as well as other loftily-named hues like “blanched almond” and “peach puff.”

Raveling drew these names from an unsurprising source: the (now-defunct) paint company Sinclair Paints. It was an arbitrary move; after failing to receive sanctions from the American National Standards Institute (ANSI), which issued standards for Web color properties, Raveling decided to take matters into his own hands. He calibrated the colors for his own HP monitor. “Nuts to ANSI & ‘ANSI standards,’” he complained.

Later that year, X11 gained a set of bolder colors thanks to another programmer, John C. Thomas. Just as Raveling’s update tweaked shades to assuage user confusion, Thomas’s addressed the following written objection from coworker Bruce Schuchardt in 1989:

“[I] am still shocked and horrified by the default colors in the rgb database. The ‘pink’ color in particular looks like the flesh-tone of someone who has been puking for several hours and would really rather get a bullet in the head than go on living.”

Thomas agreed. Frustrated with inconsistent displays, he started to find it futile to standardize color names. In response, he stated in an e-mail that he “sat down one evening with the handiest standard of subjective color names, a box of 72 Crayola crayons.” That birthed “aquamarine,” “orchid,” and “salmon,” to name a few.

By 2001, the World Wide Web Consortium (W3C) published the first working draft of the CSS 3 Color Module that would include the colors. In light of evolving technologies, the colors had fallen out of use, but the W3C claimed the goal was to “codify current practices.” Every browser supported the colors at this point, consequently, the W3C had been using them in compatibility tests. Incorporating the colors into CSS, then, would prevent sites from breaking.

“It was like a backwards-compatibility thing. They thought, ‘We’ve accidentally been doing this, so we might as well just not break it,’” Sexton told Ars.

Backlash ensued. The color database had been subjected to the whims of so many different programmers that it became deeply disorganized, leading some to argue it had no place in CSS. Critics attacked its naming scheme: “dark gray” was lighter than “gray”; there was a “medium violet red” but no “violet red”; “light goldenrod yellow” had no corresponding “goldenrod yellow.” In total 17 colors had dark versions, but only 13 had light ones. Color distribution was also uneven, skewing toward reds and greens and away from blues.

Perhaps the most vehement denunciation comes from a 2002 e-mail written by programmer Steven Pemberton: “The X11 colour names are an abomination that should have been stifled at birth, and adding them to CSS is a blemish on the otherwise excellent design of CSS. To say that the X11 colour set and their names have been ‘designed’ is an insult to the word ‘design.’ It is just a mess.”

Another point of contention was cultural exclusion. Some programmers took umbrage at the region-centric nature of names like “dodger blue” and the potential racial undertones of “navajo white” (from Sinclair Paints) and “indian red” (from Crayola, though the crayon has since been renamed in response to the same concerns). Others considered the English-only names alienating.

“I’m not a native English speaker. Imagine my reaction the first time I saw the ‘gainsboro’ color  or ‘papaya whip,’” Daniel Glazman, co-chairman of the CSS Working Group, told Ars.

Ostensibly, these repercussions could have been prevented. In the ‘80s, X system programmers had the option to identify colors the way many developers do today: with a hexadecimal value (AKA hex value, e.g., #FFFF00) or an RGB color code (e.g., 255,255,0). These options allow a greater degree of choice and precision, and they’re based on schematic, objective, globally legible systems. Why weren’t they used in the first place?

“It was a recognition that almost nobody likes using the numeric values. People don’t think in terms of F5B as a particular shade of color. Using a name is more natural,” said Jim Fulton, a student at MIT at the time of X’s creation and manager of Raveling’s and Thomas’s files. However, he conceded, “Not every idea works out well.”

In 2014, however, an unexpected event cast the color list in a more favorable light: a new shade. “Rebecca purple,” was introduced to honor the life of Rebecca Meyer, the daughter of Eric Meyer, a respected programmer and CSS writer. Rebecca died of brain cancer at the age of six; the hue (#663399) was chosen to reflect her favorite color. (A few developers opposed the addition, maintaining that a set of standards was no place for an emotional tribute. They were dismissed as curmudgeons.)

Still, the general consensus is that these colors’ utility is minimal; they’re best reserved as placeholders (it’s easier to type “tomato” than “#FF6347” when you need a color quickly), for beginner-level design projects, or as the butt of a joke.

“I view it with amusement that the colors seem to have migrated into CSS. I just laugh at it,” Fulton told Ars. “I think if someone were to go and crawl over the top 100 or top 1,000 sites and take a look at how various colors are specified, I’m willing to bet you’d still find close to zero percent using color names beyond ‘white’ or ‘black.’”

“If I’m doing an example to show people how to use an editor or a framework, I use hex values like #C0FFEE or #BADA55. It’s about as useful to use #C0FFEE as it is to use ‘papaya whip,’” Sexton added.

Should the colors have been left without standard names then, sparing the development community from a series of angry e-mails and micro-controversies? According to Fulton, probably. Then again, as programmers navigated the uncharted territory of color-displaying GUIs in the ‘80s, it was only natural to experiment any way they knew how.

“At the time, we were dealing with, in some ways, the very beginnings of the graphical home-computer industry,” he said. “For color devices especially, this was the very beginning.”


CSS Animations vs. JavaScript

CSS Animations vs. JavaScript

Once upon a time, most developers used jQuery to animate things in the browser. Fade this, expand that; simple stuff. As interactive projects got more aggressive and mobile devices burst onto the scene, performance became increasingly important. Flash faded away and talented animators pressed HTML5 to do things it had never done before. They needed better tools for complex sequencing and top-notch performance. jQuery simply wasn’t designed for that. Browsers matured and started offering solutions.

The most widely-acclaimed solution was CSS Animations (and Transitions). The darling of the industry for years now, CSS Animations have been talked about endlessly at conferences where phrases like “hardware accelerated” and “mobile-friendly” tickle the ears of the audience. JavaScript-based animation was treated as if it was antiquated and “dirty”. But is it?

As someone who’s fascinated (bordering on obsessed, actually) with animation and performance, I eagerly jumped on the CSS bandwagon. I didn’t get far, though, before I started uncovering a bunch of major problems that nobody was talking about. I was shocked.

This article is meant to raise awareness about some of the more significant shortcomings of CSS-based animation so that you can avoid the headaches I encountered, and make a more informed decision about when to use JS and when to use CSS for animation.

Lack of independent scale/rotation/position control

Animating the scale, rotation, and position of an element is incredibly common. In CSS, they’re all crammed into one “transform” property, making them impossible to animate in a truly distinct way on a single element. For example, what if you want to animate “rotation” and “scale” independently, with different timings and eases? Maybe an element is continuously pulsing (oscillating scale) and you’d like to rotate it on rollover. That’s only possible with JavaScript.

In my opinion, this is a glaring weakness in CSS but if you only do simpler animations that animate the entire transform state at any given time, this won’t be an issue for you.

Performance

Most comparisons on the web pit CSS animations against jQuery since it is so pervasive (as if “JavaScript” and “jQuery” were synonymous) but jQuery is widely known to be quite slow in terms of animation performance. The newer GSAP is also JavaScript-based but it’s literally up to 20x faster than jQuery. So part of the reason JavaScript animation got a bad reputation is what I call the “jQuery factor”.

The most frequently cited reason for using CSS for animation is “hardware acceleration”. Sounds yummy, right? Let’s break it down into two parts:

GPU involvement

The GPU is highly optimized for tasks like moving pixels around and applying transform matrices and opacity, so modern browsers try to offload those tasks from the CPU to the GPU. The secret is to isolate the animated elements onto their own GPU layers because once a layer is created (as long as its native pixels don’t change), it’s trivial for the GPU to move those pixels around and composite them together. Instead of calculating every single pixel 60 times per second, it can save chunks of pixels (as layers) and just say “move that chunk 10 pixels over and 5 pixels down” (or whatever).

Side note: It’s not wise to give every element its own layer because GPUs have limited video memory. If you run out, things will drastically slow down.

Declaring your animations in CSS allows the browser to determine which elements should get GPU layers, and divvy them up accordingly. Super.

But did you know you can do that with JavaScript too? Setting a transform with a 3D characteristic (like translate3d() or matrix3d()) triggers the browser to create a GPU layer for that element. So the GPU speed boost is not just for CSS animations – JavaScript animation can benefit too!

Also note that not all CSS properties get the GPU boost in CSS animations. In fact, most don’t. Transforms (scale, rotation, translation, and skew) and opacity are the primary beneficiaries. So don’t just assume that if you animate with CSS, everything magically gets GPU-juiced. That simply isn’t true.

Offloading calculations to a different thread

The other part of “hardware acceleration” has to do with being able to use a different CPU thread for animation-related calculations. Again, this sounds great in theory but it doesn’t come without costs, and developers often overestimate the benefits.

First of all, only properties that don’t affect document flow can truly be relegated to a different thread. So again, transforms and opacity are the primary beneficiaries. When you spin off other threads there’s overhead involved with managing that process. Since graphics rendering and document layout eat up the most processing resources (by FAR) in most animations (not calculating the intermediate values of property tweens), the benefit of using a separate thread for interpolation is minimal. For example, if 98% of the work during a particular animation is graphics rendering and document layout, and 2% is figuring out the new position/rotation/opacity/whatever values, even if you calculated them 10 times faster, you’d only see about a 1% speed boost overall.

Performance comparison

The stress test below creates a certain number of image elements (dots) and animates them from the center to random positions around the edges using random delays, creating a starfield effect. Crank up the number of dots and see how jQuery, GSAP, and Zepto compare. Since Zepto uses CSS transitions for all of its animations, it should perform best, right?

The results confirm what is widely reported on the web – CSS animations are significantly faster thanjQuery. However, on most devices and browsers I tested, the JavaScript-based GSAP performed even better than CSS animations (by a wide margin in some cases, like on the Microsoft Surface RT GSAP was probably at least 5 times faster than the CSS transitions created by Zepto, and on the iPad 3 iOS7 transforms were significantly faster when animated with GSAP instead of CSS transitions):

Animated properties Better w/JavaScript Better w/CSS
top, left, width, height Windows Surface RT, iPhone, iPad, iPad, Samsung Galaxy Tab, Chrome, Firefox, Safari, Opera, Kindle Fire HD, IE (none)
transforms (translate/scale) Windows Surface RT, iPhone, iPad, Samsung Galaxy Tab, Firefox, Opera, IE iPad, Safari, Chrome
Exactly how much “better”? The original version of the test had a frames-per-second counter for quantifiable results, but it quickly became apparent that there’s no truly accurate way to measure FPS across browsers especially with CSS animations, and certain browsers were reporting misleading numbers, so I removed it. You can easily gauge relative performance, though, by cranking up the number of dots, switching among engines, and watching how things perform (smooth movement, steady timing and dot dispersion, etc.). After all, the goal is to have animations look good.

Interesting things to note:

  • When animating top/left/width/height (properties that affect document flow), JavaScript was faster across the board (GSAP, not jQuery).
  • A few devices seemed highly optimized for transforms whereas others handled top/left/width/height animations better. Most notably, the older iOS6 was much better with CSS-animated transforms, but the newer iOS7 flip-flopped and now they are significantly slower.
  • There’s a substantial lag in the initial animation startup with CSS animations as the browser calculates layers and uploads the data to the GPU. This also applies to JavaScript-based 3D transforms, so “GPU acceleration” doesn’t come without its own costs.
  • Under heavy pressure, CSS transitions were more likely to spray out in bands/rings (this appears to be a synchronization/scheduling issue, possibly due to them being managed in a different thread).
  • In some browsers (like Chrome), when there were a very high number of dots animating, it completely killed the opacity fade of the text, but only when using CSS animations!

Although well-optimized JavaScript is often just as fast if not faster than CSS animations, 3D transforms do tend to be faster when animated with CSS, but that has a lot to do with the way browsers handle 16-element matrices today (forcing conversion from numbers to a concatenated string and back to numbers). Hopefully that’ll change, though. In most real-world projects, you’d never notice the performance difference anyway.

I’d encourage you to do your own testing to see which technology delivers the smoothest animation in your particular project(s). Don’t buy the myth that CSS animations are always faster, and also don’t assume that the speed test above reflects what you’d see in your apps. Test, test, test.

Runtime controls and events

Some browsers allow you to pause/resume a CSS keyframes animation, but that’s about it. You cannot seek to a particular spot in the animation, nor can you smoothly reverse part-way through or alter the time scale or add callbacks at certain spots or bind them to a rich set of playback events. JavaScript provides great control, as seen in the demo below.

Modern animation is very much tied to interactivity, so it’s incredibly useful to be able to animate from variable starting values to variable ending ones (maybe based on where the user clicks, for example), or change things on-the-fly but declarative CSS-based animation can’t do that.

Workflow

For simple transitions between two states (i.e. rollovers or expanding menus, etc.), CSS Transitions are great. For sequencing things, however, you generally need to use CSS keyframe animations which force you to define things in percentages, like:

@keyframes myAnimation {
  0% {
    opacity: 0;
    transform: translate(0, 0);
  }
  30% {
    opacity: 1;
    transform: translate(0, 0);
  }
  60% {
    transform: translate(100px, 0);
  }
  100% {
    transform: translate(100px, 100px);
  }
}
#box {
   animation: myAnimation 2.75s;
}

But when you’re animating, don’t you think in terms of time rather than percentages? Like “fade up the opacity for 1 second, then slide to the right for 0.75 seconds, and bounce down to a rest 1 second later”. What happens if you spend hours crafting a complicated sequence in percentages, and then the client says “make that part in the middle 3 seconds longer”? Ouch. You’d need to recalculate ALL of the percentages!

Usually building animations involves a lot of experimentation, especially with timing and eases. This is actually where a seek() method would be quite useful. Imagine building out a 60-second animation piece-by-piece and then finessing the final 5 seconds; you would need to sit through the first 55 seconds every time you want to see the results of your edits to the last parts. Yuck. With aseek() method, you could just drop that into place during production to skip to the part you’re working on, and then remove it when you’re done. Big time-saver.

It is becoming increasingly common to animate canvas-based objects and other 3rd-party library objects but unfortunately CSS animations can only target DOM elements. That means that if you invest a lot of time and energy in CSS animations, it won’t translate to those other types of projects. You’ll have to switch animation tool sets.

There are a few more workflow-related conveniences that are missing in CSS Animations:

  • Relative values. Like “animate the rotation 30 degrees more” or “move the element down 100px from where it is when the animation starts”.
  • Nesting. Imagine being able to create animations that can get nested into another animation which itself can be nested, etc. Imagine controlling that master animation while everything remains perfectly synchronized. This structure would promote modularized code that is much easier to produce and maintain.
  • Progress reporting. Is a particular animation finished? If not, exactly where is it at in terms of its progress?
  • Targeted kills. Sometimes it’s incredibly useful to kill all animations that are affecting the “scale” of an element (or whatever properties you want), while allowing the rest to continue.
  • Concise code. CSS keyframe animations are verbose even if you don’t factor in all the redundant vendor-prefixed versions necessary. Anyone who has tried building something even moderately complex will attest to the fact that CSS animations quickly get cumbersome and unwieldy. In fact, the sheer volume of CSS necessary to accomplish animation tasks can exceed the weight of a JavaScript library (which is easier to cache and reuse across many animations).

Limited effects

You can’t really do any of the following with CSS animations:

  • Animate along a curve (like a Bezier path).
  • Use interesting eases like elastic or bounce or a rough ease. There’s a cubic-bezier()option, but it only allows 2 control points, so it’s pretty limited.
  • Use different eases for different properties in a CSS keyframe animation; eases apply to the whole keyframe.
  • Physics-based motion. For example, the smooth momentum-based flicking and snap-back implemented in this Draggable demo.
  • Animate the scroll position
  • Directional rotation (like “animate to exactly 270 degrees in the shortest direction, clockwise or counter-clockwise”).
  • Animate attributes.

Compatibility

CSS-based animation doesn’t work in IE9 and earlier. Most of us hate supporting older browsers (especially IE), but the reality is that some of us have clients who require that support.

Browser prefixes are necessary for many browsers, but you can leverage preprocessing tools to avoid having to manually write them out.

Conclusion

Are CSS animations “bad”? Certainly not. In fact, they’re great for simple transitions between states (like rollovers) when compatibility with older browsers isn’t required. 3D transforms usually perform very well (iOS7 being a notable exception), and CSS animations can be very attractive for developers who prefer putting all of their animation and presentation logic in the CSS layer. However, JavaScript-based animation delivers far more flexibility, better workflow for complex animations and rich interactivity, and it often performs just as fast (or even faster) than CSS-based animation despite what you may have heard.

When compared to jQuery.animate(), I can understand why CSS Animations were so appealing. Who in their right mind wouldn’t jump at the chance to get a 10-fold performance boost? But it’s no longer a choice between jQuery and CSS Animations; JavaScript-based tools like GSAP open up entirely new possibilities and wipe out the performance gap.

This article isn’t about GSAP or any particular library; the point is that JavaScript-based animation doesn’t deserve a bad reputation. In fact, JavaScript is the only choice for a truly robust, flexible animation system. Plus, I wanted to shed some light on the frustrating parts of CSS animations (which nobody seems to talk about) so that you can ultimately make a more informed decision about how you animate in the browser.

Will the Web Animations spec solve things?

The W3C created a spec called Web Animations that aims to solve a lot of the deficiencies in CSS Animations and CSS Transitions, providing better runtime controls and extra features. It certainly seems like a step forward in many ways, but it still has shortcomings (some of which are probably impossible to overcome due to the need for legacy support of existing CSS specifications, so for example, independent transform component control is unlikely). There are definitely some smart guys who worked on the spec.


Refactoring CSS: The Three I’s

Refactoring CSS: The Three I’s

In a recent interview, I was asked about simple and/or replicable steps to take when refactoring CSS. The topics of legacy, Technical Debt, and refactoring are, for one reason or another, at the front of my mind at the moment, so I thought I would write up a short post on an approach to refactoring CSS (or any language) that I call The Three I’s: Identify, Isolate, Implement.

Identify

It’s all well and good knowing that ‘your CSS is a mess’, but which bits specifically? Which parts of your codebase are causing you problems right now? Which ones will be the quickest to refactor? Which parts will provide you with the most benefit once refactored? It is important to identify prime candidates for refactoring.

For example, the CSS for your nav might be cumbersome and hard to work with, but if the nav works correctly, is accessible, and you rarely have to edit the CSS for it, refactoring it will likely not provide you with much immediate value: we can probably afford to leave it as it is for a little while longer. However, your layout/grid system might be incredibly fragmented and inconsistent, it might have cross-browser issues, its responsiveness may have been bolted on as an afterthought, and of course it is probably used extensively and frequently. As a result, you might get a lot of value from tackling that first.

Have a clear idea of which parts of your project should be refactored, if at all.

Tip: Try to limit refactoring work to the scope of single features. It’s much safer to refactor a single feature than it is to refactor your entire naming convention, for example. For further detail on this, and much more, you can see my Refactoring CSS Without Losing Your Mind talk at a number of events throughout the rest of 2016.

Isolate

Once we have identified candidates for refactoring, we need to isolate them before and during working on them. Suppose we have decided to refactor our layout system first, we should rewrite this in isolation, outside of our project.

In order to do this, open a new jsFiddle, CodePen, etc. and begin work there. Do not refactor features back into a stale codebase, as doing so runs the risk of making use of legacy CSS that may itself be refactored in future. For example, we might be using a traditional reset in the current project, which may be replaced by Normalize.css in future—we don’t want to build our brand new layout system on top of a reset that will be removed in six months time.

Build the new/refactored version of your feature in complete isolation so that you know it is well encapsulated, and it’s not making use of any legacy.

Implement

The final step is to implement your refactored feature. Copy and paste the jsFiddle CSS into the relevant part of your project, and see what happens. 90% of the time, you’ll find that there are some problems: conflicts with existing CSS, naming collisions, existing styles leaking into your new code, etc.

We tackle these details at implementation stage, and we need to give careful consideration as to where we place the fixes. If the fix solves a problem with the layout system itself, it is usually best to place the fix in the layout system’s partial. If the fix addresses problems arising from conflicts with legacy code, it is often best to place it in a shame.css file. This keeps the legacy fix away from greenfield CSS, meaning it will be much easier to remove once we’ve refactored whatever legacy was causing the problem in the first place.

Move the refactored feature back into the project and tidy things up here.

In short:

Identify sensible candidates for refactoring: not all legacy is born equal.
Isolate the feature in order to rebuild it: do not lean on out of date code.
Implement the refactored feature into the project: do any cleanup work at this point, and in the right place(s).


Take a Look as This Incredible Art Made with CSS

Take a Look as This Incredible Art Made with CSS

One thing about web design is that no matter how many intricately-defined standards there are, you can never be sure that whatever you create is going to look the same in all browsers. Even the very latest versions of the most popular browsers have different ways of handling assorted web technologies, which can affect the way your site renders; that’s why cross-platform testing is so important, especially if you’re relying on cutting-edge CSS animation.

While inconsistencies between browsers can be infuriating, every now and then they can throw up something utterly delightful, and here’s one fantastic example: the pure CSS art of Diana Smith. She creates beautiful browser-based art inspired by classic paintings, using only hand-written HTML and CSS; her latest creation, Lace (in the style of Flemish and Baroque works) is a stunning piece.

“Image” Varies Greatly in Different Browsers

This portrait looks different depending on the browser you view it in, because it’s not an “image” at all. It’s pure web code that your browser renders into a drawing every time you load the page.

Take a Look as This Incredible Art Made with HTML & CSS

PureCSS Lace is the latest of digital artist Diana Smith’s code portraits inspired by Flemish baroque oil paintings, joining PureCSS Francine from May 2018. Along with a few retro-inspired posters and a woman in neon-glowing profile, the pieces are created from code, instead of embedded .jpg image files that look the same no matter how you view them.

So, you can’t save Lace or Francine—you could screenshot them, but that would ruin what makes them so unique—but you can distort them into some pretty wacky versions of themselves, depending on the browser it’s rendered within.

“Because of the artistic nature of this project I have not concerned myself with cross-browser-compatibility, so the live preview will most likely look laughable in anything other than chrome,” Smith wrote in the GitHub repository where each of her projects and their source code is stored.

Motherboard loaded Lace up in several different browsers. The results were definitely laughable, yet still weirdly artful.

These are all screenshots of PureCSS Lace rendered in different browsers, so they’ll look the same in your browser no matter which you use, while showing off how different browsers transform the work.

Safari, for some reason, renders the lace frills of Lace to the front.

 

safari
 

Things get weirder—and more Cubist—in a version of Opera from 2014.

opera
 

Ironically, Microsoft Edge takes all the edges off.

edge
 

Netscape Navigator looks like it was created in Microsoft Paint—appropriate, as both ruled the 90s.

nav
 

“When you look at this image on different browsers, you’re kind of looking at the history of the internet and what was demanded of it at the time,” Smith told Motherboard.

But experimenting with different browsers also reveals a hint of the future: A ton of browsers these days are running Chromium, Google’s open-source browser code. Whereas Pure CSS Lace might have shown off how every browser is unique in the past, it now looks exactly the same on Chrome, Vivaldi, Brave, and Opera.


10 Best CSS Trends 2019

10 Best CSS Trends 2019

As time goes on, web design is getting more innovative. Rather than just displaying information, websites are works of art, featuring complex animations, unique layouts, and micro-interactions. So many of these things are possible through CSS. CSS gives style to normal, boring web pages, and enables everything that makes websites enjoyable to interact with. 2019 brings with it plenty of new horizons for web design, and these are the 10 best CSS trends that will define the year.

1. Mobile First

Of all the CSS trends, the most current and continuing to grow CSS “sentiment” is towards Mobile First. Historically, web designers have developed web applications for computers first, and then added responsive web design to make sure the web looks good when viewed on a tablet or a phone. This CSS trend is shifting towards designing for mobiles first, and then add responsive design to make a site work on desktops and laptops.

50/50 is an easy way to achieve web design for responsive webs. With 50/50 design, the screen can show two pages on large screens and one page on narrow screens.

2. Cards

Most typical cards are rectangles with an image and some text. Cards have become a common structure for organizing headlines, images, and text on an equal plane. Cards can be small or large, with or without pictures, and with or without shadows. One of the most notable CSS trends and ubiquitous examples is Google Feed cards.

3. CSS Grid

CSS Grid Generator

Take a Look: CSS Grid Generator

The prevailing standard for grid-based layouts has been Flexbox. In fact, at its height at the end of 2018, nearly 83% of page loads on Chrome used Flexbox. But a new contender has entered the ring.

That new contender is Grid. Still young and only seeing use on about 2.25% of page loads, it has still skyrocketed in popularity, only representing 0.25% of page loads at the start of 2018.

Grid is being hailed as better than Flexbox. Flexbox gives you control of vertical or horizontal alignment, but not both at once. Grid, on the other hand, does.

CSS experts attribute the lack of popularity to the fact that most major websites are not using it. After all, that data above is based on page views, not the raw number of pages that use Grid. It was only fairly recently that major sites adopted Flexbox, so it makes sense that they don’t want to make the switch just yet.

2019 will definitely see the growth of Grid, however, because it unlocks a degree of creative freedom that other options do not offer.

4. CSS Writing Mode

Example of CSS Writing Mode

Not all languages are written and read from left to right. For languages that go in other directions, you can use the writing-mode CSS property.

Flow text from top to bottom or from right to left and adjust the horizontal and vertical values. You can even display text sideways vertically, rotate the text for certain designs, and mix scripts.

5. Mobile Animations

Animations as a tool for engagement are increasingly popular. Websites will start to use more and more animated loading icons, page loads with limited design, etc. to keep the user’s attention.

An example of this from a popular website is YouTube. Open the YouTube mobile app and scroll through the videos. If you stop for a second, the video will autoplay with the sound off and show captions.

Animations are also used as indicators for an action or a task. Animated buttons and lists are becoming common too. You read all about using CSS animations from Mozilla.

6. Popular Frameworks (Bulma, Tailwind, Bootstrap 4, etc.)

Foundation CSS Framework

CSS frameworks have been around for a while, but they’ve only been growing in popularity in recent years. If you need a primer on what a framework is, read this.

Awwwards defines a framework as:

“A framework is a standardized set of concepts, practices and criteria for dealing with a common type of problem, which can be used as a reference to help us approach and resolve new problems of a similar nature.”

As we move to a more mobile web, frameworks are adjusting to compensate. Styling and design are changing, animations and action are becoming more common, and a focus on simplicity and end user experience are more important than ever!

In 2019, many well designed frameworks are taking the lead and helping developers and designers to ship faster than ever. A few of the most notable frameworks being used around the web in 2019 are:

  • Foundation – Responsive, mobile-first framework and used as enterprise solution;
  • Bootstrap 4 – Bootstrap is one of the biggest CSS frameworks used worldwide, version 4 comes with new features for color schemes and utility classes;
  • Materialize – Popular framework focused on material design styles;

Read more about the top CSS frameworks 2019 on Scotch.io.

7. Single Pages, Experimental Navigations

Carrd single page website builder.

With websites becoming almost as synonymous as having your own profile on social networks, more users are turning to simpler solutions and single page options to send traffic out to other locations.

Common examples include:

  • Linktree – Simple page with links to your socials, products, etc.;
  • Carrd – Simple, free, fully responsive one-page sites for pretty much anything;
  • About.me – More professional focused portfolio site, similar to LinkedIn but with room for creativity;
  • Instapage – Top landing page builder for businesses and startups;

These single page websites are being taken further with the creative use of CSS and styling to enhance the experience. The Next Web highlighted ‘large and experimental navigations’ as one of their ‘10 exciting web design trends you can’t hide from in 2019’. So why are people moving to these interesting layouts?

Because of action. With the focused large buttons and navigation, users immediately click to the desired location. Whether that be a shop, informational page with hours/details, or just a new video/song.

More and more websites are simply set up as directing points for companies, individuals, or groups to send traffic to and then distribute out. Musicians use Linktree and other services to share their new songs on all streaming platforms, and get a cut of the affiliate revenue in the meantime.

8. Variable Fonts

Google's 'Introduction to variable fonts on the web'.

Highlighted by Carrie Cousins for Designmodo’s ‘Top 17 Web Design and UI Trends 2019’, variable fonts are defined as “a collection of master styles, with one central ‘default’ master (usually the Regular font style) and multiple registered “axes” which tie the central master to the other masters. For example, the Weight axis might connect a Light style master to the default style and through to the Bold style master. The individual styles that can be located along this axis are called “instances”.

What this means is that fonts are more responsive and seamless across devices and platforms. You can scale the width, sizing, and other aspects of the font more easily without jumping from font weight to font weight or switching fonts entirely.

Check out an example of the variable typeface ‘Amstelvar’ on GitHub. Also read the full analysis on variable fonts and how they will change the web from Google.

9. Scroll Snapping

'Practical CSS Scroll Snapping' from CSS Tricks.

Scroll snapping is one of the relatively new CSS trends, and is a technique used for snapping users to certain scroll points. Rather than a fluid motion down the page or left to right, you can have the page scroll in increments. Popular uses of this are for swiping through products or details on a page, scrolling through a book/reading experience, and sliding down a page with incremental blocks of information.

CSS Tricks features a great guide on Practical CSS Scroll Snapping.

The guide features information on browser support, best practices, and the properties you should use to ensure your scroll snapping works as intended.

Want to see how scroll snapping works? Check out these examples on Webkit.

10. Full Screen Input

Last but not least of the CSS trends is the use of full screen inputs. More and more sites are using full screen for inputs like signups and logins, instead of using only a small part of the page. Full screen often uses a screen overlay or modal instead of redirecting to a new page.

If you enjoyed this article regarding the best CSS trends 2019 and want even more CSS info check out our other CSS Guides.