Web Standards

The $1,000 Podcasting Setup

Css Tricks - Sun, 06/18/2017 - 12:18am

I figure between (as I write) the 267 episodes of ShopTalk, 134 episodes of CodePen Radio, 154 video screencasts (and many hundreds more as part of the different series), and all my guest podcast apperances, I'm edging on 1,000 things I've voice-recorded for public consumption.

98% of that was with the Rode Podcaster, the same exact microphone I documented using in 2008. I figured it was about time for an upgrade, as I plan to continue podcasting and screencasting for another 10 years! I know audio quality is a big deal. I don't quite consider myself an audiophile, but I know I prefer listening to podcasts with good audio quality, and I'd like to make sure what I produce is as good of quality as is practical for me right now.

I had our podcast editor Chris Enns on ShopTalk to talk gear'n'stuff, and this setup is largely his recommendations. A good part of the beauty of this setup is that it's designed around making it sound like you're in an amazing studio, without actually having to be.

Shure SM7B ($399) Pictured here with the big alternate big fluffy cover that it ships with, which is helpful for minimizing breathing noises and pop filtering.

As Shure says, the SM7B has:

flat, wide-range frequency response for exceptionally clean and natural reproduction of both music and speech.

It's a pretty dang good microphone. (Chris Enns also recommended the Heil PR 40, which is in the same range.) On my desk, I have a Swivel Mount Boom Arm to put it on, so I can swing it into place when using it, and swing it away when I'm not.

Like most pretty dang good microphones, it's not "USB". It has an XLR plug, and you'll need an XLR cable to plug it into our next device...

DBX 286s ($196)

Chris Enns described DBX 286s to me as a sound sweetener.

It's an optional bit, but plugging the microphone into this first does a bunch of nice stuff for you. It's a big part of the "sound like your in a nice studio when you aren't" situation.

It looks kind of scary, since there are a whole bunch of knobs and buttons on it and they all actually do things. I found setup videos like this helpful:

The DBX 286x outputs in a 1/4" cable, so you'll need a XLR Male to 1/4" Male to plug it into...

Focusrite Scarlett 2i4 ($189)

This is the device that you actually plugin into your computer via USB. Your computer will recognize it as a sound input device.

The Focusrite Scarlett comes in a variety of models, mostly differentiated by how many inputs it has. If you know you'll only ever need one input, the Solo model has you covered at $99. I went for the 2i4 model which has two microphone inputs and four instrument inputs, just in case I want to do something a bit more robust with it at some point. Even just having a second podcast guest in the same vicinity, you could pipe them into one computer and get separate tracks, which is cool.

With the DBX 286s, you won't need any gain from the Focusrite Scarlett, but if you skip the DBX 286s (which you totally can), you will.

Setup

On my desk, I have it all stacked up like this:

That's Shure SM7B > DBX 286s > Scarlett Focusrite > Computer.

Then I use Audio Hijack Pro to record, so I can get the mono-audio recorded on both left and right channels properly.

All Together

Here's an Amazon List with it all there, if you're interested in the same kind of setup.

The $1,000 Podcasting Setup is a post from CSS-Tricks

Handling Long and Unexpected Content in CSS

Css Tricks - Thu, 06/15/2017 - 9:20pm

When we write CSS, sometimes we forget about some edge cases in the designs. For example, when the content is longer than we expected and we didn't account for that possibility, our design could break. We can't guarantee that our CSS will always work as expected, but at least we can reduce that by testing different types of content.

When you code CSS, you're writing abstract rules to take unknown content and organize it in an unknown medium. - Keith J. Grant

In this article, we will go through different UI bugs from real-world websites so we can account for them from the beginning. Ready? Let's go!

A button with an icon placed on the right/left side

This is a toggle button for an accordion. There is an icon on the right side to emphasize that it is clickable. However, when the area is not big enough, the text will overlap the icon. This might happen when we don't account for long content.

A solution would be to add an enough padding to the right side to accommodate for the size of the icon:

.button { padding-right: 50px; }

Notice how increasing the padding creates a safe area for the icon. Now we can be sure that it won't break if the text gets longer.

See the Pen A button with an icon by Ahmad Shadeed (@shadeed) on CodePen.

Input Placeholder

When applying the float label pattern for our forms, especially with a button on the right side. We should test this thoroughly to avoid any issues when the label is too long.

A solution would be to add position: relative for the button. This will move it above the label.

See the Pen Long placeholder by Ahmad Shadeed (@shadeed) on CodePen.

Long Names

In this design, the image is floated to the left and we have an author name on the right. What happens when the name is longer than expected? The UI will break.

The issue there is that we only floated the image to the left side. This might cause the author name to move beside it. However, this will only work if the name is not long.

To make it more robust, we should float the author image and add overflow: hidden to the author name wrapper. That way, we will get the advantage of block-formatting context (Thanks to Thierry Koblentz for pointing this out in the comments). Or, another solution, use flexbox since it's suitable for that small component.

See the Pen Long person name by Ahmad Shadeed (@shadeed) on CodePen.

Long links/words inside an article body

Sometimes there are long links or words in an article. This might not cause an issue with a very wide viewport. But for smaller sizes like mobile or tablet, this will cause a horizontal scrolling and it will be annoying.

We have two solutions for such an issue:

1) Use CSS word-break .article-body p { word-break: break-all; }

Please test well when using word-break since it has some differences between browsers. We recommend you to read this article on the topic.

2) Add overflow to the wrapper element and text-overflow to the links .article-body p { overflow: hidden; text-overflow: ellipsis; }

This solution is safer and better for links. But for words, I would use word-break.

See the Pen Long links / words by Ahmad Shadeed (@shadeed) on CodePen.

Long article tags

When we place an article tag over a card, we should only add padding for the spacing. Determining width and height might make the UI break when the tag content is too long.

If you want to have a minimum width for the tag, that's fine. We can use min-width with padding around the tag content. That way, the width will be dynamic and the issue will be solved.

See the Pen Long Article Tags by CSS-Tricks (@css-tricks) on CodePen.

Section header with a link

In this example, we have a section title along with a "view more" link on the right. There are different ways to code this in CSS, one of them is using absolute positioning for the link.

This will cause issues in case the title was too long. A better solution could be to use flexbox. That way, it will automatically push the link to a new line when there is no enough space.

.header-2 { display: flex; flex-wrap: wrap; justify-content: space-between; align-items: center; }

The above technique is called "Alignment Shifting Wrapping". I learned about it two years ago from this article.

See the Pen Section header with a link by Ahmad Shadeed (@shadeed) on CodePen.

Conclusion

I learned the hard way that using dummy content or simply adding things randomly is not enough. We should add all types of content to our layouts until something breaks. I like to use Heydon Pickering's forceFeed.js for adding content randomly to a specific component.

Handling Long and Unexpected Content in CSS is a post from CSS-Tricks

How the minmax() Function Works

Css Tricks - Thu, 06/15/2017 - 9:18pm

Another swell post by Ire Aderinokun, this time on the curious minmax() CSS function and how it works alongside the CSS Grid features that we've been experimenting with lately.

What's especially great here is the examples where Ire explains how we can avoid media queries altogether. With just a couple of lines of CSS we can now build pretty complicated layouts.

Direct Link to ArticlePermalink

How the minmax() Function Works is a post from CSS-Tricks

Free Guide to Using cPanel & WordPress?

Css Tricks - Wed, 06/14/2017 - 9:05pm

Managed WordPress hosting is a great choice if you need a hosting solution that's optimized for WordPress. But it's only for WordPress.

What if you need more?

What if you need email hosting? What if you need to run other software alongside WordPress? What if you need more control than what managed WordPress hosting allows, but without the complexity of a VPS?

There's an easy solution: host everything in one place, and manage it all with the powerful cPanel dashboard.

You'll learn how in this free guide to cPanel & WordPress.

Direct Link to ArticlePermalink

Free Guide to Using cPanel & WordPress? is a post from CSS-Tricks

Using Mixins in Vue.js

Css Tricks - Wed, 06/14/2017 - 8:48pm

It's a common situation: you have two components that are pretty similar, they share the same basic functionality, but there's enough that's different about each of them that you come to a crossroads: do I split this component into two different components? Or do I keep one component, but create enough variance with props that I can alter each one?

Neither of these solutions is perfect: if you split it into two components, you run the risk of having to update it in two places if the functionality ever changes, defeating DRY premises. On the other hand, too many props can get really messy very quickly, and force the maintainer, even if it's yourself, to understand a lot of context in order to use it, which can slow you down.

