This is a very quick tip, about a pet peeve of mine in almost every CSS animation I see. As you may know, I’m a sucker for reducing the amount of code (as long as it remains human readable of course). I demonstrated a very similar example in my “CSS in the 4th dimension” talk, but I recently realized I never blogged about it (or seen anyone else do so).

Lets assume you have a simple animation of a pounding heart, like so:

@keyframes pound {
	from { transform: none; }
	50% { transform: scale(1.4); }
	to { transform: none; }
}

.heart {
	/* ... */
	animation: pound .5s infinite;
}

You can see the problem already: the shrunk heart state is repeated twice in the keyframes (from and to). You probably know you can combine them into one rule, like so:

@keyframes pound {
	from, to { transform: none; }
	50% { transform: scale(1.4); }
}

What many don’t know, is that you don’t need these two keyframes at all, since they basically replicate the same state as the one in the .heart rule. To quote the CSS Animations spec:

If a 0% or “from” keyframe is not specified, then the user agent constructs a 0% keyframe using the computed values of the properties being animated. If a 100% or “to” keyframe is not specified, then the user agent constructs a 100% keyframe using the computed values of the properties being animated.

Therefore, the code could actually be as simple as:

@keyframes pound {
	50% { transform: scale(1.4); }
}

This trick is very useful for providing fallbacks that are the same as the first or last keyframe, without having to repeat them in the @keyframes rule. Of course it doesn’t only apply to animations where you only have one keyframe beyond from and/or to. You can omit the from and to keyframes in every animation, when you want them to be the same as the styles that are applied to the element anyway.

Of course, to make this particular animation appear more natural, it would be much more wise to do something like this, still with only one keyframe (the from state is dynamically generated by the browser):

@keyframes pound {
	to { transform: scale(1.4); }
}

.heart {
	/* ... */
	animation: pound .25s infinite alternate;
}

which just reverses every even iteration, instead of trying to have both states (shrinking and growing) in the animation. The reason this looks more natural is that animation-direction: alternate; (which is what the alternate keyword does in the animation shorthand) also reverses the timing (easing) function for the reversed iterations. ;)

This is a very quick tip, about a pet peeve of mine in almost every CSS animation I see. As you may know, I’m a sucker for reducing the amount of code (as long as it remains human readable of course). I demonstrated a very similar example in my “CSS in the 4th dimension” talk, but I recently realized I never blogged about it (or seen anyone else do so).

Lets assume you have a simple animation of a pounding heart, like so:

@keyframes pound {
	from { transform: none; }
	50% { transform: scale(1.4); }
	to { transform: none; }
}

.heart {
	/* ... */
	animation: pound .5s infinite;
}

You can see the problem already: the shrunk heart state is repeated twice in the keyframes (from and to). You probably know you can combine them into one rule, like so:

@keyframes pound {
	from, to { transform: none; }
	50% { transform: scale(1.4); }
}

What many don’t know, is that you don’t need these two keyframes at all, since they basically replicate the same state as the one in the .heart rule. To quote the CSS Animations spec:

If a 0% or “from” keyframe is not specified, then the user agent constructs a 0% keyframe using the computed values of the properties being animated. If a 100% or “to” keyframe is not specified, then the user agent constructs a 100% keyframe using the computed values of the properties being animated.

Therefore, the code could actually be as simple as:

@keyframes pound {
	50% { transform: scale(1.4); }
}

This trick is very useful for providing fallbacks that are the same as the first or last keyframe, without having to repeat them in the @keyframes rule. Of course it doesn’t only apply to animations where you only have one keyframe beyond from and/or to. You can omit the from and to keyframes in every animation, when you want them to be the same as the styles that are applied to the element anyway.

Of course, to make this particular animation appear more natural, it would be much more wise to do something like this, still with only one keyframe (the from state is dynamically generated by the browser):

@keyframes pound {
	to { transform: scale(1.4); }
}

.heart {
	/* ... */
	animation: pound .25s infinite alternate;
}

which just reverses every even iteration, instead of trying to have both states (shrinking and growing) in the animation. The reason this looks more natural is that animation-direction: alternate; (which is what the alternate keyword does in the animation shorthand) also reverses the timing (easing) function for the reversed iterations. ;)

I posted about this in both the WebPlatform.org blog and Dabblet’s blog, but I thought it might be interesting to many readers of this blog as well:

As many of you probably know, I’ve started working for W3C Developer Relations since this August. Half of my time is devoted to WebPlatform.org, a very promising project to document the web with the help of all major players, in a vendor-neutral way. Even before I joined W3C, we discussed using a hosted, customized version of dabblet in WebPlatform.org, as a platform for live code examples. I recently started working towards making this happen.

A lot of changes and improvements need to be made to achieve this, but the good news is, most of these will be pushed to dabblet.com as well! In a nutshell, this is what I’m currently working on:

