Should you leave normalize.css as a separate file? (Nope.)

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.

Necolas points this out in the GitHub pull request on this issue:

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.

Elements of a responsive web — or responsive web design’s role in the larger quest

Web GadgetsHi everyone,

I’ve been doing a fair bit of research on the latest thinking in responsive web design. Heady and exciting stuff.

One thing that quickly becomes clear is that responsive web design (see Ethan Marcotte’s book and add Luke Wroblewski’s Mobile First and Andy Clarke’s 320 and Up) is one key element in a larger matrix of elements that together make for a responsive web.

Other key elements include at least these:

  • Responsive Content — content carefully crafted and optimally adapted for your device (see Sara Wachter-Boettcher and Jeffrey Zeldman)
  • 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

Mozilla Developing a WebAPI to replace native apps with HTML5

Mozilla has launched an ambitious new project aimed at breaking down the proprietary app systems on today’s mobile devices. The project, dubbed WebAPI, is Mozilla’s effort to provide a consistent, cross-platform, web-based API for mobile app developers. Using WebAPI, developers would write HTML5 applications rather than native apps for iOS, Android, and other mobile platforms.

Mozilla isn’t just talking about WebAPI, it’s already hard at work and plans to develop the APIs necessary to provide “a basic HTML5 phone experience” within six months. After that, the APIs will be submitted to the W3C for standardization.

Among the APIs Mozilla wants to develop are a telephone and messaging API for calls and SMS, a contacts API, a camera API and half a dozen more.

via Mozilla WebAPI wants to replace native apps with HTML5 — Ars Technica.

HTML and CSS for Beginners: Great Free Resources

HTML and CSS for Beginners: Great Free Resources

HTML Dog.com Screenshot

Here’s a great list of free places to learn the basics of HTML and CSS for those wanting to get started:

Additionally, we would recommend this new video tutorial series: Web Development from Scratch — from Nettuts+.

For a free intermediate level resource, see The MDC (Mozilla’s Doc Center).

Many thanks to the folks who put together this list in their send-up of W3schools.com — a site to be avoided. See W3Fools – A W3Schools Intervention.

Responsive Web Design vs. Mobile Site: Which is better, when?

Responsive Web Design vs. Mobile Site: Which is better, when?


Over the next few weeks we at A Little Code will be experimenting with best ways to optimize sites for multiple devices. Here are a few initial thoughts.

Hitting the Limits of Responsive Web Design

Initially, we’ve found that for a site with a number of interactive elements, such as drop-down navigation, slideshows, javascript overlays, etc., the approach to Responsive Web Design recommended by Ethan Marcotte — adding media queries for mobile devices at the end of things — isn’t up to the task.
Continue reading “Responsive Web Design vs. Mobile Site: Which is better, when?”