Enter mixins. Mixins in Vue are useful for writing in a functional style because ultimately, functional programming is about making code understandable by reducing moving parts. (There's a great quote by Michael Feathers about this). A mixin allows you to encapsulate one piece of functionality so that you can use it in different components throughout the application. If written correctly, they are pure- they don't modify or change things outside of the function's scope, so you will reliably always receive the same value with the same inputs on multiple executions. This can be really powerful.

Basic example

Let's say we have a couple of different components whose job it is to toggle a state boolean, a modal and a tooltip. These tooltips and modals don't have a lot in common except for that functionality: they don't look the same, they're not used the same, but the logic is similar.

//modal const Modal = { template: '#modal', data() { return { isShowing: false } }, methods: { toggleShow() { this.isShowing = !this.isShowing; } }, components: { appChild: Child } } //tooltip const Tooltip = { template: '#tooltip', data() { return { isShowing: false } }, methods: { toggleShow() { this.isShowing = !this.isShowing; } }, components: { appChild: Child } }

We could extract the logic here and create something that can be reused:

const toggle = { data() { return { isShowing: false } }, methods: { toggleShow() { this.isShowing = !this.isShowing; } } } const Modal = { template: '#modal', mixins: [toggle], components: { appChild: Child } }; const Tooltip = { template: '#tooltip', mixins: [toggle], components: { appChild: Child } };

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

This example was intentionally kept small and simple for purposes of legibility- examples of mixins I've found useful in real life applications are included but not limited to: getting dimensions of the viewport and component, gathering specific mousemove events, and base elements of charts. Paul Pflugradt has a nice repo of Vue Mixins, but it's worth mentioning that they're written in coffeescript.

Usage

This Pen doesn't really show how we would set this up in a real application, so let's look at that next.

You can set up your directory structure any way that you like, but I like to create a mixin directory in order to stay organized. The file we'd create would have a .js extension (as opposed to .vue, like our other files), and we'd export an object for the mixin:

And then in Modal.vue we would now have access to it by importing the toggle like this:

import Child from './Child' import { toggle } from './mixins/toggle' export default { name: 'modal', mixins: [toggle], components: { appChild: Child } }

It's important to understand that even though we're using an object and not a component, lifecycle methods are still available to us. We could hook into mounted() here and it would be applied to the component's lifecycle, which makes this way of working really flexible and powerful.

Merging

Looking at the last example, we can see that not only do we have our functionality, but also lifecycle hooks available to us from the mixin, so when applying it to a component with overlapping processes, ordering matters. By default, mixins will be applied first, and the component will be applied second so that we can override it as necessary. The component has the last say. This only really becomes important when there is a conflict and the component has to "decide" which one wins out, otherwise everything will be placed in an array to execute and the mixin will be pushed first, the component second.

//mixin const hi = { mounted() { console.log('hello from mixin!') } } //vue instance or component new Vue({ el: '#app', mixins: [hi], mounted() { console.log('hello from Vue instance!') } }); //Output in console > hello from mixin! > hello from Vue instance!

If the two conflict, we can see how the Vue instance or component will win:

//mixin const hi = { methods: { sayHello: function() { console.log('hello from mixin!') } }, mounted() { this.sayHello() } } //vue instance or component new Vue({ el: '#app', mixins: [hi], methods: { sayHello: function() { console.log('hello from Vue instance!') } }, mounted() { this.sayHello() } }) // Output in console > hello from Vue instance! > hello from Vue instance!

You may notice that we have two console.logs for the Vue instance string instead of one here- that's because the first function that was called wasn't destroyed, it was overridden. We're still calling both of the sayHello() functions here.

Global Mixins

When we use the term global in reference to mixins, we are not referring to being able to access them on every component, like we are with something like filters. We can already access our mixins in a component with mixins: [toggle].

Global mixins are literally applied to every single component. For this reason, the use case for them is extremely limited and they should be considered with great caution. One use I can think of that makes sense is something like a plugin, where you may need to gain access to everything. But again, even in this instance, I would be wary about what you're applying, especially when you're extending functionality to applications that might be a black box for you.

To create a global instance, we would place it above the Vue instance. In a typical Vue-cli build, this would go in your main.js file.

Vue.mixin({ mounted() { console.log('hello from mixin!') } }) new Vue({ ... })

Again, use this with caution! That console.log would now appear in every single component. This isn't so bad in this case (aside from all the noise in the console) but you can see how potentially harmful that could be if used incorrectly.

Conclusion

Mixins can be useful to encapsulate a small piece of functionality that you'd like to reuse. They are certainly not the only option available to you: higher order components, for example, allow you to compose similar functionality, this is just one way of working. I like mixins because we're not having to pass state around, but this pattern can certainly be abused as well, so take care to think through which option makes the most sense for your application.

Using Mixins in Vue.js is a post from CSS-Tricks

How To Build An In-House UX Team

Usability Geek - Wed, 06/14/2017 - 12:26pm
The needs of real users are increasingly driving enterprise software design and development. Since 2013, IBM has hired close to 1500 designers and UXers, establishing the largest design studio...
Categories: Web Standards

Introduction to Webpack: Entry, Output, Loaders, and Plugins

Css Tricks - Wed, 06/14/2017 - 12:36am

Front-end development has shifted to a modular approach, improving the encapsulation and structure of codebases. Tooling became a critical part of any project, and right now there are a lot of possible choices.

Webpack has gained popularity in the last years because of its power and scalability, but some developers found its configuration process confusing and hard to adopt.

We'll go step by step from an empty configuration file to a simple but complete setup to bundle a project. This article assumes basic understanding of CommonJS notation and how modules work.

Concepts

Unlike most bundlers out there, the motivation behind Webpack is to gather all your dependencies (not just code, but other assets as well) and generate a dependency graph.

At first, it might look strange to see a `.js` file require a stylesheet, or a stylesheet retrieving an image modified as it was a module, but these allow Webpack to understand what is included in your bundle and helps you transform and optimize them.

Install

Let's first add the initial packages we are going to use:

npm install webpack webpack-dev-server --save-dev

Next we create a `webpack.config.js` file in the root of our project and add two scripts to our `package.json` files for both local development and production release.

"scripts": { "start": "webpack-dev-server", "build": "webpack" }

Webpack commands will pick up the config file we've just created unless we indicate other action.

Entry

There are many ways to specify our "entry point", which will be the root of our dependencies graph.

The easiest one is to pass a string:

var baseConfig = { entry: './src/index.js' };

We could also pass an object in case we need more than one entry in the future.

var baseConfig = { entry: { main: './src/index.js' } };

I recommend the last one since it will scale better as your project grows.

Output

The output in Webpack is an object holding the path where our bundles and assets will go, as well as the name the entries will adopt.

var path = require('path'); var baseConfig = { entry: { main: './src/index.js' }, output: { filename: 'main.js', path: path.resolve('./build') } }; // export configuration module.exports = baseConfig;

If you're defining the entry with an object, rather than hardcoding the output filename with a string, you can do:

output: { filename: '[name].js', path: path.resolve('./build') }

This way when new entries are added Webpack will pick up their key to form the file name.

With just this small set of configurations, we are already able to run a server and develop locally with npm start or npm run build to bundle our code for release. By knowing the dependencies of the project, webpack-dev-server will watch them and reload the site when it detects one of them has changed.

Loaders

The goal of Webpack is to handle all our dependencies.

// index.js file import helpers from '/helpers/main.js'; // Hey Webpack! I will need these styles: import 'main.css';

What's that? Requiring a stylesheet in JavaScript? Yes! But bundlers are only prepared to handle JavaScript dependencies out-of-the-box. This is where "loaders" make their entrance.

Loaders provide an easy way to intercept our dependencies and preprocess them before they get bundled.

var baseConfig = { // ... module: { rules: [ { test: /* RegEx */, use: [ { loader: /* loader name */, query: /* optional config object */ } ] } ] } };

For loaders to work, we need a regular expression to identify the files we want to modify and a string or an array with the loaders we want to use.

Styles

To allow Webpack to process our styles when required we are going to install css and style loaders.

npm install --save-dev css-loader style-loader

The css-loader will interpret styles as dependencies and the style-loader will automatically include a <style> tag with them on the page when the bundle loads.

var baseConfig = { entry: { main: './src/index.js' }, output: { filename: '[name].js', path: path.resolve('./build') }, module: { rules: [ { test: /\.css$/, use: [ { loader: 'style-loader' }, { loader: 'css-loader' } ] } ] } };

In this example, main.css will go first through css-loader and then style-loader.

Preprocessors

Adding support for LESS or any other preprocessor is as simple as installing the corresponding loader and adding it to the rule.

rules: [ { test: /\.less$/, use: [ { loader: 'style-loader' }, { loader: 'css-loader' }, { loader: 'less-loader' } ] } ] Transpiling

JavaScript can be transformed by loaders too. One example would be using a Babel loader to transpile our scripts.

rules: [ { test: /\.js$/, use: [ { loader: 'babel-loader' } ] } ] Images

Webpack has a great feature where it can detect url() statements inside stylesheets and let loaders apply changes to the image file and the url itself.

// index.less file @import 'less/vars'; body { background-color: @background-color; color: @text-color; } .logo { background-image: url('./images/logo.svg'); }

By adding one rule, we could apply the file-loader to just copy the file or use the url-loader, the latest inlines the image as a base64 string unless it exceeds a byte limit, in which case it will replace the url statement with a relative path and copy the file to the output location for us.

{ test: /\.svg$/, use: [ { loader: 'url-loader', query: { limit : 10000 } } ] }

Loaders can be configurable by passing a query object with options, like here where we are configuring the loader to inline the file unless it exceeds 10Kb in size.

Managing our build process this way, we will only include the necessary resources instead of moving a hypothetical assets folder with tons of files that might or might be not used in our project.

If you use React or a similar library you can require the .svg file in your component with the svg-inline-loader.

Plugins

Webpack contains default behaviors to bundle most type of resources. When loaders are not enough, we can use plugins to modify or add capabilities to Webpack.

For example, Webpack by default includes our styles inside our bundle, but we can alter this by introducing a plugin.

Extracting Assets

A common use for a plugin is to extract the generated stylesheet and load it as we normally do using a <link> tag.

var ExtractTextPlugin = require('extract-text-webpack-plugin'); var lessRules = { test: /\.less$/, use: [ { loader: 'style-loader' }, { loader: 'css-loader' }, { loader: 'less-loader' } ] }; var baseConfig = { // ... module: { rules: [ // ... { test: /\.less$/, use: ExtractTextPlugin.extract(lessRules) } ] }, plugins: [ new ExtractTextPlugin('main.css') ] }; Generate an `index.html` file

When building single-page applications we usually need one .html file to serve it.

The HtmlWebpackPlugin automatically creates an `index.html` file and add script tags for each resulting bundle. It also supports templating syntax and is highly configurable.

var HTMLWebpackPlugin = require('html-webpack-plugin'); var baseConfig = { // ... plugins: [ new HTMLWebpackPlugin() ] }; Building for Production Define the Environment

A lot of libraries introduce warnings that are useful during development time but have no use in our production bundle and increase its size.

Webpack comes with a built-in plugin to set global constants inside your bundle.

var ENV = process.env.NODE_ENV; var baseConfig = { // ... plugins: [ new webpack.DefinePlugin({ 'process.env.NODE_ENV': JSON.stringify(ENV) }) ] };

We now need to specify the environment on our commands:

"scripts": { "start": "NODE_ENV=development webpack-dev-server", "build": "NODE_ENV=production webpack" }

process.env.NODE_ENV will be replaced by a string, allowing compressors to eliminate unreachable development code branches.

This is really useful to introduce warnings in your codebase for your team and they won't get to production.

if (process.env.NODE_ENV === 'development') { console.warn('This warning will dissapear on production build!'); } Compressing

On production, we need to give users the fastest possible product. By minifying our code with remove unnecessary characters, this reduces the size of our bundle and improves loading times.

One of the most popular tools to do this is UglifyJS, and Webpack comes with a built-in plugin to pass our code through it.

// webpack.config.js file var ENV = process.env.NODE_ENV; var baseConfig = { // ... plugins: [] }; if (ENV === 'production') { baseConfig.plugins.push(new webpack.optimize.UglifyJsPlugin()); } Wrap Up

Webpack config files are incredibly useful, and the complexity of the file will depend on your needs. Take care to organize them well as they can become harder to tame as your project grows.

In this article, we started with a blank config file and ended up with a base setup that would allow you to develop locally and release production code. There's more to explore in Webpack, but these key parts and concepts can help you become more familiar with it.

If you want to go deeper, I recommend Webpack official documentation which has been updated and improved for its second big release.

Introduction to Webpack: Entry, Output, Loaders, and Plugins is a post from CSS-Tricks

CSS Animations vs Web Animations API

Css Tricks - Tue, 06/13/2017 - 1:57am

There is a native API for animation in JavaScript known as the Web Animations API. We'll call it WAAPI in this post. MDN has good documentation on it, and Dan Wilson has a great article series.

In this article, we'll compare WAAPI and animations done in CSS.

A note on browser support

WAAPI has a comprehensive and robust polyfill, making it usable in production today, even while browser support is limited.

As ever, you can check Can I Use for browser support data. However, that doesn't provide very good info on support of all the sub features of WAAPI. Here's a checker for that:

See the Pen WAAPI Browser Support Test by Dan Wilson (@danwilson) on CodePen.

To experiment with all features without a polyfill, use Firefox Nightly.

The basics of WAAPI

If you've ever used jQuery's .animate(), the basic syntax of WAAPI should look pretty familiar. 

var element = document.querySelector('.animate-me'); element.animate(keyframes, 1000);

The animate method accepts two parameters: keyframes and duration. In contrast to jQuery, not only does it have the benefit of being built into the browser, it's also more performant.

The first argument, the keyframes, should be an array of objects. Each object is a keyframe in our animation. Here's a simple example:

var keyframes = [ { opacity: 0 }, { opacity: 1 } ];

The second argument, the duration, is how long we want the animation to last?. In the example above it is 1000 milliseconds. Let's look at a more exciting example.

Recreating an animista CSS animation with WAAPI

Here's some CSS code I yanked from the awesome animista for something calling itself the "slide-in-blurred-top" entrance animation. It looks pretty sweet. 

The actual perf is much better than this GIF.

Here's those keyframes in CSS:

0% { transform: translateY(-1000px) scaleY(2.5) scaleX(.2); transform-origin: 50% 0; filter: blur(40px); opacity: 0; } 100% { transform: translateY(0) scaleY(1) scaleX(1); transform-origin: 50% 50%; filter: blur(0); opacity: 1; }

Here's the same code in WAAPI:

var keyframes = [ { transform: 'translateY(-1000px) scaleY(2.5) scaleX(.2)', transformOrigin: '50% 0', filter: 'blur(40px)', opacity: 0 }, { transform: 'translateY(0) scaleY(1) scaleX(1)', transformOrigin: '50% 50%', filter: 'blur(0)', opacity: 1 } ];

We've already seen how easy it is to apply the keyframes to whichever element we want to animate:

element.animate(keyframes, 700);

To keep the example simple, I've only specified the duration. However, we can use this second parameter to pass in far more options. At the very least, we should also specify an easing. Here's the full list of available options with some example values:

var options = { iterations: Infinity, iterationStart: 0, delay: 0, endDelay: 0, direction: 'alternate', duration: 700, fill: 'forwards', easing: 'ease-out', } element.animate(keyframes, options);

With these options, our animation will start at the beginning with no delay and loop forever alternating between playing forwards and in reverse.

See the Pen motion blur waapi circle by CSS GRID (@cssgrid) on CodePen.

Annoyingly, for those of us familiar with CSS animations, some of the terminologies varies from what we're used to. Although on the plus side, things are a lot quicker to type!

  • It's easing rather than animation-timing-function
  • Rather than animation-iteration-count it's iterations. If we want the animation to repeat forever it's Infinity rather than infinite. Somewhat confusingly, Infinity isn't in quotes. Infinity is a JavaScript keyword, whereas the other values are strings.
  • We use milliseconds instead of seconds, which should be familiar to anyone who's written much JavaScript before. (You can use milliseconds in CSS animations as well, but few people do.)

Let's take a closer look at one of the options: iterationStart. 

I was stumped when I first came across iterationStart. Why would you want to start on a specified iteration rather than just decreasing the number of iterations? This option is mostly useful when you use a decimal number. For example, you could set it to .5, and the animation would start half way through. It takes two halves to make a whole, so if your iteration count is set to one and your iterationStart is set to .5, the animation will play from halfway through until the end of the animation, then start at the beginning of the animation and end in the middle! 

It is worth noting that you can also set the total number of iterations to less than one. For example:

var option = { iterations: .5, iterationStart: .5 }

This would play the animation from the middle until the end. 
endDelay: endDelay is useful if you want to string multiple animations after each other, but want there to be a gap between the end of one animation and the start of any subsequent ones. Here's a useful video to explain from Patrick Brosset.

Easing

Easing is one of the most important elements in any animation. WAAPI offers us two different ways to set easing?—?within our keyframes array or within our options object.
In CSS, if you applied animation-timing-function: ease-in-out you might assume that the start of your animation would ease in, and the end of your animation would ease out. In fact, the easing applies between keyframes, not over the entire animation. This can give fine-grained control over the feel of an animation. WAAPI also offers this ability.

var keyframes = [ { opacity: 0, easing: 'ease-in' }, { opacity: 0.5, easing: 'ease-out' }, { opacity: 1 } ]

It's worth noting that in both CSS and WAAPI, you shouldn't pass in an easing value for the last frame, as this will have no effect. This is a mistake a lot of people make.
Sometimes it's a lot more intuitive to add easing over an entire animation. This is not possible with CSS, but can now be achieved with WAAPI.

var options = { duration: 1000, easing: 'ease-in-out', }

You can see the difference between these two kinds of easing in this Pen:

See the Pen Same animation, different easing by CSS GRID (@cssgrid) on CodePen.

Ease vs Linear

It's worth noting another difference between CSS animation and WAAPI: the default of CSS is ease, while the default of WAAPI is linear. Ease is actually a version of ease-in-out and is a pretty nice option if you're feeling lazy. Meanwhile, linear is deadly dull and lifeless?—?a consistent speed that looks mechanical and unnatural. It was probably chosen as the default as it is the most neutral option. However, it makes it even more important to apply an easing when working with WAAPI than when working with CSS, lest your animation look tedious and robotic.

Performance

WAAPI provides the same performance improvements as CSS animations, although that doesn't mean a smooth animation is inevitable. 

I had hoped that the performance optimizations of this API would mean we could escape the use of will-change and the totally hacky translateZ? —? and eventually, it might. However, at least in the current browser implementations, these properties can still be helpful and necessary in dealing with jank issues.

However, at least if you have a delay on your animation, you don't need to worry about using will-change. The primary author of the web animations spec had some interesting advice over on the Animation for Work Slack community, which hopefully he won't mind me repeating here: 

If you have a positive delay, you don't need will-change since the browser will layerize at the start of the delay and when the animation starts it will be ready to go.

WAAPI Versus CSS Animations?

WAAPI gives us a syntax to do in JavaScript what we could already achieve in a stylesheet. Yet, they shouldn't be seen as rivals. If we decide to stick to CSS for our animations and transitions, we can interact with those animations with WAAPI.
 

Animation Object

The .animate() method doesn't just animate our element,? it also returns something. 

var myAnimation = element.animate(keyframes, options); Animation object viewed in a console

If we take a look at the return value in the console, we'll see its an animation object. This offers us all sorts of functionality, some of which is pretty self-explanatory, like myAnimation.pause(). We could already achieve a similar result with CSS animations by changing the animation-play-state property, but the WAAPI syntax is somewhat terser than element.style.animationPlayState = "paused". We also have the power to easily reverse our animation with myAnimation.reverse(), which again, is only a slight improvement over changing the animation-direction CSS property with our script.

However, up until now, manipulating @keyframes with JavaScript hasn't been the easiest thing in the world. Even something as simple as restarting an animation takes a bit of know-how, as Chris Coyier has previously written about. Using WAAPI we can simply use myAnimation.play() to replay the animation from the beginning if it had previously completed, or to play it from mid-iteration if we had paused it.

We can even change the speed of an animation with complete ease.

myAnimation.playbackRate = 2; // speed it up myAnimation.playbackRate = .4; // use a number less than one to slow it down getAnimations()

This method will return an array of any animation objects for any animations we've defined with WAAPI, as well as for any CSS transitions or animations.

element.getAnimations() // returns any animations or transitions applied to our element using CSS or WAAPI

If you feel comfortable and content using CSS for defining and applying your animations, getAnimations() allows you to use the API in conjunction with @keyframes. It's possible to continue to use CSS for the bulk of your animation work and still get the benefit of the API when you need it. Let's see how easy that is.

Even if a DOM element only has one animation applied to it, getAnimations() will always return an array. Let's grab that single animation object to work with.

var h2 = document.querySelector("h2"); var myCSSAnimation = h2.getAnimations()[0];

Now we can use the web animation API on our CSS animation :)

myCSSAnimation.playbackRate = 4; myCSSAnimation.reverse(); Promises and Events

We already have a variety of events triggered by CSS that we can utilise in our JavaScript code?: ?animationstart, animationend, animationiteration and transitionend. I often need to listen for the end of an animation or transition in order to then remove the element it was applied to from the DOM.

The equivalent of using animationend or transitionend for such a purpose in WAAPI would again make use of the animation object:

myAnimation.onfinish = function() { element.remove(); }

WAAPI offers us the choice of working with both events and promises. The .finished property of our animation object will return a promise that will resolve at the end of the animation. Here's what the example above would look like using a promise:

myAnimation.finished.then(() => element.remove())

Let's look at a slightly more involved example yanked from the Mozilla Developer Network. Promise.all expects an array of promises and will only run our callback function once all of those promises have resolved. As we've already seen, element.getAnimations() returns an array of animation objects. We can map over all the animation objects in the array calling .finished on each of them, giving us the needed array of promises.

In this example, it's only after all the animations on the page have finished that our function will run.

Promise.all(document.getAnimations().map(animation => animation.finished)).then(function() { // do something cool }) The Future

The features mentioned in this article are just the beginning. The current spec and implementation look to be the start of something great.

CSS Animations vs Web Animations API is a post from CSS-Tricks

An Introduction to the `fr` CSS unit

Css Tricks - Mon, 06/12/2017 - 2:23am

With all the excitement around CSS Grid, I haven't seen as much talk about the new fr CSS length unit (here's the spec). And now that browser support is rapidly improving for this feature, I think this is the time to explore how it can be used in conjunction with our fancy new layout engine because there are a number of benefits when using it; more legible and maintainable code being the primary reasons for making the switch.

To get started, let's take a look at how we'd typically think of building a grid in CSS. In the example below, we're creating a four column grid where each column has an equal width:

<div class="grid"> <div class="column"></div> <div class="column"></div> <div class="column"></div> <div class="column"></div> </div> .grid { display: grid; grid-template-columns: repeat(4, 25%); grid-column-gap: 10px; }

See the Pen CSS-Tricks: Grid Example 1 by Robin Rendle (@robinrendle) on CodePen.

If you've never seen that repeat() function after the grid-template-columns property then let me introduce you to one of the neatest features of CSS Grid! It's a shorthand, essentially, allow us to more succinctly describe repeating values. We could have written grid-template-columns: 25% 25% 25% 25%; instead, but it's cleaner using repeat(), particularly when you have more verbose widths (like a minmax() expression).

The syntax is essentially this:

repeat(number of columns/rows, the column width we want);

There are actually a couple of issues with what we've done so far, though.

First, in order to use this neat CSS function, we had to do a tiny bit of math. We had to think to ourselves what is the total width of the grid (100%) divided by the number of columns we want (4), which brings us to 25%. In this instance, the math is pretty darn easy so we don't have to worry about it but in more complex examples we can completely avoid doing the math and let the browser figure that out for us. We do have calc() available to us, so we could have done repeat(4, calc(100% / 4), but even that's a little weird, and there is another problem anyway...

The second issue is a problem with overflow. Because we've set each column to 25% and a grid-column-gap to 10px then that pushes grid element wider than 100%. It isn't how you'd expect things to work from just looking at the code above but that's how percentages work. What we're really saying with the code above is "set each column to 25% the width of the viewport and have a 10px gap between them." It's a subtle difference, but it causes a big issue with layout.

We've inadvertently caused some horizontal scrolling here:

See the Pen CSS-Tricks: Grid Example 1 by Robin Rendle (@robinrendle) on CodePen.

This is where the fr unit can help us.

The fr unit (a "fraction") can be used when defining grids like any other CSS length such as %, px or em. Let's quickly refactor the code above to use this peculiar new value:

.grid { display: grid; grid-template-columns: repeat(4, 1fr); grid-column-gap: 10px; }

See the Pen CSS-Tricks: Grid Example 1b by Robin Rendle (@robinrendle) on CodePen.

That will look just the same as the example above because in this instance we're setting each of our four columns to one fraction (which happens to be 1/4 or 25%). But! There's no overflow on the x-axis anymore because setting each column to 1fr takes that 10px into account automatically and subtracts it from the total width available for each column.

Why the heck should I learn how to use this fancy new CSS length if I can mostly stick to the units like percent or pixels, you wonder? Well, let's dig into a more complex CSS Grid example to explain why fr is a better alternative. In a new example, let's say we want our navigation on the left followed by a twelve column grid which should look like this:

This is a pretty typical scenario for a lot of UIs and so using the fr unit prevents us from either making a separate grid div or fumbling about with calc. Because if we didn't use fr in the example above then we'd somehow have to figure out the following:

the width of each column = ((width of viewport - width of nav) / number of columns) * 1%

That's possible for sure, it's just awfully painful to read, and if we changed the width of the nav then we'd have to do that dumb calculation all over again. Instead, the fr unit tidies all of that up into a super readable line of code:

.grid { display: grid; grid-template-columns: 250px repeat(12, 1fr); grid-column-gap: 10px; }

See the Pen CSS-Tricks: Grid Example 2 by Robin Rendle (@robinrendle) on CodePen.

What we're doing here is setting a fixed width in pixels for the first column and then creating twelve separate columns which are set at one "fraction of the free space" (literally how the spec phrases it). But there's no crazy calculations or anything! It's super readable and if the width of that left nav changes then the width of our columns on the right will adjust themselves automatically.

With just a little bit of legwork we've made our interface more maintainable for the future and we've ensured that our code is more legible for the next developers that are coming up behind us.

Information from other folks

Some of the fun and power of the fr unit comes from mixing it with other units. Imagine a fixed sidebar and main content area that takes up the rest of the space: grid-template-columns: 200px 1fr; easy!

Here's an example from Alligator.io showing mixed units nicely:

Rachel Andrew has a video specifically about fr:

Anna Monus has a very good article on fr.

Yay for the fr unit!

An Introduction to the `fr` CSS unit is a post from CSS-Tricks

A Little Example of Data Massaging

Css Tricks - Sun, 06/11/2017 - 9:15am

I'm not sure if "data massaging" is a real thing, but that's how I think of what I'm about to describe.

Dave and I were thinking about a bit of a redesign for ShopTalk Show. Fresh coat of paint kinda thing. Always nice to do that from time to time. But we wanted to start from the inside out this time. It didn't sound very appealing to design around the data that we had. We wanted to work with cleaner data. We needed to massage the data that we had, so that it would open up more design possibilities.

We had fallen into the classic WordPress trap

Which is... just dumping everything into the default content area:

We used Markdown, which I think is smart, but still was a pile of rather unstructured content. An example:

If that content was structured entirely differently every time (like a blog post probably would be), that would be fine. But it wasn't. Each show has that same structure.

It's not WordPress' fault

We just didn't structure the data correctly. You can mess that up in any CMS.

To be fair, it probably took quite a while to fall into a steady structure. It's hard to set up data from day one when you don't know what that structure is going to be. Speaking of which...

The structure we needed

This is what one podcast episode needs as far as structured data:

  • Title of episode
  • Description of episode
  • Featured image of episode
  • MP3
    • URL
    • Running Time
    • Size in Bytes
  • A list of topics in the show with time stamps
  • A list of links
  • Optional: Guest(s)
    • Guest Name
    • Guest URL
    • Guest Twitter
    • Guest Bio
    • Guest Photo
  • Optional: Advertiser(s)
    • Advertiser Name
    • Advertiser URL
    • Advertiser Text
    • Advertiser Timestamp
  • Optional: Job Mention(s)
    • Job Company
    • Job Title
    • Job URL
    • Job Description
  • Optional: Transcript
Even that's not perfect

For example: we hand-number the episodes as part of the title, which means when we need that number individually we're doing string manipulation in the templates, which feels a bit janky.

Another example: guests aren't a programmatic construct to themselves. A guest isn't its own database record with an ID. Which means if a guest appears on multiple shows, that's duplicated data. Plus, it doesn't give us the ability to "display all shows with Rebecca Murphey" very easily, which is something we discussed wanting. There is probably some way to program out way out of this in the future, we're thinking.

Fortunately, that structure is easy to express in Advanced Custom Fields

Once you know what you need, ACF makes it pretty easy to build that out and apply it to whatever kind of page type you need to.

I'm aware that other CMS's encourage this kind of structuring by default. Cool. I think that's smart. You should be very proud of yourself for choosing YourFavoriteCMS.

In ACF, our "Field Group" ended up like this:

We needed "Repeater" fields for data like guests, where there is a structure that needs to repeat any number of times. That's a PRO feature of ACF, which seems like a genius move on their part.

Let the data massaging begin

Unfortunately, now that we had the correct structure, it doesn't mean that all the old data just instantly popped into place. There are a couple of ways we could have gone about this...

We could have split the design of show pages by date. If it was an old show, dump out the content like we always have. If it's a new show, use the nice data format. That feels like an even bigger mess than what we had, though.

We could have tried to program our way out of it. Perhaps some scripts we could run that would parse the old data, make intelligent guesses about what content should be ported to the new structure, and run it. Definitely, a non-trivial thing to write. Even if we could have written it, it may have taken more time than just moving the data by hand.

Or... we could move the data by hand. So that's what we ended up doing. Or rather, we hired someone to move the data for us. Thanks Max! Max Kohler was our data massager.

Hand moving really seemed like the way to go. It's essentially data entry work, but required a little thought and decision making (hence "massaging"), so it's the perfect sort of job to either do yourself or find someone who could use some extra hours.

Design is a lot easier with clean and structured data

With all the data nicely cleaned up, I was able to spit it out in a much more consistent and structured way in the design itself:

This latest design of ShopTalk Show is no masterpiece, but now that all this structural work is done, the next design we should be able to focus more on aesthetics and, perhaps, the more fun parts of visual design.

A Little Example of Data Massaging is a post from CSS-Tricks

CSS-Tricks Chronicle XXXI

Css Tricks - Sat, 06/10/2017 - 6:52am

All the latest happenings! As I like to do, I round up a bunch of things that have happened in the past few months around here on this site, over at CodePen and ShopTalk, and other sites where I got to be a guest or was involved somehow. There has been some big releases, some redesigns, and a bunch of guest podcasts.

I got to be a guest on Relative Paths with Mark Phoenix and Ben Hutchings. It was episode 47 and the topic was dogmatism, a topic I weighed in on earlier with my post My Increasing Wariness of Dogmatism.

The biggest release ever on CodePen is CodePen Projects. It hasn't even been out three months yet! As opposed to Pens on CodePen, Projects gives you an editor that is more of a full-on IDE with your own file system.

I was a guest on Eric Siu's podcast Growth Everywhere, Episode 196 where we talk numbers and growth stuff. (Fair warning on the link: it's pretty pop-up heavy.)

I also had a lot of fun on the Email Design Podcast, Episode 60, where I got to chat with Kevin Mandeville and Jason Rodriguez specifically about email stuff. That's not something I get to talk about much, but I actually find myself doing quite a bit lately with email, and it's a very weird world that somehow feels completely different than "normal" front-end development.

I have moved back home to Milwaukee, after spending the last 7 months in Miami. Bittersweet! Farewell, friends old and new in Miami. Hello, friends old and new in Milwaukee.

We're less than a month away from the 10 year anniversary of CSS-Tricks! We'll definitely do something. No rooftop party or anything, but definitely come see what we got on July 4th.

I redesigned my personal site. It's nothing special to look at, but I think it's going to serve my needs very well. The new site needed to clearly show: this is who I am, this is what I do, this is where I exist other places on the web, and most importantly, these are the things I want you to do.

The most fun little bit is the radio buttons by the bio area, which allow you to customize the length, first person or third, and what format it's in.

ShopTalk also has a brand new website. Also designed and implemented by me, so, brace yourselves for utilitarian. This one was driven by backend data. I think I'll write about that soon.

We recently did a podcast called On Podcasting where I got to chat with Chris Enns about podcasting equipment. I figured it was about time to get some advice and update my gear. I bet if you factor in all the ShopTalk, CodePen Radio, guest appearances, and videos I've recorded, I'm around 1,000 episodes of stuff. Probably about time I have some decent gear. I pulled the trigger on the major upgrade. I'll have to post about that soon as well.

My public speaking schedule for the rest of the year is:

CSS-Tricks Chronicle XXXI is a post from CSS-Tricks

The Equilateral Triangle of a Perfect Paragraph

Css Tricks - Fri, 06/09/2017 - 2:11am

Still, too many web designers neglect the importance of typography on the web. So far, I've only met a few that really understand typography and know how to apply that knowledge to their work. And the lack of knowledge about typography doesn't come from ignorance. I learned that web designers are commonly either self-taught and haven't grasped the importance of typography yet, or they actually studied design but typography was just one of the classes they had to attend.

I created the Better Web Type course to help raise awareness of the important role typography plays on the web. In my opinion, both web designers and web developers should learn the basics—if a designer uses ligatures in her designs but the developer doesn't even know what ligatures are, how can we expect him to correctly transform the most beautifully designed typography into code? With both roles knowing the basics, we'll be able to start contributing to a better web by producing better web typography. Together.

One of the most important things in typography is to shape a seamless reading experience that invites the reader and presents the content in an objective way. To do that, we need to be able to shape perfect paragraphs. There are three keys to doing that, as Josef Mueller-Brockmann—a renowned 20th-century typographer and visual communicator, put it:

The reader should be able to read the message of a text easily and comfortably. This depends to a not inconsiderable extent on the size of the type, the length of the lines and the leading (line-height).

—Josef Mueller–Brockmann

When I was writing the lessons for the Better Web Type course, I was trying to think of a simple concept that would illustrate exactly that: font-size, line-height, and length of lines need to be in perfect balance. I struggled for a while but then, out of nothing, it hit me—the equilateral triangle. All three sides of an equilateral triangle are equal and so are all the three angles. A great representation of three things in perfect balance. It turned out that it was easy to apply this idea to the three keys that shape a perfect paragraph. But first, let's take a look at each of them in isolation.

Type size & color

One of the mistakes that most websites make is that they make the main body text too small. Back in the early 2000s it was common practice to set the body text to a size of around 11px. But back then the screens were smaller with lower screen resolutions. 11px then was larger than it is now.

A common rule for setting the body text is to set it to a size that would match the size of the text in a book at an arm's length distance.

Matching the font size with the text size from a book at an arm's length. (Source: iA)

The recommended size for today's screens is 16px for mobile and from 18 to 22px for desktop. This also depends on the typeface. Some typefaces set at 16px may seem larger than others, as it's clear in the picture below.

The same text set in Merriweather seems larger and heavier than when set in Georgia.

"Type color" in typography doesn’t mean actual color like red, blue or green. Type color means how heavy black type on a light background looks like. A typeface of the same size and same weight may seem heavier than another one. The contrast of the Merriweather typeface in the example above is lower (comparing the serifs and different stems) than the one of Georgia on the right. That makes it look heavier and the color of the type is darker.

Length of lines

Reading very long lines of text is tiring for our eyes. Our eyes need constant pauses which are provided by line breaks. In that instance of switching to the next line, they get that short pause. Short, but long enough to keep them going for longer. It's like an engine that doesn't run on full power all the time so it keeps going longer without overheating.

The ideal length of a line of text is from 45 to 75 characters—including spaces. Anything that reaches far from that range becomes hard to read. Too much line switching when lines are too short and too few breaks for the eyes when they're too long.

Recommended line length in Google's Material Design Guidelines (Source: material.io) Line-height (leading)

Line-height, or leading as it's usually referred to in print, is the pillar of vertical rhythm in typography. Understanding how it works is key to producing better typography for the web.

Line-height (leading) works differently on the web. It's evenly distributed below and above the line of text.

Too many designers or web developers that I've met think of line-height as an isolated text feature. So they tend to set it based on what seems right. Consequently, line-height is something that gets set without too much consideration. But line-height is too important to be set so mindlessly. The length of the lines affects the line-height. The longer the lines, the more space between them is required. Type size affects the line-height. The larger it is, the larger the line-height should be as well.

Type color affects line-height too. Darker and heavier type requires more space between the lines. And in the end, the typeface itself may affect it as well. As we've seen earlier, some typefaces seem larger than others. Some, mostly serifed typefaces, will seem heavier. Those will require more space between the lines too.

Now that you know that line-height is very important and that it should never be considered as an isolated feature, let's look at general best practices. For paragraphs, ideal line-height is usually between 1.3 and 1.7. So a body text set at 16px should have a line-height from 21 to 26px. This will depend on the things mentioned earlier: typeface design, type size, weight etc.

Same typeface, same font-size, different color. Darker text should have larger line-height. Same typeface, same font size, same color, different line length. The longer the line of text, the larger the line-height required. Different typefaces, same font size, same color. Typefaces that seem larger and heavier need more line-height. The equilateral triangle

There are some general best practices in typography but they're never definite. As we saw with the line-height, we're commonly presented with ranges that we should use. What to choose from that range takes time to learn. The eye needs time to get sharper in noticing these differences.

And so we come to what I call The Equilateral Triangle of a Perfect Paragraph. We've looked at type size, measure and line-height in isolation (as much as we could). By doing so, we already learned that these properties are interconnected. They can't be considered in isolation and they never should be. That's why an equilateral triangle is a perfect representation of a well-designed paragraph of text. For it, we need a good type size that matches the measure, which matches the line height. Get one of them wrong and your triangle will get skewed.

Unfortunately, I can't give you definite numbers of a perfect paragraph as there are millions of combinations out there. But I can give you a few examples that will help you train your eye. Try to pay attention to the details and compare the type size, the lengths of the lines and the spacing between them.

A perfectly balanced paragraph represented by an equilateral triangle.

In the example above, the text is set in Merriweather — an uncommonly large and heavy typeface. That's why it's set to 14px. The line-height is, therefore, closer to the upper edge of the recommended range of 1.3 to 1.7. The paragraph above neatly fits 55 characters per line (also in the recommended range).

Lines of text in this paragraph are too long. The triangle isn't equilateral. To fix this we'd need to either make the type size and line-height larger or decrease the length of the line.

In the example above, the length of the lines is outside the recommended range of 55–75. It's 84 on average, meaning that the bottom side of the triangle expands on both sides. The triangle is not equilateral anymore.

The line-height of this paragraph is too large. The lines of text are starting to drift apart. This example could be improved if we increased the length of the lines. To properly fix it we'd also need to increase the font size to balance it out. A simpler way to fix it would be to decrease the line-height.

The line-height in the example above is obviously too large. It's set to 2 and very much outside the recommended range. The lines of text are too far apart. Unfortunately, this happens too often on the web. It seems like there's a trend of setting type to a light gray color and applying a large line-height on top of it. It's an attempt to get that clean, minimalistic style but it's wrong. Texts like that, especially if long, are hard to read.

The font-size is way too large in this paragraph. It forces the length of the lines to 30 characters and completely skews the triangle. The lines of text are too close together. To fix this we'd either have to decrease the size of the text or increase both line-height and the length of the lines.

Fortunately, I don't encounter this on the web too often. I still wanted to include it, so we cover all the possible options that can come out of this concept. The font size in the example above is way too large for the given line-height and length of the lines. Texts set like this are extremely hard to read.

The learning game

Many of the students of the Better Web Type course have asked me to elaborate on this concept. And what's the best way to illustrate how this concept works in action? A learning game that will help you sharpen your eyes. Presenting "The Equilateral Triangle of a Perfect Paragraph — A Web Typography Learning Game".

The game consists of ten levels, each asking you to set one of the three properties: font size, line-height or the length of the lines. At the end, you get a score out of 100 and a chance to participate in the giveaway of the upcoming book Better Web Typography for a Better Web. Four, randomly chosen, highest scores will get a free book, which is based on the popular Better Web Type course.

I hope that as many people as possible come across this game and learn that line-height, font-size, and length of lines always need to be considered together. Try to get the best result and challenge your friends. The more people know about this, the better the web typography will get.

Check out the game

The Equilateral Triangle of a Perfect Paragraph is a post from CSS-Tricks

An intro to web components with otters

Css Tricks - Fri, 06/09/2017 - 2:10am

Monica Dinculescu on web components and why we might care:

... before web components came around, you had to wait on all browsers to agree on a new element (like, a date picker). And even after they agreed on a new element, it took them yeaaaaars to implement it... With web components, web developers get to write such elements, so that you don't have to wait for 10 years before all browsers agree that they should implement a date picker.

I struggle with trying to figure out if web components (with Polymer or not) are really "the future" or not. People definitely haven't adopted them with the same ferocious appetite as New JavaScript, which also tackles componentization. But they are a web standard with growing native support, so... probably?

I'm probably wrong in conflating the two, though. Even the React Docs say:

React and Web Components are built to solve different problems. Web Components provide strong encapsulation for reusable components, while React provides a declarative library that keeps the DOM in sync with your data. The two goals are complementary.

Direct Link to ArticlePermalink

An intro to web components with otters is a post from CSS-Tricks

Women speakers and attendees at Amsterdam web conferences

QuirksBlog - Fri, 06/09/2017 - 1:59am

As a slight contribution to the diversity in web development discussion, here are the ratios of female attendees and speakers from the Amsterdam web conferences Krijn and I organised or are close to. I’m not sure what these numbers mean, but someone will surely have a bright idea after staring at them for long enough.

function init() { var trs = document.querySelectorAll('#women tbody tr'); for (var i=0,tr;tr=trs[i];i+=1) { var att = parseInt(tr.querySelectorAll('td')[2].textContent); var sp = parseInt(tr.querySelectorAll('td')[3].textContent); tr.appendChild(document.createElement('td')).textContent = (sp/att).toFixed(1); } }

Krijn gathered the crucial attendee numbers, while I added the speakers, a calculation, and some general remarks.

Before we show the numbers, here are some caveats:

  1. Attendee numbers include all speakers.
  2. We only counted an attendee as a woman if we’re 100% certain. Some names are inconclusive, and we counted those as men.
  3. Ratio is the ratio of female speakers and female attendees, both in percentages. Thus, a high ratio means there are relatively more women on stage than in the audience.
  4. Fronteers 2017 ticket sales have not yet concluded; the number of female attendees may yet go up.
  5. My apologies for Fronteers 2008. In my defence: diversity was not in fashion yet back then, and I had no clue what I was doing anyway. The miracle was that the conference took place at all.
Women at Amsterdam web development conferences Date Name Attendees Speakers Ratio 0809 Fronteers 2008 6% 0% 0910 Fronteers 2009 6% 13% 1010 Fronteers 2010 10% 12% 1110 Fronteers 2011 11% 21% 1210 Fronteers 2012 11% 11% 1310 Fronteers 2013 12% 22% 1410 Fronteers 2014 9% 17% 1510 Fronteers 2015 10% 33% 1610 Fronteers 2016 10% 38% 1710 Fronteers 2017* 12% 50% 1306 CSS Day 2013 10% 25% 1406 CSS Day 2014 10% 13% 1506 CSS Day 2015 15% 50% 1606 CSS Day 2016 18% 31% 1706 CSS Day 2017 16% 31% 1411 dsgnday 2014 19% 50% 1511 dsgnday 2015 24% 50% 1105 Mobilism 2011 11% 12% 1205 Mobilism 2012 7% 5% 1305 Mobilism 2013 11% 12% 1503 Mobilism 2015 11% 25%

Now what can we glean from these numbers? The number of female attendees varies between 6 and 24%, and they form a higher percentage in later years, although it partly depends on the conference topic. dsgnday scored really well, while Mobilism fell somewhat short.

The ratio column really asks more questions than it answers; specifically: what SHOULD the share of female speakers be? If the share of female attendees is the benchmark, then all but three of these conferences overshot their mark, sometimes considerably.

The other view would be that there should be 50% woman speakers. Although that sounds great I personally never believed in this argument. It’s based on the general population instead of the population of web developers, and if we’d extend that argument to its logical conclusion then 99.9% of the web development conference speakers should know nothing about web development, since that’s the rough ratio in the general population.

Make of that what you wish. Your mileage (kilometrage?) will vary.

Historical female ratios

This raises the question: what is the share of women in web development anyway? Right now my answer is 15-20%.

The table above is one of my sources. Another is my recollection of my first job, when between 1999 and 2002 I was lead front-end engineer of a team of, to the best of my memory, 13 front-end developers, of which four were women.

Since I had no clue if my experiences were extraordinary or pretty mainstream, I recently asked on Twitter. Based on the replies I conclude that my 30% score was on the high end, and that the average back then was slightly lower. 20-25%?

For many years A List Apart ran an annual survey. I was able to find gender data for three years: 16% women in 2007, 17% in 2009, and 18% in 2011. This sketches a somewhat darker picture, but we can conclude there have always been women in web development — though not as many as we’d like.

So after squinting at these bits of data and doing heuristics (also called AI nowadays), I arrived at my guesstimate of 15-20%. If anyone has more data to share, especially data that does not conform to this picture, now would be a great time to publish it.

World Wide Web, Not Wealthy Western Web

Css Tricks - Fri, 06/09/2017 - 1:58am

Bruce Lawson explores many of the misconceptions that web designers might have when building websites. The crux of his argument is that we should be focusing on designing for users that are just getting online and for those that have frustratingly slow internet connection speeds.

He even makes a bold prediction:

Many of your next customers will come from the area circled below, if only because there are more human beings alive in this circle than in the world outside the circle.

Direct Link to ArticlePermalink

World Wide Web, Not Wealthy Western Web is a post from CSS-Tricks

Building a Directory with the Twitter API

Css Tricks - Thu, 06/08/2017 - 6:11am

Last month, designer Helen Tran asked people to name five women designers that they thought were valuable to the industry:

I need you to help me out.
Name five female Designers you think are really valuable + important to our industry.

— Helen Tran (@tranhelen) April 26, 2017

In just a few days, the tweet generated over 373 replies that named 636 women by their Twitter usernames specifically. A few people were joking around that the thread was a great place to find potential recruits and I realized I had a different need: I'm not trying to recruit anyone but I'd love to find women to follow who are excelling at things that I'm interested in or trying to learn more about. Since many people put their job title or area of expertise in their Twitter descriptions, I realized I could create a self-reported filtering system by searching each description for keywords and then display the profiles in a sortable directory.

I decided to use the thread as a jumping off point and create a free-standing website: Women Who Design. Here's how I built it.

Getting Started

To start, I needed to:

  1. Record each person's Twitter username, also known as their "handle," from the original thread on a list.
  2. Set up the project's file structure.
  3. Get the Twitter REST API to return profile information from a given handle.
  4. Choose a database to store each handle and its corresponding profile information.

The first step, getting the handles, was the easiest. With a good playlist on in the background, I spent about an hour combing the Twitter thread and entered each handle into a spreadsheet, which I then exported as a JSON file called `designers.json`.

At this point, I initialized my git repo and set up a basic file structure:

  • index.html
  • app.js
  • styles.css
  • designers.json

At the top of my `app.js` file, I imported all the designers from the original Twitter thread.

var designers = require('./designers.json');

Next up, I registered my app with Twitter to start working with the REST API.

I chose to configure the project as a read-only application since I was only planning to make use of the GET users/show endpoint, which supplies user profile information.

Then I installed an asynchronous client library for Twitter (also called Twitter) through the command line to enable me to make calls to the API.

npm install twitter

To use the library in my project, I also had to require it at the top of my `app.js` file.

var twitter = require('twitter');

According to the client library documentation, I would need to enter my app's consumer key, consumer secret and a bearer token in my `.js` file after requiring "twitter".

var client = new Twitter({ consumer_key: '', consumer_secret: '', bearer_token: '' });

The key and secret were easily found in my Twitter app dashboard, but the bearer token required an extra step. I ran the following command in the command line to get the bearer token, filling in the variables with my credentials from the dashboard, then I added the result to the client variable above.

curl -u "$CONSUMER_KEY:$CONSUMER_SECRET" \ --data 'grant_type=client_credentials' \ 'https://api.twitter.com/oauth2/token'

The client library also provided a handy convenience method for making requests, so I added it to my app.js file with a note to fill it in later. According to the GET users/show endpoint documentation, I would need to pass each handle from my list to the "screen_name" parameter to get the profile information I was looking for.

client.get('users/show', {'screen_name': handle}, function(error, response) { if (!error) { console.log(response); // do stuff here later! } });

If done correctly, I could expect the response to look something like this:

{ "id": 2244994945, "id_str": "2244994945", "name": "TwitterDev", "screen_name": "TwitterDev", "location": "Internet", "profile_location": null, "description": "...",

Finally, I had to choose a database to store the profiles. I landed on the Realtime Database from Firebase, because it's a NoSQL database that uses JSON as its storage format. I installed firebase and firebase-admin on npm, then required them at the top of my `app.js` file alongside everything else.

var firebase = require('firebase'); var admin = require('firebase-admin');

To get writing to and reading from the database working, I had to authenticate Firebase using a specially generated "Service Account" private key. I generated the key in the Service Accounts tab of my Firebase settings, and dropped the corresponding code below the rest of my configurations.

var serviceAccount = { "type": "service_account", "project_id": process.env.WWD_FIREBASE_PROJECT_ID, "private_key_id": process.env.WWD_FIREBASE_PRIVATE_KEY_ID, "private_key": process.env.WWD_FIREBASE_PRIVATE_KEY, "client_email": process.env.WWD_FIREBASE_CLIENT_EMAIL, "client_id": process.env.WWD_FIREBASE_CLIENT_ID, "auth_uri": "https://accounts.google.com/o/oauth2/auth", "token_uri": "https://accounts.google.com/o/oauth2/token", "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs", "client_x509_cert_url": process.env.WWD_FIREBASE_CLIENT_CERT_URL }; Working with the data

Phew! List recorded: check. App registered: check. File structure set up: check. Database setup: check. Time to actually start using the API.

I took a look at the sample response in the GET users/show endpoint documentation and I determined I’d need to store the user’s name, handle (referred to in the docs as screen_name), location, description, and profile image URL. I also wanted to save the profile color each user set on Twitter to use as a highlight color for buttons, links, and other accents, so I put the following code inside the client library convenience method I had saved in my `app.js` file.

var name = response.name; var handle = response.screen_name; var description = response.description; var imageUrl = response.profile_image_url_https; var location = response.location; var profileColor = response.profileColor;

To prevent situations where differences in capitalization would result in two instances of the same profile (like @julesforrest vs @JulesForrest), I set the handle variable to lowercase.

handle = handle.toLowerCase();

Then I noticed the profile images being returned were way too small to be useful on a desktop display. By tinkering with the image URL, I found a larger image path that worked better for my needs.

imageUrl = response.profile_image_url_https.replace("_normal", "_400x400"); Linking the Links

People often have URLs, @handles, #hashtags and email addresses in their profile descriptions, but unfortunately, the Twitter API was returning each description as a simple string. Luckily, I found a tool called Autolinker that would search each string and build out anchor tags in the appropriate places.

To get it working, I installed it via npm, then required it at the top of my app.js file:

npm install autolinker --save var Autolinker = require( 'autolinker' );

Basic usage looked pretty straightforward and it came with a few options out of the box that could be passed as an object to the second parameter, like opening each link in a new window or adding a class to each anchor tag.

var linkedText = Autolinker.link( textToAutolink[, options] );

However, I wanted to add each user’s custom profile color (saved earlier from the API response) as an inline style on that user’s links, which required writing a custom replacement function. While custom replacement functions can handle some pretty complex configurations, I only tweaked the example from the documentation slightly to add the inline color styles and open each link in a new window. It’s important to note the social network for mentions and hashtags needs to be specified at the top of object parameter to link them properly, which wasn’t immediately clear from the docs.

description = Autolinker.link( description, { mention: 'twitter', hashtag: 'twitter', replaceFn : function( match ) { switch( match.getType() ) { case 'url' : var tag = match.buildTag(); tag.setAttr( 'style', 'color: #' + profileColor ); return tag; case 'mention' : var mention = match.getMention(); return `<a href="https://twitter.com/${mention}" target="blank" style="color: #${profileColor}">@${mention}</a>`; case 'email' : var email = match.getEmail(); return `<a href="mailto:"${email}" target="blank" style="color: #${profileColor}">${email}</a>`; case 'hashtag' : var hashtag = match.getHashtag(); return `<a href="https://twitter.com/hashtag/${hashtag}" target="blank" style="color: #${profileColor}">#${hashtag}</a>`; } } });

Frustratingly, though, Twitter's link-shortened t.co URLs were showing up as the text of the anchor tag instead of the descriptive URL.

Several hours of debugging later, I finally noticed that the t.co URLs and not the descriptive URLs were in the original strings returned by the API all along. After re-examining the sample response, I found a description.urls object that I had missed earlier and logged that as well, replacing the t.co URL text with the appropriate descriptive URL text.

var descriptionUrls = response.entities.description.urls; if (descriptionUrls.length != 0) { for (var i = 0; i < descriptionUrls.length; ++i) { description = description.replace(descriptionUrls[i].url, `${descriptionUrls[i].display_url}`); } } Searching for Filters

People get the most of Twitter when they're following people who are relevant to them in some way, so it had to be easy for directory users to sort the profiles by position or area of expertise. For example, as someone who’s interested in front-end development, I'd like to find which women in the directory identified themselves as developers.

Adding those sortable filters was the last and most important step to complete before writing each profile to Firebase and I spent a lot of time thinking about the right way to handle the problem. I knew I could create a self-reported filtering system by searching each profile description for keywords, but many of the terms people had in their descriptions overlapped with one another (product designer and UX designer, developer, and engineer). Ultimately, I decided that it was important to use the exact terms people used to describe themselves, even if it meant more clicks for the directory user.

To choose the filter categories, I looked for terms that showed up most frequently across the descriptions as a whole and wrote a function to search for terms and push appropriate tags to an array. I planned to later use the array on the front end to make the filtering work.

var designerTagsArray = []; function addDesignerTags(handle, searchTerm, tag) { if ((description.toUpperCase()).includes(searchTerm) === true) { designerTagsArray.push(tag); }; }; addDesignerTags(handle, "PRODUCT DESIGN", "product "); addDesignerTags(handle, "LEAD ", "lead "); addDesignerTags(handle, "MANAGER", "manager "); // etc, etc

For certain terms like "director", I had to do a custom search to weed out similar phrases with significantly different meanings like art director or creative director.

if ((description.toUpperCase()).includes("DIRECTOR") === true) { if ((description.toUpperCase()).includes("ART DIRECTOR") === true) { // do nothing } else if ((description.toUpperCase()).includes("CREATIVE DIRECTOR") === true) { // do nothing } else { designerTagsArray.push("director"); }; };

When the filtering was done, I stringified the array and removed any extra characters:

designerTagsArray = JSON.stringify(designerTagsArray); designerTagsArray = designerTagsArray.replace(/[^\w\s]/gi, ''); Writing to Firebase

It was time to upload all the data from the original list. First, I created a new object to hold all the information I needed to write to Firebase:

var designerProfile = new Object();

Assigned all items:

designerProfile.name = name; designerProfile.handle = handle; designerProfile.description = description; designerProfile.imageUrl = imageUrl; designerProfile.imageUrlMobile = imageUrlMobile; designerProfile.profileColor = profileColor; designerProfile.designerTags = designerTagsArray;

And wrote a function to add them to an object I named display on Firebase:

function writeToFirebase(handle, designerProfile) { firebase.database().ref('display/' + handle).set({ designerProfile }); console.log(handle + " has been written to Firebase!"); }; writeToFirebase(handle, designerProfile);

Up until this point, all the code I had written was contained inside the original convenience method from the Twitter client library:

client.get('users/show', {'screen_name': handle}, function(error, response) { if (!error) { console.log(response); // log relevant data // lowercase handle // adjust image URL // add links to descriptions // search and add tags // write to Firebase } });

I wrapped the convenience method inside a function called getProfileInfo, which accepted a Twitter handle as a parameter.

var getProfileInfo = function(handle) { client.get('users/show', {'screen_name': handle}, function(error, response) { if (!error) { console.log(response); // log relevant data // lowercase handle // adjust image URL // add links to descriptions // search for tags // write to Firebase } }); };

Then I wrote a loop to cycle through each handle from the JSON file of the original list, which I'd imported earlier to the top of my app.js file.

for (var i = 0; i < designers.length; ++i) { getProfileInfo(designers[i].handle); };

Finally, I ran the script in the command line using Node and got all the profile data showing up in Firebase.

node app.js The Front End

While ironing out the data kinks, I was also working on a simple front-end that read profiles from the database and built them out in HTML using jQuery. I created about and nomination pages as well, with a form on the nomination page to capture new submissions.

To get the form working, I grabbed the inputted text from each of the input fields and added them to a new Firebase object I named submit for later review.

var designerDatabase = firebase.database(); $('#designer-submission').submit(function(event){ event.preventDefault(); var handle = $('#handle').val(); var reason = $('#reason').val(); designerDatabase.ref('submissions/' + handle).set({ handle: handle, reason: reason }); $('#handle').val(''); $('#reason').val(''); });

All in all, I ended up with a client-side `.js` file, three `.html` files, a logo `.svg` file and a `.css` file.

Getting it Live

When the basic interactions were all coded, I decided it was time to try getting the project up on Heroku. Since most of the app was built on server-side Node, I needed a tool called Express.js to publish it as an actual site. To do that, I had to set up my `package.json` file.

npm init

After asking a bunch of questions about the name and version number of my app, it prompted me to specify an entry point, which I left as the default: index.js.

entry point: (index.js)

Then I installed Express:

npm install express --save

After that, I set up my index.js file, which looked like this:

var express = require('express'); var app = express(); app.use(express.static('public')); app.get('/', function (req, res) { res.sendFile('index.html'); }); app.listen(process.env.PORT || 3000, function () { console.log('Example app listening on port 3000!'); });

To serve all my client-side files properly, I moved them all to a folder called public. I set up a remote Heroku repo and pushed the code.

git push heroku master Adjusting the back-end structure

Once everything else was up and running, I had to change my setup a bit because I wanted to use the getProfileInfo function to both refresh existing profiles and write entirely new profiles for designers submitted through the site.

I nixed my app.js file and saved the getProfileInfo function as a module.export called getprofileinfo.js<code> to use in two newly created scripts: display.js and submit.js. Then I required the module at the top of the display script and used the Heroku scheduler add-on to run it every 24 hours to refresh the data of existing profiles on Firebase.

var getProfileInfo = require('./getprofileinfo.js'); function getDisplayedDesigners() { firebase.database().ref('display/').on('value', function (results) { var allDisplayedDesigners = results.val(); for (var designer in allDisplayedDesigners) { getProfileInfo(designer); }; }); } getDisplayedDesigners();

The submit script was a little different. I wanted to browse the submissions manually to remove any troll responses or ineligible people, then automatically add the remaining submissions to the display object and remove them from the submit object. I also had to account for people who might include the @ symbol in the handle field of the form when submitting.

var getProfileInfo = require('./getprofileinfo.js'); function getSubmittedDesigners() { firebase.database().ref('submissions/').on('value', function (results) { var allSubmittedDesigners = results.val(); for (var designer in allSubmittedDesigners) { var handle = designer; if (handle.includes("@") === true) { handle = handle.replace("@", ""); getProfileInfo(handle); firebase.database().ref('submissions/' + "@" + handle).remove(); } else { getProfileInfo(handle); firebase.database().ref('submissions/' + handle).remove(); }; }; }); } getSubmittedDesigners();

With this setup, I could run the submit.js in the command line and process all the eligible submissions at once.

node submit.js Launch!

On May 15, I officially launched my first-ever app: Women Who Design. In the first 24 hours, it got 15,000 visitors and 1,000 new nominations, which was pretty exciting to see. I hadn't anticipated that kind of response, though, so I’m now working on some major front-end and performance upgrades to support the site traffic and volume of profiles. In the meantime, I'm glad that people are using the site to find and nominate incredibly talented women in the design industry. Stay tuned!

Building a Directory with the Twitter API is a post from CSS-Tricks

How to improve your site’s UX

Css Tricks - Thu, 06/08/2017 - 6:08am

Let's face it, it's tough to be a web designer today. You have to stand up in front of the class and let people pick apart the thing you spent 10 hours on the night before.

But what if you can really support your designs by actual data and feedback, directly from your users and visitors, ultimately improving the overall experience.

By combining both Analytics and Feedback tools, Hotjar gives you the 'big picture' of how to improve your site's user experience and performance. The Analytics tools allow you to measure and observe user behavior (what users do) while the Feedback tools allow you to hear what your users have to say (Voice of User), all in one central interface.

Try it for free today.

Direct Link to ArticlePermalink

How to improve your site’s UX is a post from CSS-Tricks

Aspect Ratio Boxes

Css Tricks - Thu, 06/08/2017 - 5:47am

I had a little situation the other day where I needed to make one of those aspect-ratio friendly boxes. This isn't particularly new stuff. I think the original credit goes as far back as 2009 and Thierry Koblentz's Intrinsic Ratios and maintained popularity even for other kinds of content with articles like Uncle Dave's Ol' Padded Box.

Let's go on a little journey through this concept, as there is plenty to talk about.

The Core Concept: padding in percentages is based on width

Even when that is a little unintuitive, like for vertical padding. This isn't a hack, but it is weird: padding-top and padding-bottom is based on an element's width. So if you had an element that is 500px wide, and padding-top of 100%, the padding-top would be 500px.

Isn't that a perfect square, 500px × 500px? Yes, it is! An aspect ratio!

If we force the height of the element to zero (height: 0;) and don't have any borders. Then padding will be the only part of the box model affecting the height, and we'll have our square.

Now imagine instead of 100% top padding, we used 56.25%. That happens to be a perfect 16:9 ratio! (9 / 16 = 0.5625).

Now we have a friendly aspect ratio box, that works well in fluid width environments. If the width changes, so does the height, and the element keeps that aspect ratio.

Use case: a background-image

Perhaps we've made a typographic lockup. It's for the title of an article, so it makes sense to use an <h1> tag.

<h1> Happy Birthday </h1>

We can make that <h1> tag the aspect ratio box and apply the lockup as a background image.

h1 { overflow: hidden; height: 0; padding-top: 56.25%; background: url(/images/happy-birthday.svg); }

But I lied about that aspect ratio up there. It's not actually a 16:9 image. I just downloaded that graphic off a stock photography site. It happens to be an SVG with a viewBox="0 0 1127.34 591.44" which means it's essentially an 1127.34 × 591.44 image in terms of aspect ratio. Or it could have been a 328 × 791 image.

I'd say it's very common for any random image not to fit into a very specific pre-defined aspect ratio...

The Math of Any Possible Aspect Ratio

Perfect squares and 16:9 stuff is great, but the values used for those are just simple math. An aspect ratio can be anything, and they commonly are completely arbitrary. A video or image can be cropped to any size.

So how do we figure out the padding-top for our 1127.34 × 591.44 SVG above?

One way is using calc(), like this:

padding-top: calc(591.44 / 1127.34 * 100%);

It was expressed to me not long ago that using calc() here may be "slower", but I've never seen any evidence of that. I imagine that yes, the computer does need to calculate something, so in a head-to-head battle against a situation where it doesn't, calculating is slower. But a math problem doesn't seem like too much work for a computer. For example, the popular Intel Pentium III (released in 1999) could do 2,054 MIPS or "Millions of instructions per second", so it would make imperceptively quick work of a division problem. And now chips are 50× faster.

If we were using a preprocessor like Sass, we could do the calculation ahead of time:

padding-top: 591.44px / 1127.34px * 100%;

Either way, I'm a fan of leaving the math in the authored code.

How do you put content inside if padding is pushing everything down?

We hid the content in the demo above, by letting the content get pushed out and hiding the overflow. But what if you need an aspect ratio box while keeping content inside of it? That's slightly trickier. We'll need to position it back up into place. Absolute positioning can be up for that job.

Say we're just using text alone now, but still want the aspect ratio box. We'll need an inside wrapper for the absolute positioning. Let's get specific with our classnames:

<h1 class="aspect-ratio-box"> <div class="aspect-ratio-box-inside"> Happy Birthday </div> </h1>

Then do the positioning:

.aspect-ratio-box { height: 0; overflow: hidden; padding-top: 591.44px / 1127.34px * 100%; background: white; position: relative; } .aspect-ratio-box-inside { position: absolute; top: 0; left: 0; width: 100%; height: 100%; }

Just for fun, let's go full blast here and center that text and size it so it scales with the box:

<h1 class="aspect-ratio-box"> <div class="aspect-ratio-box-inside"> <div class="flexbox-centering"> <div class="viewport-sizing"> Happy Birthday </div> </div> </div> </h1>

Few more classes to style:

.flexbox-centering { height: 100%; display: flex; justify-content: center; align-items: center; } .viewport-sizing { font-size: 5vw; } Use Case: Video

This is probably the #1 most common and practical use case for all this aspect ratio box stuff. HTML5 <video> isn't an issue, as it behaves as if it has an aspect ratio just like <img>s do. But a lot of video on the web arrives in <iframe>s, which do not scale with an aspect ratio.

This is exactly what FitVids is all about. It finds videos on the page, figures out their unique aspect ratios, then applies these same CSS concepts to them to make them fluid width while maintaining their unique aspect ratios.

FitVids is jQuery based, but there are vanilla JavaScript options, like this one by Ross Zurowski.

But... what if there is too much content?

Back to arbitrary (probably textual) content for a bit.

We're essentially setting heights here, which should always flash a blinking red light when working with CSS. The web likes to grow downward, and setting fixed heights is an enemy to that natural movement.

If the content becomes too much for the space, we're in Bad Design territory:

Bad Design Territory

Maybe we could do something like overflow: auto; but that might be Awkward Design Territory.

The Psuedo Element Tactic

This is what has become, I think, the best way to handle an aspect ratio box that has completely arbitrary content in it. Keith Grant has a good writeup on it. Marc Hinse had an explanation and demos back in 2013.

With this technique, you get the aspect ratio box with less markup, and it's still safe if the content exceeds the height.

The trick is to apply the % padding to a pseudo element instead of the box itself. You float the pseudo-element, so the content inside can be inside nicely, then clear the float.

.aspect-ratio-box { background: white; } .aspect-ratio-box::before { content: ""; width: 1px; margin-left: -1px; float: left; height: 0; padding-top: 591.44px / 1127.34px * 100%; } .aspect-ratio-box::after { /* to clear float */ content: ""; display: table; clear: both; }

See how it's safer:

And a video:

Using Custom Properties

This is perhaps the coolest idea of all!

Thierry Koblentz recently wrote this up, crediting Sérgio Gomes for the idea.

To use it, you set a custom property scoped right to the element you need it on:

<div style="--aspect-ratio:815/419;"> </div> <div style="--aspect-ratio:16:9;"> </div> <!-- even single value --> <div style="--aspect-ratio:1.4;"> </div>

The CSS that styles this is gosh-danged genius:

[style*="--aspect-ratio"] > :first-child { width: 100%; } [style*="--aspect-ratio"] > img { height: auto; } @supports (--custom:property) { [style*="--aspect-ratio"] { position: relative; } [style*="--aspect-ratio"]::before { content: ""; display: block; padding-bottom: calc(100% / (var(--aspect-ratio))); } [style*="--aspect-ratio"] > :first-child { position: absolute; top: 0; left: 0; height: 100%; } }

Allow me to quote Thierry's step-by-step explanation:

  • We use [style*="--aspect-ratio"] as a hook to target the appropriate boxes
  • We stretch the inner box regardless of support for custom property
  • We make sure the height of images comes from their intrinsic ratio rather than their height attribute
  • We style the container as a containing block (so the inner box references that ancestor for its positioning)
  • We create a pseudo-element to be used with the “padding hack” (it is that element that creates the aspect ratio)
  • We use calc() and var() to calculate padding based on the value of the custom property
  • We style the inner box so it matches the dimensions of its containing block
Other Ideas & Tools

Lisi Linhart tipped me off to Ratio Buddy, which is super cool:

Notice that it uses a pseudo element, but then still absolutely positions the inside container. That's kinda weird. You'd probably either skip the pseudo element and put the padding right on the container, or float the pseudo-element so you don't need that inner container. Still, I like the idea of a little generator for this.

Tommy Hodgins has CSSplus which features Aspecty which is just for this, assuming you're cool with a JavaScript parsing and changing your CSS kinda thing:

See the Pen Aspect Ratio for Chris by Chris Coyier (@chriscoyier) on CodePen.

I've actually seen quite a bit of real world usage of aspect ratio boxes over the years. Feel free to share if you've had some experience!

Aspect Ratio Boxes is a post from CSS-Tricks

UX Case Study: Bumble

Usability Geek - Wed, 06/07/2017 - 10:42am
I have written a considerable amount of articles on a variety of UX design topics, covering subjects as niche as mobile app pop-ups to concepts as spacious and all-encompassing as design itself. But...
Categories: Web Standards

Masking vs. Clipping: When to Use Each

Css Tricks - Wed, 06/07/2017 - 3:20am

I was recently doing some client work where I used both <clipPath>s and <mask>s in SVG to hide and show content for animation. When I started this project, I thought I knew all of the reasons to use one over the other. But, as tends to happen, working closely with something reveals idiosyncrasies. In this post, we'll go over some of these details so that you can get productive as soon as possible.

What is clipping and masking and why should we care about it?

Both clipping and masking obscure areas where elements in an SVG or HTML element can be visually applied. You use a bit of SVG designated as a <clipPath> or <mask> by wrapping the element and applying an id, like so:

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

Though no demo of these techniques will rival Yoksel's version, which is comprehensive not just to SVG but to CSS versions of clipping and masking as well:

See the Pen CSS and SVG Masks by yoksel (@yoksel) on CodePen.

These techniques are so useful because we can show and hide bits of content, which we can use for unique layouts, realism in animation, and performant alternatives to height transitions.

Clipping

Think about <clipPath> in SVG (or clip-path in CSS) as a way to cut a shape out of another shape. There's no concept of opacity, or alpha channel, to gray area here. Parts of the element with a clipping path applied are literally visible or not visible. Clipping just uses the geometry of the shape. Because of this, certain visual elements won't be applied. This includes, but is not limited to: stroke and stroke styles, gradients, and fill colors.

You can still, however, animate these visual elements, change their attributes, and apply transforms to them, these will still be honored. Remember that when you animate them you need to target the elements inside the <clipPath>. Another thing to keep in mind is that the pieces that are clipped away won't accept pointer events, so events can only be captured on the parts that you can visually see.

Check out the Wall-e demo below. Do you see how the arms are being obscured as they reach out and then tuck back into the body? In order to realistically hide and show that arm, we will need to obscure it as it moves. In this case, we made a clipPath out of the elbow curve and clipped pieces of the arm as it extended.

See the Pen Vue-controlled Wall-E by Sarah Drasner (@sdras) on CodePen.

It doesn't end there, of course, we can apply this technique to more sophisticated effects, such as this amazing x-ray machine from Noel Delgado:

See the Pen X-ray me (SVG Experiment) by Noel Delgado (@noeldelgado) on CodePen.

Masking

Think about masking as a way to apply complex, detailed, and shapes with varying opacity over another element. This can lead to really beautiful visual effects and performant alternatives to other techniques. For instance, animating gradients can be really CPU-intensive. But in the graphic below, we’re animating the mask instead of the gradient to the same visual effect, and it's a lot less heavy.

See the Pen Animating transparent mask by Sarah Drasner (@sdras) on CodePen.

Because SVG supports text and each piece is editable, we can also create interesting effects to show and hide pieces of data that are changing. Check out this demo from Craig Roblewsky:

See the Pen Quick Tip: Invert SVG text fill color with masks by Craig Roblewsky (@PointC) on CodePen.


Unlike clipping, masking does respect stroke and stroke effects, but keep in mind that in a mask, it will treat white as an area that will be shown and black as an area to be masked, with the greyscale exposing each along that scale.

This means, though, that you can use gifs with white and transparency to create masks that expose really cool effects:

See the Pen Gif masking in SVG by Sarah Drasner (@sdras) on CodePen.

I learned everything I needed to learn to make the above demo from Yoksel, who has a vast collection of pens with this technique, here's one I particularly like with a bird and a gradient, and a subtle texture in the background.

See the Pen Rainbow bird by yoksel (@yoksel) on CodePen.

Masking vs. Clipping: When to Use Each is a post from CSS-Tricks

Syndicate content
©2003 - Present Akamai Design & Development.