• Adding JavaScript support — This will be a challenge UX-wise, as it shouldn’t run on every keystroke, like the HTML and CSS, but it should run on startup and it should be straight-forward how to get it to run. Perhaps it will also run after a significant pause in typing.
• Dabblets that are not stored in Github, but get their data through POST requests.
• Improving cross-browser support
• Strengthening security
• Integrating Prism. Dabblet’s syntax highlighter might have been Prism’s precursor, but currently Prism has solved many of its bugs, and these fixes need to be pushed to dabblet at some point.
• General bug fixing

These will probably be gradually rolled out in dabblet.com and tested by the community, before we integrate dabblet into WebPlatform.org. If a new feature is significant enough, there will be a new blog post about it here, but don’t expect blog posts about bugfixes. I’m really excited to see dabblet flourish, and I believe you will be too, once these updates are out!

I posted about this in both the WebPlatform.org blog and Dabblet’s blog, but I thought it might be interesting to many readers of this blog as well:

As many of you probably know, I’ve started working for W3C Developer Relations since this August. Half of my time is devoted to WebPlatform.org, a very promising project to document the web with the help of all major players, in a vendor-neutral way. Even before I joined W3C, we discussed using a hosted, customized version of dabblet in WebPlatform.org, as a platform for live code examples. I recently started working towards making this happen.

A lot of changes and improvements need to be made to achieve this, but the good news is, most of these will be pushed to dabblet.com as well! In a nutshell, this is what I’m currently working on:

• Adding JavaScript support — This will be a challenge UX-wise, as it shouldn’t run on every keystroke, like the HTML and CSS, but it should run on startup and it should be straight-forward how to get it to run. Perhaps it will also run after a significant pause in typing.
• Dabblets that are not stored in Github, but get their data through POST requests.
• Improving cross-browser support
• Strengthening security
• Integrating Prism. Dabblet’s syntax highlighter might have been Prism’s precursor, but currently Prism has solved many of its bugs, and these fixes need to be pushed to dabblet at some point.
• General bug fixing

These will probably be gradually rolled out in dabblet.com and tested by the community, before we integrate dabblet into WebPlatform.org. If a new feature is significant enough, there will be a new blog post about it here, but don’t expect blog posts about bugfixes. I’m really excited to see dabblet flourish, and I believe you will be too, once these updates are out!

I was always interested in accessibility, but I never had to comply with any guidelines before. At W3C, accessibility is considered very important, so everything we make needs to pass WCAG 2.0 AA level. Therefore, I found myself calculating color contrast ratios very frequently. It was a very enlightening experience. I used to think that WCAG-mandated contrast ratios were too restrictive and basically tried to force you to use black and white, a sentiment shared by many designers I’ve spoken to. Surprisingly, in practice, I found that in most cases they are very reasonable: When a color combination doesn’t pass WCAG, it usually *is* hard to read. After all, the possible range for a contrast ratio is 1-21 but only ratios lower than 3 don’t pass WCAG AA (4.5 if you have smaller, non-bold text). So, effectively 90% of combinations will pass (82.5% for smaller, non-bold text).

There are plenty of tools out there for this. However, I found that my workflow for checking a contrast ratio with them was far from ideal. I had to convert my CSS colors to hex notation (which I don’t often use myself anymore), check the contrast ratio, then adjust the colors as necessary, covert again etc. In addition, I had to adjust the lightness of the colors with a blindfold, without being able to see the difference my adjustments would make to the contrast ratio. When using semi-transparent colors, it was even worse: Since WCAG only describes an algorithm for opaque colors, all contrast tools only expect that. So, I had to calculate the resulting opaque colors after alpha blending had taken place. After doing that for a few days, I got so fed up that I decided to make my own tool.

In addition, I discovered that there was no documented way of calculating the contrast ratio range that can be produced with a semi-transparent background, so I came up with an algorithm (after many successive failures to find the range intuitively), published it in the w3c-wai-ig mailing list and used the algorithm in my app, effectively making it the first one that can accept semi-transparent colors. If your math is less rusty than mine, I’d appreciate any feedback on my reasoning there.

Below is a list of features that make this tool unique for calculating color contrast ratios:

• Accepts any CSS color the browser does, not just hex colors. To do this, it defers parsing of the color to the browser, and queries the computed style, which is always rgb() or rgba() with 0-255 ranges which be parsed much more easily than the multitude of different formats than modern browsers accept (and the even more that are coming in the future).
• Updates as you type, when what you’ve typed can be parsed as a valid CSS color.
• Accepts semi transparent colors. For semi-transparent backgrounds, the contrast ratio is presented with an error margin, since it can vary depending on the backdrop. In that case, the result circle will not have a solid background, but a visualization of the different possible results and their likelihood (see screenshot).
• You can share your results by sharing the URL. The URL hashes have a reasonable structure of the form #foreground-on-background, e.g. #black-on-yellow so you can even adjust the URL as a form of input.
• You can adjust the color by incrementing or decrementing its components with the keyboard arrow keys until you get the contrast right. This is achieved by including my Incrementable library.

Browser support is IE10 and modern versions of Firefox, Safari, Chrome, Opera. Basic support for IE9. No responsive version yet, sorry (but you can always send pull requests!)

Save the link: contrast-ratio.com

Edit 2022: Link updated to reflect current one. Original link was leaverou.github.com/contrast-ratio