Poll Results for “How much do you value your keyboard typing skills?”
Nearly 22,000 CSS-Tricks visitors voted in this one. A majority (72%) voted that they can type well. Only very few (6%) said they had limited typing ability. The rest in the "OK" range. The voting was broken up in a 1-10 scale. See the complete results in the sidebar of the site.
This was an awkward poll (my fault) because I was interested both in how good you are at typing as well as how much you care about that. Do those things go hand in hand, or not? Probably would have been better as two separate questions.
The most voted-for single option, by far, was [8] Quite valuable. I can type well but I don't really practice. That resonates with me. I feel like I'm just fine thank you very much at typing. I never set out to get better at it, but I sure do it a lot. And I kinda presume I get better at it the more I do it because that's how everything else in the world works. Although I'm sure dedicated practice/training would surely level me up faster.
It seems to me, from what we have here, most people consider themselves good typists and don't worry too much about it. Very few people can't do it. And there is a surprisingly large contingent who value it enough to practice (or at least consider themselves very good at it).
When you're a fast, efficient typist, you spend less time between thinking that thought and expressing it in code. Which means, if you're me at least, that you might actually get some of your ideas committed to screen before you completely lose your train of thought. Again.
Any final thoughts on this matter? Let's talk it out in the comments.
Sponsored: Hack Reactor – The Original JavaScript Coding School
Hack Reactor is a 3-month immersive coding school focused on computer science fundamentals and JavaScript. With a twofold mission, Hack Reactor works to empower people and transform education through rapid-iteration teaching. Hack Reactor grads work at companies like Google, Adobe, OpenTable, Amazon, and numerous startups with a average starting salary of $105K and a 99% graduate hiring rate.
I personally know someone who went to a coding school and changed careers and changed their life, so I'm a believer. Apply today and gain the skills and confidence to build amazing products.
I had heard several people say Design for Community by Derek Powazek is a great book and was published well "before it's time." As someone who works on several sites that I very much think of as community sites, I picked it up and gave it a read. Published in 2001, the book is just over 13 years old now. Ancient history for a typical tech book. It is a tech book in that it talks about specific websites and specific technologies, and those things do feel ancient (the screenshots are hilarious). But as a design book (and kind of an anthropology book), it has aged quite gracefully.
Since I read the book with a highlighter marker in hand, I thought I'd share quotes from it and think about how the ideas from the book have come to pass all these years later.
The word "community" is dangerous. It's the kind of word that shows up in taglines and quarterly reports to make stockholders feel warm and fuzzy.
I've loosely used "CSS-Tricks: A Web Design Community" in the past (like on T-Shirts) and it does feel a bit empty. I don't do myself any favors by reminding people that it's "just me" around here and downplaying the site as essentially just a personal blog. It's grown up quite a bit over the years and I'm going to try to keep growing it. I think I'm going to stop specifically referring to it as a community though and let it just be that if it truly is one.
If you're successful, your members will start calling it a community on their own.
The book starts off with some bad reasons to add community features to your site, including a funny conversation with a CEO that wants to add a live chat room to their site.
"Well, if someone comes in and starts talking trash about the company, you'll wanted them kicked out, right?"
"Right!" he said.
"Good," I said. "Then it's settled. We'll have moderators in there 24/7. Who wants the night shift?"
And that ended that.
Completely open/anonymous/live chat is pretty much gone on the web. It will probably stay that way. The second you put up something like that it's absolutely full of bad behavior. Even here on CSS-Tricks, a live chat demo I did once was full of awful things within hours. Imagine AT&T putting a live chat room on their homepage.
Chat is still around, in the form of private, invite-only chat. For instance, realtime customer support like Media Temple does or team/group chat like Google Hangouts or Slack. In the case of IRC, some channels have moderators. In the case of chat apps like Tlk.io, there are no big public rooms (there is no directly to find them) so rooms are kind of share-only and self-selecting.
When users post to your site, it isn't a gift from them to you; it's the beginning of a very real relationship between you and the user.
But they were the victims of their own success. Users began posting comments and questions so frequently that the comments only lasted on the homepage of the community area for a brief time. The more popular they became, the faster the posts scrolled away before getting responses.
An on-going problem today. So much so that Facebook continually experiments with what to show people when you visit. It's not as simple as the most recent, it's a (presumably) complex algorithm. Some forums feature things like "hot threads" or send digest emails of bustling activity. But most of them, even the forums here, just list threads by most recent. Definitely not a "solved" problem.
I'm always a fan of manual curation. If you have the resources, you pick the best stuff to highlight.
In a story about a digital photography site successfully adding community forums:
I'm certain that had Askey not primed the pump with high quality content from the beginning, the quality (and quantity, for that matter) of the forums would not have been nearly as high.
Certainly the case here on CSS-Tricks. You can't just toss up a brand new website, call it "Wood Carving Forums", and expect wood carvers to come flocking in. Even if you do "prime the pump" it's no guarantee. The only guarantee is that things are going to start slow.
I often had (pipe) dreams of researching video games that were only going to come out years from now and setting up nice forums for the site so when they did launch things would pick up and maybe become the active/default place to talk about that game. But my lack of passion for said game would surely have shone through. And with no other content to support the forums, it was almost surely a fail.
Asynchronous communication gives the participants more time to craft elegant responses. ... You may find that you want to employ a variety of synchronous and asynchronous communication methods for different tasks.
Essentially:
Posting = Asynchronous = Slower = More thoughtful
Chat = Synchronous = Faster = More off-the-cuff
They both have strong points and don't need to be mutually exclusive. For instance, CodePen supports comment threads on all Pens and Posts. That's asynchronous and you'll sometimes see essentially mini posts there with code samples and lengthy explanations (Although I admit, they are, for some reason, prone to very short comments.) But in Professor Mode and Collab Mode, we offer the participants of that live chat. Messages come in in real time with no page refresh and are visually called out.
Facebook obviously sees the value in both, offering both posts/photos which are slower and more considered and Messenger which is live chat.
Sometimes the line is blurred, like in GitHub issues where issues are essentially comment threads, but new ones come in in real time.
... the tone of the content you give your users is replicated and amplified a thousand times in the responses it generates.
No question. Publish and enthusiastic post, get enthusiastic responses. But more than the tone of an individual post, the tone comes from the copy everywhere on the site. From microcopy to documentation. From headlines to emails.
Personally I see it happen on the most molecular level. If I post something with a pissy tone in a comment thread, I get pissy responses. More and more I see that positivity spreads a little, negativity/anger spreads a lot, and positivity can often stop a negative domino effect dead in its tracks.
If the community is constantly reminded that he leaders are all real people, everyone will stay a whole lot friendlier.
I'm a big believer in this. I like to write like I'm just some dude talking to you. That's how I think; that's how I feel. That creates tone. That tone is casual. That is amplified in the communities.
It's imperative that you remember that everything you type serves as an example of what is permissible in the forum.
No one is above the law! Especially the king!
And everything a user posts serves as an example as well. At a minimum you have to moderate threads, and ideally give moderation tools to users as well. Comment threads can get incredibly bad, like as bad as bad can possibly be. I also think of the insane threads we see these days on Reddit / Hacker News / YouTube. Awash with personal attacks, racism, etc. The longer it's like that, the more "OK" it seems to others.
Find the proactive, positive members and get them involved in the production of your content.
I'm constantly trying to do this and wishing I was better at doing this. Easily could be a full time job.
Speaking of a full-time job, from an interview in the book with Matt Haughey:
Don't underestimate the commitment required. Done right, a community site will take a lot of your time, and the payoffs, in whatever form you set for yourself as goals, may not come for a very long time.
Years, at a minimum, in my experience.
... pick something you're passionate about, devote the necessary time to building a site around it, stick with it for as long as it takes.
... songwriting and web design are really the same thing. Each of them involves setting a beat and then improvising around it.
Nice sentiment. I'm admittedly fond of music analogies though. I like that idea that no matter how much of a plan you have, the real designing starts after you've started building and even after you've launched.
... tie your community features to your content as much as possible, visually and architecturally.
Having comment threads specifically for bits of content that are someplace entirely different on the site is just weird, and not something we're used to seeing these days. Perhaps those days are rightfully gone.
Whenever I'm reading a site with a beautiful design and then I link away to a bargain basement area for the discussion tools, I feel like I've just been sent to the kid's table.
I know I like discussion about content as close to the content as I possibly can. Even things like Disqus (while I generally like Disqus) sometimes feel a little more disconnected with the content than I would like (with the often different look and feel than the content above it). I wonder if the Medium technique of commenting on a particular paragraph is something that will catch on. Not sure how I feel about that yet. Clever, but distracting? Too close?
... the first thing the user is greeted with is other people's answers to the question.
This has largely become a standard. Post > Comments > Comment Form. You have to at least scroll past some comments (which hopefully set the proper tone) before you get a chance to comment yourself. Maybe that's what is weird about Disqus. Although they really minimize the comment form until you click in there which is nice.
Later, Derek talks about "burying the post button" in which he admits is counter-intuitive, but leads to higher quality content. I'm still afraid to do that one. I feel like I'd just constantly get called out for bad UX.
... don't be annoyed when your users do something totally unpredictable. They're doing you a favor - they're teaching you about your site.
So valuable. As long as it's positive, you accommodate, not force into another direction. That forcing isn't going to go well.
... if you're users sense that they're being manipulated, they'll resent you for it.
Rules are all well and good, but if they're not communicated to the user in a clear way, they might as well not exist.
Not even that the rules exist at all and are posted somewhere, but that they are right in front of users right when they matter. Derek's message on his site is a classic, one that I've riffed on in various ways over the years, and that I still see riffed on by others:
This is my personal site. It's like my living room. I hope you'll come in, have a seat, and be cool. If if you're not and you post something off-topic, mean, or just plain stupid, I will delete it and kick you out. I reserve the right to delete any post for any reason. I also reserve the right to believe that people are essentially good, in spite of overwhelming evidence to the contrary.
It's like a compliment sandwich in paragraph form: start positive, mention the negative clearly, end positive.
He also points out some fun microcopy from another site:
If you're being a jerk, we have the right to de-activate your account and put gum in your hair.
We try and do the plain-talking thing on CodePen in the midst of legalese. And it wasn't our idea. It's a trend I'd like to see more of.
Unfortunately in my experience, the people who are very good at designing websites are usually not the same kind of people who are good at hosting and moderating them.
I hope that's not true in the very personal case of me, but I take the point. I often see small companies hiring community people among their first hires and large companies having entire dedicated teams. "Social Media Person" surely wasn't even a job when Derek wrote this book.
... whenever I posted something official, it was prefaced by "MODERATOR" and the color was changed slightly so that the community would know it's official.
These days, WordPress applies a class name to the comments based on if it's by a site administrator or the author of the post or whatever, which serves as a styling hook for just this reason. I'm sure most commenting systems have a take on this. The idea has caught on for sure.
While it may be important to give users whatever they want when you're trying to sell them a widget, in a community setting, barriers to entry are a necessary part of creating a successful community space.
I think of big sites switching over to Facebook for comment threads. It's harder to be anonymous there (although not impossible) but also I suspect a lot of people just live logged into Facebook so it's extra obnoxious to switch over to your "anonymous" account. It's not a perfect solution though, as I've heard YouTube had worse comments after forcing you to comment via Google Plus.
I think it's fairly obvious that the bigger the barrier to entry, the higher quality content you'll get. For instance, how to this day you have to be invited to Dribbble. Certainly over the years not having an open signup has meant there is higher quality work being posted there. But also less of it.
Imagine a site you have to submit an application and be approved before you can comment there. That site would be lucky to get a handful of good applicant, I'd bet (in general). The idea of limiting what users can post, I suspect, is frightening to companies. Less activity is scary (nobody cares about us! It looks dead around here!) even though more activity is probably what you should be scared of (moderating and community-building is hard work).
If you're trying to foster prolonged conversations over time, requiring accounts the way to go.
...
If, on the other hand, you're primarily trying to foster a one-time connection, then requiring accounts is a unnecessary hassle to impose on the user, and you'll wind up turning too many people off to justify it.
Just on this site alone there are at least four types of barriers to entry:
Content - people will never come here if this kind of content isn't of interest and they don't seek it out. (good, this is a site by web nerds for web nerds)
Blog comments - Registration isn't required, but leaving a name and email address is. (quick, anybody can do it)
Forums - Registration is required. (makes it easy to come back and be a part of ongoing discussions)
The Lodge - comment threads on those videos required a paid account. (less conversation, easier to manage, good for business)
The barriers to entry can be decided upon on a per-activity basis. Writing or reading.
Email connects people in an immediate, personal way. So it's not surprising that some of the most powerful community experiences can be found in your inbox.
In this chapter Derek talked a lot about email-powered communities. Mailing lists / newsgroups kinda things. Nothing public on the web, which gives that style of communication an "ephemeralness". I don't see a lot of this anymore. Perhaps a slight resurgence in email newsletters, but that's more one-way.
I also think of things like the W3C mailing lists, which take place over email, but are archived on the web. To me it feels archeatic and exclusionary (people still do this?!).
Email is alive and well though, and probably just about the same as it was 13 years ago, if not relied upon even more heavily. Their connection to communities being more relegated to notifications. I don't go on Vimeo every day, for example, but thanks to email notifications of new comments, I can still feel connected there.
All these quotes are from the first 2/3 of the book.
I'm still reading it. Savoring it, really. The last chapter is titled "Killing Your Community" and you just KNOW that has some juicy relevance to today's world.
Derek's current project is Exposure, which I've used and quite like. It's community-like, in that you can browse around other non-anonymous people's photo-stories, but interaction with them is very limited. I wonder what they have in store for community on the site, or if less-is-more here. What lessons from the past are driving decisions here? Interesting to consider.
Ethan Marcotte just wrote about an old article with similar value. Are there any "old" tech books or articles that you still savor?
What do you do when your design pattern breaks down?
Say you have a module. Every site has modules, right?
<div class="module"> </div>
Perfect! We did it!
But now, a New Circumstance™ comes along. This module isn't going to work exactly as is. It's pretty close, but in this New Circumstance™ the module is going to need some extra bottom margin.
How do you handle that? Let's explore some ways.
Body class affects it
Are all the modules on a particular page or area of your site like this? Perhaps you can add a class to that page (or area):
.module { /* normal style */ } .solitary-module { @extend .module; /* could be a %placeholder selector */ /* variation style */ }
Double up classes
Perhaps you create an additional class, but that class isn't meant to work on it's own, it's just a variation.
<div class="module module-books"> </div>
.module { /* normal styles */ } .module.module-books { /* variation styles */ /* you don't HAVE to double up the classes here in the CSS, but it enforces the connection (while increasing specificity) */ }
Data-attribute variations
I don't think this is particularly common, but I kinda dig it.
rssheap is a web-based reader for software developers. You subscribe to tags of interest (CSS, JavaScript, PHP, Ruby, etc.), and we find great articles for you to read. Articles are sorted by how many votes they have to ensure you always read high-quality content.
I think this is a clever idea. It's easier than a typical RSS reader because there is content there the second you sign up and you find things socially. It's also better than a typical news aggregator site in that you mark things as read and customize to your liking.
Say you have a @keyframe animation that animates an element all the way across the screen. From off the left edge to off the right edge. You apply it to multiple elements. But you don't want all the elements to start at the same exact position.
You can change the animation-delay so that they start at different times, but they will still all start at the same place.
Fortunately, there is a way.
The trick is to use negativeanimation-delay. That will begin an animation right away, but as if part of the animation has run already.
Favicons, Touch Icons, Tile Icons, etc. What All Do You Need?
The following is a guest post by Philippe Bernard. Philippe has done research on what it takes to make a favicon (and all the related graphics and markup) such that you are covered with the best quality output everywhere. Spoiler alert: it's a lot of different graphics and markup. Also full disclosure: Philippe has built a tool to help with it he showcases in the article.
Favicons were introduced in 1999 by Internet Explorer 5 (ref) and standardized by the W3C a few months later. They are a small graphic that represents the website.
Since then, most desktop browsers have followed the trend and used favicons in some way. It's an easy job, isn't it? Just create a small picture to add to any web project to make it "final". Nothing fancy. Or is it?
Let's do a quiz!
What is the primary favicon file?
Answer: favicon.ico. And just to make sure: this is not a PNG renamed to favicon.ico. Although some browsers are easygoing enough to forgive this mistake, ICO is a different format, one that supports multiple versions of an image.
Question: What dimensions should favicon.ico be?
A: 16x16. The standard.
B: 32x32. Wasn't favicon updated some time ago?
C: 64x64. You know, with all these new high pixel density screens.
D: None of the above.
Answer: D.
favicon.ico is a format originally conceived by Microsoft and the other vendors have gone along with it. Microsoft recommends 16x16, 32x32 and 48x48. Yes, a single ICO file can contain multiple graphics.
Desktop browsers often use the favicon in a tab, and on standard resolution displays, the 16x16 version is fine:
16x16 favicon.ico in Chrome's tab. So far so good.
But a 16x16 icon is too small for other places: the task bar and the desktop.
16x16 favicon.ico added to task bar.
16x16 favicon.ico added to desktop. Not good.
As soon as the icon contains several pictures, the results are much better.
16x16, 32x32 and 48x48 favicon.ico added to task bar. As good as a native app.
16x16, 32x32 and 48x48 favicon.ico added to desktop. Perfect.
Question: What is the purpose of favicon.png?
When digging the topic, we often encounter another file, favicon.png. People have questions about it all the time. What is it exactly?
A: An icon for browsers which do not support favicon.ico. Such as Firefox, maybe?
B: A high resolution icon. You know, with all these new high pixel density displays.
C: An old relic from the past. Now there are modern icons such as the Apple Touch icon.
D: Answer D. It's complicated.
Answer: D. Since the adoption of HTML5, favicon.ico isn't very useful. The sizes attribute was introduced to specify several different versions of the same icon, and those can be PNG files:
Let's face an unsatisfying truth. Altough all desktop browsers support favicon.ico, this file is mostly deprecated. Yes, you can still rely on this file and it will work as expected. But seriously, it's an old deprecated format. It is not used anywhere else in web technology. PNG is much more consistent.
favicon.ico is for old versions of IE. For the other browsers and most recent versions of IE, we use PNG icons. Then, which sizes do we declare? We'll cover that soon.
Question: What format do we need to support mobile platforms?
According to SmartInsights, more than 26% of the Web traffic is generated by smartphones and tablets. It's the future. What do you need to support this world?
A: favicon.ico. It worked 15 years ago it'll work today.
B: PNG icons. You said you would talk about it.
C: Apple Touch icon. Duh.
D: The right answer is never listed anyway.
Answer: D. You need PNG icons. And Apple Touch icons. And Windows 8 tile graphics. And a file named browserconfig.xml.
Mobile platforms are much more heterogeneous than the classic desktop browsers. Screen sizes and resolutions vary hugely and there is no predominant OS like Windows was when the Internet started to spread. Consequence: do not expect to design a mobile favicon with a single, universal graphic and single, universal declaration in the HTML code.
Question: Which sizes should the PNG icons be?
A: 96x96 for Google TV
B: 196x196 for Android Chrome
C: 228x228 for Coast by Opera
D: All of the above
Answer: D, and more. Like the 160x160 picture for older versions of Opera Speed Dial (long gone), or the 128x128 icon for Chrome Web Store, here it really depends on the platforms you want to support.
Question: What is the size of the Apple Touch icon?
The Apple Touch icon is used by iOS devices for bookmarks and web sites "added to home screen". If the answer that comes to mind is 57x57, congratulations. This is correct. Well, it was, 7 years ago, when the first iPhone was released.
Answer: Up to 152x152.
Three releases occurred since the birth of the first iPhone:
The iPad. Its screen is much larger than the iPhone.
The Retina screen. It doubles the pixel density of the original screen.
iOS 7. Its flat style makes the appearance of iPhone/iPad slightly different.
Combines them and you get 2 x 2 x 2 = 8 combinations:
Device
Screen
iOS version
Icon size
iPhone
Classic
6 and prior
57x57
7
60x60
Retina
6 and prior
114x114
7
120x120
iPad
Classic
6 and prior
72x72
7
76x76
Retina
6 and prior
144x144
7
152x152
An old 57x57 Apple Touch icon on a shiny Retina iPad. Blurry.
A high resolution 152x152 Apple Touch icon on a shiny Retina iPad. Neat.
If you didn't have the right answer, don't blame yourself though. Out of the 5,000 top web sites which exhibit an apple-touch-icon.png, as little as 4% get it right.
Some might argue that 8 graphics are not really necessary. But at least, your master Apple Touch icon should be 152x152. A Retina iPad running iOS 7 will find what it needs and lesser devices can scale down such picture as needed.
Question: Is it necessary to declare the Apple Touch icons in the HTML?
A: I dunno. Come on, you have to answer something!
As strange at it sounds, iOS devices are not the only ones to look for the Apple Touch icon. Since these icons are popular and more common than high resolution PNG icons, some browsers, such as Android Chrome, are using them. Therefore, declaring them is safer, in case a visitor with a compatible device or browser is able to process one of them.
Question: What does it take to define a tile for Windows 8 tablets?
A: Windows 8 tablet? What is this?
B: favicon.ico. Steve Balmer legacy.
C: Two msapplication-TileColor and msapplication-TileImage meta tags.
D: browserconfig.xml.
Answer: C for Windows 8.0 and IE 10, D for Windows 8.1 and IE 11. Answer A is somehow also correct.
Congratulations, you completed the quiz! How did you do?
The point of these questions was to point out how tricky this topic truly is, despite its apparent simplicity. The time when favicon was a single favicon.ico file is long gone. But old habits persist and lead to absurd situations. We can spend days on a super neat responsive design, yet dropping only a 57x57 Apple Touch icon, just suitable for old devices barely used nowadays.
A favicon generator for the mobile era
In 2014, creating a multi-platform favicon is complex and hard to get done right. Sure, you can get a decent result with favicon.ico, a 32x32 PNG icon and a 152x152 apple-touch-icon.png in the root of your web site. But it can take more than a dozen of picture to get the job done. Unless we work on a huge project with according budget, we usually do not have so much time to spend on this small task.
As the author of RealFaviconGenerator, let me give you a wise advice: use RealFaviconGenerator. Unlike the regular favicon generators around, it fills two needs.
Different platforms involve different UIs. While it is certainly not an online version of Photoshop, RealFaviconGenerator offers a few settings to design decent icons for various platforms. Like an opaque background for iOS (Apple prevents transparent icons) or a white silhouette for Windows 8.
Some clever stuff in here regarding styling content that is just regular HTML (perhaps as produced from Markdown). No classes or attributes of any kind, no extra HTML, no JavaScript, no nothin'. Content like that is 1) easier for anyone to produce 2) going to last.
How To Add Page Transitions with CSS and smoothState.js
The following is a guest post by Miguel Ángel Pérez. Miguel has been working on ways to transition pages on websites more gracefully. On single-page applications, we have more opportunity for this since we aren't fighting the page reload. But traditional sites with page reloads, you can still be quite graceful with some help from CSS and JS. In this article Miguel focuses on setting up the CSS to do this and making it work with his plugin.
CSS animations (and a little JavaScript trickery) can let us add page transitions and move away from the hard-cut of page loads. My jQuery plugin smoothState.js helps polish those transitions and improve UI response times.
Page transitions benefit the user experience
Imagine, for a second, how disorienting it would be if touching a doorknob teleported you to the other side of the door. Navigating the web feels like using a teleporting doorknob. Layouts change, elements rearrange or disappear, and it takes time time for the user to adjust. Smooth transitions reduce the effort it takes for users to get settled into a new environment.
Native apps understand the importance of animations. It's uncommon to find an app without page transitions, and users have grown accustomed to this higher level of usability. The web has started to feel outdated because of this shift in expectations. Many think of the web as an inferior experience to apps. Luckily, it doesn't have to be this way.
Add page transitions with CSS @keyframes animations
Let's take a look at an example to see how we could start adding page transitions. In our demo layout we can see the white flashes and hard-cuts typical of web pages.
A default browsing experience.
CSS animations allow us to define the visual behavior of an element when it gets rendered on the page. To add animations to our site we should:
Identify how the elements on the page will animate
Create the keyframes we'll need
Write the CSS declarations
Add classes to the layout
Identify how the elements on the page will animate
Let's look at our sample page:
Annotations to show how our page will animate.
We can pick out a few opportunities for adding some transitions if we examine the layout. Google's guide on meaningful transitions is a good set of rules for element animations. That's a good place to start if you're new to interaction design.
Create the @keyframes we’ll need
It looks like we'll need three types of unique animations.
A fade in animation for the header and the button
A slide up animation with a slight fade for the contents of the home page
A slide in from the right, with a slight fade, for the contents of the detail page
Now that we have our keyframes, we'll need to attach them to classes using the CSS animation properties. Here’s what that CSS looks like:
/* * CSS Page Transitions * Don't forget to add vendor prefixes! */ .m-scene { /** Basic styles for an animated element */ .scene_element { animation-duration: 0.25s; transition-timing-function: ease-in; animation-fill-mode: both;
}
/** An element that fades in */ .scene_element--fadein { animation-name: fadeIn; }
/** An element that fades in and slides up */ .scene_element--fadeinup { animation-name: fadeInUp; }
/** An element that fades in and slides from the right */ .scene_element--fadeinright { animation-name: fadeInRight; } }
It's important to note that animations that take too long will annoy the user. There has been quite a bit of research around the usability of response times. To keep the UI feeling snappy limit the animation duration to 0.25 seconds. Run some quick and dirty user testing to make sure your animations don't feel bothersome.
Add classes to the layout
Now that we have written out our CSS, it’s time to add the classes to the markup.
We've made some progress on our page with just CSS. But even with our improvements, we still see the flash and the animations aren't as tight as they could be. Now we'll use smoothState.js to fix that.
Adding polish with smoothState.js
smoothState.js is a jQuery plugin that progressively enhances page loads to give us more control over page transitions. To include it in our page we'll need to:
Create and include a new .js file, after smoothState.js, where we can run the plugin. (Or use whatever build tool / concatination process you use to do all this.)
Inside our new .js file, we'll want to initialize smoothState on a container with an id. The container should wrap all the content on the page.
;(function ($) { 'use strict'; var content = $('#main').smoothState({ // onStart runs as soon as link has been activated onStart : {
// Set the duration of our animation duration: 250,
// Alterations to the page render: function () {
// Quickly toggles a class and restarts css animations content.toggleAnimationClass('is-exiting'); } } }).data('smoothState'); // makes public methods available })(jQuery);
smoothState gives us access to an onStart.render() callback that allows us to choreograph the way elements exit the page. We can eliminate the page's hard-cuts by reversing the layout animations before displaying new content. To do this, run the .toggleAnimationClass() function, passing in a class as the first argument. Now we'll declare a new animation direction using that class.
We'll also want to animate the user back to the top of the page. Achieve this by using jQuery's .animate() function and setting the scrollTop property to 0.
// Scroll user to the top $body.animate({ 'scrollTop': 0 });
} } }).data('smoothState'); })(jQuery);
The final result is a smooth transition between the pages of our site. Elements enter and exit the page with grace and the white flash is gone. We're firing the animations even before the content loads so the user sees an immediate response from the page.
A browsing experience using CSS animations and smoothState.js
Sponsor: New Creative Market Bundle! $39 for loads of design resources
Creative Market sells loads of design resources. From high quality stock photography and vector art, to print design and web templates, to really fancy stuff like Photoshop actions for getting awesome effects easily.
Once in a while, they put together a bundle of resources you can buy and then have access to download forever from your account. They are packed with all the great stuff I mentioned. Purchased individually, everything together would be quite expensive. But for this week only, the entire Big Bundle is priced at $39!
I love having stuff like this around. Often just poking through looking at everything I have is the creative spark I need to get started building something.
Lots of stuff happening lately and far too long since I've done a Chronicle! Where I've been, where I'm going, things I've done, things I'm doing, etc.
I'm fresh back from a week trip to Iceland. It was the first for-fun-only trip I've taken since I went to Scotland last year. It was amazing.
I did a photo dump over on Flickr, but I'm planning on creating a better page for it somewhere, mixing choice photos with words. Exposure seems like the way to go, but I'm tempted to build my own thing too.
I'm off to Bend, Oregon later this week. To hang out and work with Team CodePen. We like to get together in the same place about once a quarter. We're gonna do some mountain biking, future-talkin', pool-sittin', and working.
It doubles up nicely with the (sad trombone) last-ever Front End Design Conference. It's a special conference for me because it was the first I ever spoke at. If you live anywhere near Portland, Oregon, you should come. Dan and Cherrie are making it a pay-whatever-you-can model, which is pretty dang cool.
I got to go to Düsseldorf, Germany a few month ago for Beyond Tellerrand this year and they put up my talk on SVG. I'm constantly updating this talk and will be giving it for the rest of this year. I think SVG is a damn important part of web design front end development these days.
Speaking of talks of mine that are now available online, An Event Apart published a talk I did in Austin last year about preprocessing.
Here's the full list of things I'll be speaking at for the rest of the year:
November 17-18, An Event Apart, San Francisco, California
I got to be on Brian Krogsgard's postcast Post Status.
CodePen has been chugging along great. It's my full time focus. After we launched our big new blogging feature, we've been kinda heads-down doing lots of maintenance and cleanup work. Things like upgrading servers and software, closing bugs, refactoring code, increasingsecurity, honing performance, and things like that.
We're just now starting to release little features again, like adding Angular, making it easier to build Collections, accepting PayPal, allowing new sorting methods, among other things. There is a lot more to come. We have so many ideas it's as absurd as it is exciting. We're deep into a good three new killer things.
We've also record 20 episodes now (!) of CodePen Radio.
Over in ShopTalk land things are going well too. Show after show, week after week, just how we like it. We never celebrated episode #100, deciding to opt for an episode #123 celebration instead. For that, we dug up a super old episode from 2004!
Dave and I want to make sure we keep ShopTalk worth listening to for y'all, and that means listening to you about what you like and don't like. So: Survey Time!. If you complete the survey, you'll be entered to win one of two tickets to the Front End Summit. We'll pick the winners August 18.
For the first time I'm doing something responsible with my personal business stuff and I made an LLC that I called "Midwest Coast Studios LLC". I have special bank accounts and credit cards and accounting software and everything. Fannnnccccyyyy. I used LegalZoom to set it up and I can recommend that since it was way fast and easy.
Let's say you're using inline SVG and want to change the SVG icon that is displayed in an element on state change, like changing a class or on :hover/:focus. There are a number of ways you can approach that.
Using JavaScript, you could alter the chunk of SVG that is reference in the <use>. Seems weird to do styling things with JavaScript, but, not having duplicated markup is nice, and if you reference a <symbol>, the <title> and <desc> would change too which is nice.
Remember you can do a lot with CSS as well. Perhaps you don't need an entirely different set of shapes, but you can just change things with CSS to essentially make a new icon.
If you don't set styles on anything inside the SVG, you can set them directly on the SVG (essentially crossing the shadow DOM boundary). Plus you can do CSS transforms and such to rotate/scale/move:
If you aren't using inline SVG, but instead using SVG-as-<img>, this hide-show stuff or altering the source should work fine.
If you're using SVG as background-image, changing the source is also an option. Also know that even if you use Data URI's in your CSS for multiple versions of an icon, that can seem bloat-y, but if they are pretty similar GZIP can do great work on that.
Keith Clark explains the core concept behind parallax scrolling (e.g. different elements scroll at different rates) with just CSS. It's a devilishly clever (yet simple) combination of 3D transforms to push the element "away" from the screen, affecting it's scroll rate, while adjusting the scale so the element appears at it's original size.
Scott Kellum and Brenna O'Brien worked up a Sass @mixin for it a while back which makes it even easier.
Are you new to CSS? This article is for you! Perhaps the biggest key to understanding CSS is understanding selectors. Selectors are what allows you to target specific HTML elements and apply style to them. Let's not think about style right now though, let's just focus on the selecting.
In the examples below, the CSS would be in a file called something like style.css that is referenced from an HTML document called something like index.html. They are separate files, which is the great thing about CSS, keeping the design away from the document.
And the CSS file would contain just the selector blocks like you'll see below.
ID selector
#happy-cake {
}
<!-- WILL match --> <div id="happy-cake"></div>
<!-- WILL match --> <aside id="happy-cake"></aside>
<!-- Will NOT match --> <div id="sad-cake">Wrong ID!</div>
<!-- Will NOT match --> <div class="happy-cake">That's not an ID!</div>
Leveling Up
ID selectors are the most powerful type of selector in terms of CSS specificity. Meaning that they beat out other types of selectors and the styles defined within win. That sounds good, but that's typically considered bad, because it's nice to have lower-specificity selectors that are easier to override when needed.
Class Selector
.module {
}
<!-- WILL match --> <div class="module"></div>
<!-- WILL match --> <aside class="country module iceland"></aside>
<!-- Will NOT match --> <div class=".module">The dot is for CSS, not HTML</div>
<!-- Will NOT match --> <div class="bigmodule">Wrong class</div>
Leveling Up
Class selectors are your friend. They are probably the most useful and versatile selectors out there. In part because they are well supported in all browsers. In part because you can add multiple classes (just separated by a space) on HTML elements. In part because there are JavaScript things you can do specifically for manipulating classes.
Tag Selector
h2 {
}
<!-- WILL match --> <h2>Hi, Mom</h2>
<main> <div> <!-- WILL match --> <h2>Anywhere</h2> </div> </main>
<!-- Will NOT match --> <div class="h2">Wrong tag, can't trick it</div>
<!-- Will NOT match --> <h2class="yolo">Make sure that tag has a space after it!</h2>
Leveling Up
Tag selectors are at their most useful when changing properties that are unique to that HTML element. Like setting the list-style on a <ul> or tab-size on a <pre>. Also in reset stylesheets where you are specifically trying to unset styles that browsers apply to certain elements.
Don't rely on the them too much though. It's typically more useful to have a class define styling that you can use on any HTML element.
Attribute Selector
[data-modal="open"] {
}
<!-- WILL match --> <div data-modal="open"></div>
<!-- WILL match --> <aside class='closed' data-modal='open'></aside>
<!-- Will NOT match --> <div data-modal="false">Wrong value</div>
<!-- Will NOT match --> <div data-modal>No value</div>
<!-- Will NOT match --> <div data-modal-open>Wrong attribute</div>
Leveling Up
You might argue that attribute selectors are even more useful than classes because they have the same specificity value, but can be any attribute not just class, plus they can have a value you can select by.
Hardly an issue anymore, but attribute selectors aren't supported in IE 6.
Positional Selectors
:nth-child(2) {
}
<ul> <li>nope</li> <!-- WILL match --> <li>yep, I'm #2</li> <li>nope</li> </ul>
Leveling Up
There are several different positional selectors beyond :nth-child. Using simple expressions (like 3n = "every third") you can select elements based on their position in the HTML. You can play with that idea here or check out some useful recipes.
Other Pseudo Selectors
:empty {
}
<!-- WILL match --> <div></div>
<!-- WILL match --> <aside data-blah><!-- nothin' --></aside>
<!-- Will NOT match --> <div> </div>
<!-- Will NOT match --> <div> </div>
Leveling Up
:empty is one of many pseudo selectors, which you can recognize by the colon (:) in them. They typically represent something that you couldn't know by just the element and attributes alone.
Note that these are slightly different than pseudo elements, which you can recognize by the double colon (::). They are responsible for adding things to the page by the things they select.
More Leveling Up
Selectors can be combined together. For instance:
.module.news { /* Selects elements with BOTH of those classes */ } #site-footer::after { /* Adds content after an element with that ID */ } section[data-open] { /* Selects only section elements if they have this attribute */ }
There are also selector combinators like ~ and + and > that affect selectors, like:
.module > h2 { /* Select h2 elements that are direct children of an element with that class */ } h2 + p { /* Select p elements that are directly following an h2 element */ } li ~ li { /* Select li elements that are siblings (and following) another li element. */ }
Here on CSS-Tricks there is an entire Almanac that covers all the selectors in CSS, as well as properties.
Sponsored: Improve website UX with Hotjar Insights
Hotjar Insights is a web app to help you understand your website visitors. It combines a lot of insight tools (that you might pay for separately) into one unified platform. Heatmaps that tell you where your users are clicking. Feedback forms. Exit polls. Surveys. Video recordings of users using your site. A platform for recruiting people to do user testing for you. Live chat integration. Funnel analysis. And of course, more :)
If you are a designer, UX specialist or into web marketing, this tool will allow you to improve the user experience (and conversion rate) of your site.
Get free early access to Hotjar Insights if you sign up before August 30th, 2014.
The following is a guest post by Julian Shapiro. Julian has been working on Velocity.js recently, which he has written about here on CSS-Tricks before. Julian lives in a world of animation, so it's no surprise he's collected together some interesting examples of exotic animation techniques. Here he shares all about step easing, which you might not even be aware of. A type of animation transition that jumps from keyframe to keyframe in a set number of steps, rather than packing in as many keyframes as possible as animations normally do.
We all know the standard easing types: CSS's ease and ease-in-out, jQuery's swing, and the like. But what about the bastard child of easing? What about the easing type that was - for some reason - written into the CSS spec but few people actually know about and even fewer use?
I'm talking about step easing, with which you specify the number of jumps an animation should take to arrive at its end value. For example, if you specify a step count of 4 with the opacity property across a duration of 1000ms, opacity will jump to the following values at the following times:
0ms: 0
250ms: 0.25
500ms: 0.50
750ms: 0.75
1000ms: 1.00
Between those values, opacity stays where it is. The transitions are instant.
How To Use Step Easing
To use the step easing with CSS transitions, pass in step(stepCount) as your easing type:
We'll be using Velocity.js for our examples below, since it offers fine-tuned tweening control that's better suited than CSS transitions for chaining complex animations together. Velocity.js has a nearly identical API to that of jQuery's $.animate(). (We can't use $.animate() itself because it doesn't have support for step easing.)
Use Cases
As the title of this article promised, it's time to explore clever use cases for step easing. Let's attempt to justify its existence!
Note: To see how these demos were put together, click the JS tab on any of the ensuing CodePen embeds.
Sprite Animation
Let's get the most popular use for step easing out of the way: sprite animation. This is probably the only use case that you've already seen across the Web. The implementation is simple: jump the position of a background-image (which has all the frames of an animation laid out side-by-side) so that we see one "frame" at a time:
The premise here is simple. Let's use step easing to mimic the discrete square-by-square movements of a game board piece. (Without step easing, we'd have to chain a series of CSS property changes back-to-back to accomplish this.)
In keeping with our old-school gaming theme, here's the same discrete translation principle used to replicate the choppy y-axis translation found in Tetris:
So far, we've only looked at obvious use cases that exploit step easing to save us from writing long chains of animation steps. Let's dive into examples that are more clever.
Below, we use step easing to mimic the "unpacking one file at a time" tween commonly found in a progress bar. We use the step easing only for the beginning portion of the animation before we transition into a fluid "finalizing the install" tween. Chaining together these easing types gives progress bars a feeling of separate stages that indicate which portion of the installation process is currently being executed. (Progress bars' status indications are often fabricated, so I contend that this actually has use in the real world.)
In keeping with the theme of exaggerating the elapsing of time, below is another use of fakery to dramatize the speed difference between two service providers:
This strobe effect appears trite upon first glance, but it's actually fairly clever. To establish a comparative baseline, on top is a typical pulsing animation in which opacity is tweened to 1 then reversed to 0 within an infinite loop. As expected, this gives the appearance of a pulsating light source.
Down below, we have a similar example that uses step easing. Here, the discrete motion jumps caused by the step easing create an uneasy "multi-step flashing" sensation that mimics a night club strobe light:
If you can't differentiate between the two examples, use your hand to cover one example while looking at the other.
Paw Prints
What we have here is a single image with a series of paw prints staggered equidistant along the x axis. We pre-clip the image (using the CSS clip property) so that, while the image's full height is visible, its width is not. We then use Velocity to gradually animate clipRight up to the full width of the image while using a step easing that corresponds to the number of paw prints. In other words, we discretely unclip the image to reveal one paw print at a time:
