The HTML5 Boilerplate has recently separated out normalize.css, giving it a separate stylesheet link in its default template file. Should you leave it like this in your production site? Is there some caching or other gain? Nope. At least probably not.
Looking at the rationale, one finds this was done to help with maintenance and versioning of the H5BP code.
For production, the recommendation is still to roll up all your CSS, including normalize.css into one minified and compressed file.
Benefits of disentangling normalize.css from the rest of the project’s
CSS:
Easier to track normalize.css version.
Easier to update normalize.css.
Easier to remove normalize.css if the user wants.
Clearer distinction between normalizing CSS and the additions that HTML5 Boilerplate provides. Drawback is the additional HTTP request incurred from the extra
stylesheet referenced in the HTML. However, we already do something
similar for the JS, and anyone serious about performance is going to employ a build process to concatenate and minify CSS/JS.
Emphasis added.
Further Notes
HTML5 Bones also has normalize as a separate file.
As pervasive as normalize is becoming, this could become a new best practice …
But in terms of site performance there would need to be caching benefits to overcome the need for the extra HTTP request. If I understand how browsers decide when to use a cached file, the file would need to be sourced from the same online location — as the H5BP does with Google-hosted jQuery.
The trend away from skeuomorphic design toward flat design has in many ways been refreshing and enjoyable. And yet, it’s worth noting that flat can be taken too far, to the detriment of usability. Take for example Microsoft’s modern.ie site — see the commented screenshot below or check it out yourself.
An example of Microsoft taking flat design too far. Usability cues have gone missing.
I would argue they’ve taken interface design hyperflat, and in so doing have left users without important usability hints.
Yes, the gradients and shadows of yesterday have often been overdone. But there is such a thing as subtlety and sophistication, without complete abdication. Used well, gradients, shadows, and hover effects give users important visual cues for navigating your website’s interface more efficiently and effectively.
Even in this otherwise “flat” design, shadows convey depth and provide visual cues to users.
Letterpress … is a perfect example. It is indeed, mostly flat … But Letterpress does have Z-axis depth: when you drag a letter tile, it pops up and has a drop shadow under it until you place it. There’s nothing “flat” about that. What Letterpress rejects is not depth, but depth as mere decoration. The visual “raising” of a tile as you play it is a natural visual cue, a way of emphasizing what it is you’re moving.
Google’s use of edges, bevels, shadows and hover effects, while not overdone, give users important usability cues.
Of course there are other examples. One I’ve recently enjoyed is Andy Clarke’s recent Stuff & Nonsense redesign. Check out his homepage, and you’ll see some elements that are flat, some with edges, some with shadows. All links and buttons have hover effects, begging to be clicked. Then there’s that one gorgeous button, darn near unavoidable in its lusciousness. (No Skitch arrows needed.)
Some flat, some edges, some shadow, all buttons and links with hover effects. And one unavoidably gorgeous button!
What’s going on here? Is it flat or not? With the times? Or behind? One could be forgiven for suspecting that Clarke has subordinated such questions and privileged the point and purpose of the communicative task at hand. While obviously interacting with current trends, the design is enslaved to none of them. Rather it brings past, recent, and current conventions together under the auspices of time-tested and user-empowering design strategies, including visual affordances, interactive feedback, and visual hierarchy.
Clear, straightforward, expressive, and inviting, the design speaks a visual language that is easy to understand and navigate — it looks great to boot — and it leaves no uncertainty about the most important action items on the page.
“What is simplicity and clarity? It’s the user knowing exactly what to do, and how to do it, with a minimum of effort. Achieving this kind of user experience means finding the right balance — not just going flat for flatness’s sake.”
Ran across this wonderfully efficient way of centering list items horizontally. Works great for the indicators below a carousel or a centered list of social icons. Compatible back to IE7.
ul { /* also works with ol */
width: 100%; /* or your desired width */
text-align: center; /* this will center the list items */
}
li {
display: inline-block; /* the key bit */
*display: inline; /* IE7 hack */
*zoom: 1; /* IE7 hack */
}
Suppose you’d like to use a handy LESS mixin to handle multiple CSS3 transitions in a single statement. That’s what LESS is for! But this is a bit of a hairy task. It takes a little finagling. But it’s doable! Here’s how.
To set up multiple CSS3 transitions, you’d do something like this:
a.btn {
background-color: blue;
color: white;
-webkit-transition: background-color, color .2s ease-in-out;
-moz-transition: background-color, color .2s ease-in-out;
-ms-transition: background-color, color .2s ease-in-out;
-o-transition: background-color, color .2s ease-in-out;
transition: background-color, color .2s ease-in-out;
}
It would be nice to do that in shorter form, using a LESS mixin. But by default LESS’s parametric mixins don’t like handling an indeterminate number of arguments. It can handle it (using ‘…’), but our case is even more complex, since we want to list multiple properties (separated by commas) followed by duration and easing (stated once for all).
This is a well crafted, succinct list providing summaries (with links!) of important emerging responsive design trends.
Choice notes include:
“Designing first for a small screen means making the tough decisions about what is most important and what can be cut.”
“Don’t think in terms of exact screen sizes.” — with rationale
“Use as much ‘real’ of data/copy/media as you can.” — because real content makes a difference when designing for a wide range of devices and form factors
Also a series of notes, in very readable paragraph form (and benefiting from Walton’s wonderful knack for typographic design).
Some of my favorite points, each illustrated with helpful thoughts and examples:
“ditching the assembly line method of site building for a more communicative, iterative process will be helpful.”
“I still use Photoshop, but I use it differently.”
“I finish in a mobile-first fashion,” but “I begin with wide views because the layout is usually more complex.”
“let media queried breakpoints be defined by content/layout rather than any specific device. Whenever things don’t fit or hierarchy breaks, add a media query. My favorite example of this is if we set a max-device-width media query at 480px to target an iPhone 4, the iPhone 5 wouldn’t display any of the targeted styles because the screen is larger.”
data enhanced 