Given the pervasiveness of WordPress and the size of the development community, I believe this is a watershed moment. Arguably web developers are now officially living in a JavaScript-driven world. Might this be the beginning of the end for PHP?
This chart of benefits from the WP developer article says it all. (Click to expand.)
See this table listing the benefits of the new JavaScript workflow at WordPress.com.
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).
Firefox refused to display my Font Awesome icons. After some research I found it was a cross-domain issue created by the fact that the files were being served from a CDN. (Specifically, WP Engine’s CDN.)
The fix for me was to place an .htaccess file inside the font directory containing these lines:
<FilesMatch ".(ttf|otf|eot|woff)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</FilesMatch>
This cleared it up for me. All now works as it should.
With Twitter Bootstrap’s 2.1 release, and running through the current version 2.2.1, dropdown menus have stopped working as they should in iOS and Android. Try to tap a submenu item, and the nav simply disappears. See the Github issue here. It is currently slated to be fixed in the upcoming 2.2.2 release, and I’m confident it will be addressed.
Until then, this quick little hack has worked for me. Add the following line of JS after Bootstrap’s bootstrap-dropdown.js (either in your own JS file or by adding it to Bootstrap’s JS):
$('body').on('touchstart.dropdown', '.dropdown-menu', function (e) { e.stopPropagation(); });
Since then, dropdown menus work as they should in iOS and Android, and I’ve noticed no adverse effects on non-touch devices.
Typography, buttons, thumbnails, captions, and tables
Bootstrap’s excellent jQuery plugins, including
Drop-down menus
Tabbed content switching
Responsive carousel slider for images and captions
Use Bootstrap’s Customize page for basic customization of CSS and JavaScript
Recommended resources for going further with Bootstrap
In a word, this book is a brief, friendly introduction to the basics of using Twitter Bootstrap.
Warning: Because the book is brief, and basic, there are a slew of things it does not cover.
What this book does not cover
There’s no room for serious customization of Bootstrap’s built-in styles.
It’s not able to introduce you to working with Bootstrap’s LESS files.
I regret that. But again, the book is brief and basic. (I had constraints.)
Who would want to buy this book?
If you hate sorting through the documentation yourself, this little book will get you started. By the time you’re done, you’ll be ready to return to the Bootstrap docs with familiarity and confidence as you consult it and other recommended resources to keep rolling.
Responsive Asset-Delivery — just the files you need for your device, and make it quick! (see Paul Irish on this)
Responsive Interactions — the way things are going, we may need to capture clicks, swipes, pinches, waves, fist-bumps, back flips, and on and on (seen Leap Motion?)
Responsive Workflow — none of the above happens very well without informed participants working collaboratively to achieve great results (see Viljami Salminen’s “Responsive Workflow”)
I’ve probably left a few things out. But these categories help me get a handle on what’s going on and what everyone’s trying to make happen. It’s taking a lot of work, and it’s exciting to watch. (Don’t miss Aaron Gustafson’s Adaptive Web Design and Brad Frost’s recent how-to, demo, and reflection.)
I’m intrigued enough that I’ve started a little project to try to track these discussions:
RockinResponsive.com — currently only a homepage, but I intend to shape it into a great curated collection of “the best hits on the road to a responsive web”
@RockinResponsiv — I’m actively favoriting, tweeting, and retweeting here
Hi everyone,
Data Enhanced 