Archive for the ‘CSS’ Category

File Under: CSS, HTML5

‘Form Follows Function’ Experiments Showcase the Power of HTML5

Form Follows Function. Image: Screenshot.

If you’ve been missing the early days of HTML5, back when experimentation, not stolid, functional sites was the name of the game, we’ve got a site for you: Form Follows Function.

Form Follows Function is a collection of interactive experiments built using HTML5 elements like Canvas and CSS 3 tools like 2-D/3-D transforms. Experiments include growing trees with the click of the mouse (or touch of a finger, depending on your device), dragging waves and 3-D cans of Campbell’s soup. Even the rotating menu of the experiments is impressive.

The site is the brainchild of developer Jongmin Kim, whose design work has previously garnered a Webby award.

Fun thought experiment: Imagine taking this site back in time, showing it to your 2002 self and then pointing out that it’s all built with web standards, no Flash involved.

While we really like Form Follows Function it does fall prey to the main reason we don’t really miss the early days of HTML5 and CSS 3 all that much — it doesn’t use CSS prefixes properly. Form Follow Function optimizes for Firefox and Chrome while ignoring Opera and Internet Explorer; a shame, considering how well done the rest of the site is.

File Under: Browsers, CSS

Google Chrome, Now With Cinema-Style 3-D Effects

CSS custom filters in action. Image: Screenshot/Webmonkey

Google has released an update for its Chrome web browser. Chrome 24 boasts some speed improvements and support for the still-experimental CSS custom filters, which give web developers a way to apply 3-D effects to any HTML element.

You can grab Chrome 24 — now tied with emacs in the great version number race — from Google. Current users should be updated the next time Chrome restarts.

The best news for web developers in this release is support for the draft CSS custom filters specification. First developed by Adobe, custom filters allow web developers to easily apply cinema-style filter effects to any HTML content. Think grayscale-to-color transitions, animated shadows, photo-realistic warping and other mainstays of the 3-D animation world.

Previously you needed Adobe’s special build of WebKit to work with custom filters, but now support is baked into Chrome. However, it’s still disabled by default so you’ll need to head to about:flags and search for “Enable CSS Shaders”. Click “Enable” and then relaunch Chrome. Once you’ve enabled custom filter support, head on over to Adobe’s demo page for some examples of what’s possible with custom filters.

Chrome 24 also offers a nominal speed bump thanks to some improvements in Chrome’s V8 JavaScript engine and, according to an earlier blog post, Chrome’s Cloud Printing feature is faster thanks to some server-side tweaks.

Simplify Responsive Design by Embracing the Flexible Nature of the Web

Some flexible foundations are better than others. Image: McPig/Flickr

If you’re using pixels as part of your responsive designs you’re probably making your life harder than it needs to be.

There’s nothing “wrong” with using pixels in an otherwise responsive layout, but if you do you’ll likely end up writing more code than you would using flexible units.

Jon Allsopp’s A Dao of Web Design predates responsive design by a decade, but its prescient advice remains perhaps the best way to approach any design, responsive or otherwise: “It is the nature of the web to be flexible, and it should be our role as designers and developers to embrace this flexibility, and produce pages which, by being flexible, are accessible to all.”

More than just embracing the nature of the medium, building your sites atop what developer Trent Walton calls “Flexible Foundations” can go a long way to making development easier. As Walton points out in his post, using pixels often means more code since pixel-based type, margins and padding mean you need to add new values at every responsive breakpoint.

“In many ways,” writes Walton, “every time we use a pixel value in CSS we’re rasterizing what was a fully-scalable web.”

Stick with percentages, ems or the newer rem units and your designs can scale simply by changing the body font size. Embracing the flexibility of the medium means you can adapt as well — no need to panic when a client wants to make the logo bigger at the last minute, you can scale the whole layout up (or down) with a few lines of code. For Walton’s design firm, Paravel, the flexible approach has already proved its worth in just this way:

This paid off a few weeks ago, when a client wanted to make significant changes to the layout for his site. Type, imagery, buttons, etc. needed to be smaller and overall width & spacing (margins / padding) needed to be reduced. Thankfully, this was as simple as adjusting the body font-size at wide views. Years ago, however, this could have set the project weeks beyond scoped timeline and budget.

As developer Brad Frost has said, “Get your content ready to go anywhere because it’s going to go everywhere.” Pixels may work today, but they make for a rigid site that might well break on new devices. As Walton concludes “the sites we’ve built to display on a desktop, smartphone, or a tablet today could be on a TV screen, coffee table display, or mega space yacht projection system tomorrow.” Start with a flexible foundation and your site should handle just about any hardware that tries to load it.

Five Ways to Simplify Responsive Design

Building responsive websites can be daunting. After all, instead of just one desktop layout you’re creating at least two, probably three or even four layouts to handle different breakpoints and screen sizes. That means considerably more work, which can feel overwhelming if you don’t have a good plan of attack.

One of the better plans I’ve seen recently comes from developer David Bushell, who recently outlines 5 Tips for Responsive Builds. Among his suggestions there are two standouts, the first being “utilize breakpoint zero.” For Bushell “breakpoint zero” just means “start by writing HTML in a semantic and hierarchical order. Start simple, with no CSS at all and then “apply the basic styles but don’t go beyond the default vertical flow.”

In other words, keep your layout slate blank as long as you can so that when you do start adding layout rules you can spot problems with different breakpoints early and fix them before changing things becomes a major headache.

The other highlight of Bushell’s post is the suggestion that you maintain a CSS pattern library — reusable snippets of CSS you can drop in for quick styling. There are a ton of ways you can do this, whether it’s something formal like SMACSS (pronounced “smacks”), OOCSS, or just taking the time to write a style guide with some sample code. The point isn’t how you do it or which method you use, but that you do it.

Be sure to check out Bushell’s post for more details on these two suggestions as well as the other three ways you can help make your responsive design process a bit smoother.

File Under: CSS, HTML, Performance

GitHub’s Tips for Building Faster Websites

Social code hosting service GitHub isn’t just a free, easy way to host and share your code; it’s also a huge CSS and HTML testing ground with experience writing a fast, scalable code.

So what has GitHub learned from running a hugely successful site? That surprisingly small changes to both HTML and CSS can have a huge impact on performance.

GitHub’s Jon Rohan gave a talk about some of the service’s performance problems and solutions at the CSS Dev Conference in Honolulu earlier this year. (The slides are available on Speaker Deck.) The whole video is worth watching, but the key takeaway is that the right small changes in your code can have a huge impact on performance.

Many of Rohan’s suggestions for faster CSS will be familiar to anyone who’s used YSlow and other performance tools — get rid of unnecessary tag identifiers in your CSS, i.e., div.menu becomes just .menu, eliminate ancestors where possible and avoid chaining your CSS selectors.

On the HTML side — and Rohan says it’s here that GitHub really saw performance improvements — he suggests reducing the amount of matched HTML on the page. That is, look at your pages in a profiler, figure out which tags are being matched and look for ways to simplify the layout to avoid bottlenecks. Among the more depressing things Rohan presents is how much the page load times dropped with switching from anchor links to a JavaScript solution that, while faster, is considerably less accessible.

GitHub is undeniably different than most websites — especially pages like the Git diff views, which involve considerably more code than most pages will need. But, while GitHub may be the extreme example, in many cases the same small changes can help speed up much simpler pages as well.