All posts tagged ‘CSS’

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, Web Standards

A Look at the Future of CSS

CSS Blend Modes demo. Image: Screenshot/Webmonkey.

We use the term “CSS 3″ all the time on Webmonkey, but technically that’s something of a misnomer. There is no spoon, you see.

In fact, the CSS Working Group, which oversees the CSS specification at the W3C, is cranking out draft specs of new features all the time — the monolithic “3.0″ or “4.0″ versioning was tossed out after CSS 2.1. Instead new features are developed as “modules” so that, for example, the Selector Module can be published without waiting for the Layout Module.

That means there are new CSS features coming all the time.

Adobe’s Divya Manian — who is also one of the developers behind HTML5 Boilerplate — recently gave a talk titled “CSS Next“, which highlights some of the exciting new CSS features coming soon to a browser near you.

Among the cool things Manian highlights are some impressive new tricks for web fonts, including better tools for working with ligatures, unicode and icon fonts.

There are also some impressive new layout tools in the works, namely CSS Regions and Exclusions. We looked at both back when Adobe first proposed them, but since then not only have they progressed to actual draft specs, but they’re now supported in Chrome’s Canary builds (rather than requiring a custom build from Adobe).

It’s still going to be a while before either can claim a spot in your CSS layout toolkit, but there are already a few demos you can check out to see the new layout possibilities Regions and Exclusions offer. Grab a copy of Chrome Canary and turn on “Enable Experimental WebKit Features” in chrome:flags and then point your browser to this demo of Regions and this “shape inside” demo of Exclusions.

Other things Manian covers that we’re looking forward to include CSS Filters and Blend modes. CSS Filters already work in WebKit browsers and allow you to apply effects like blur or grayscale to any HTML element. CSS Blend Modes work just like layer-blending modes in Photoshop and other graphics apps — allowing you to blend layers using modes like “difference,” “overlay,” “multiply” and so on. As of right now you still need a special build of Chromium to see Blend Modes in action.

Manian also covers two intriguing WebKit-only features that aren’t yet a part of any CSS spec, but could be one day. Be sure to read through Manian’s post for more info and a few other new things, including two Webmonkey has covered recently — CSS @supports and CSS Variables.

File Under: CSS, Web Standards

Exercise Better Web Typography With CSS Hyphens

Forget The Homer; look at those sweet, sweet hyphens. Image: Screenshot/Webmonkey.

Last night, while reading Craig Mod’s excellent article, Subcompact Publishing, I noticed something that only type-obsessed nerds probably notice: some really good-looking hyphenation. A quick right-click to “inspect element” revealed this gem: -moz-hyphens: auto;.

It’s true; while we were sleeping Firefox, IE 10 and Safari all implemented the CSS hyphenation spec. In fact, Firefox has had hyphenation support for over year (starting with version 6). Sadly, Chrome doesn’t support hyphens just yet, nor does Opera. Still, if you’d like to do something really simple that will vastly improve the readability of your text for Firefox, IE 10 and Safari users, add this to your site’s stylesheet:

p {
    -webkit-hyphens: auto;
    -moz-hyphens: auto;
    -ms-hyphens: auto;
    -o-hyphens: auto;
    hyphens: auto;

Right now the -o- prefix isn’t doing anything, but it future-proofs the code a bit for when Opera adds support. The only catch to hyphenation is that not only does the browser need to support it, it also needs to have a hyphenation dictionary for the language you’re using. The Mozilla Developer Network has a good rundown of which browsers support which languages.

There’s no real need for a fallback since the web has never had any hyphenation. Browsers that don’t support the CSS hyphens rule will simply render the page as they always have, but those that do will now be a bit more readable.

And, as a kind of footnote, if you have any interest in the future of publishing, Subcompact Publishing is well worth a read.

[Update: It looks like developer Peter Paul Koch just noticed hyphenation support as well. He’s got a short post that notes one potential problem with hyphens that I missed: you need to explicitly declare a language, as in <html lang="en"> in order to trigger hyphenation. See Koch’s post for more details.]

File Under: CSS, Web Standards

Use Tomorrow’s Web Standards Today With CSS ‘@Supports’

Woolly, the CSS sheep.

Using CSS 3 on the web today means that, inevitably, some browsers won’t be able to display some elements of your design. Hopefully you’re using progressive enhancement so that your pages still function in less-capable browsers, which might not understand all those fancy transform rules.

For more complex projects progressive enhancement might even mean turning to a feature detection library like Modernizr, which will detect and apply CSS classes based on the current browser’s capabilities.

Modernizr is great when you need it, but did you know that soon the browser itself will be able to give you the same information?

Both Opera 12.10 and Firefox 19 (currently in the Aurora channel) support native CSS feature detection through the CSS @supports rule. CSS @supports offers the same capabilities of Modernizr — selectively applying CSS based on what the current browser supports — but it does it through much faster native code. Even better, because browsers that don’t support @supports will just ignore it, you can start using it today.

Opera Software’s Chris Mills recently posted a nice intro to using @supports which you should read for more details, but here’s an example to illustrate the basic idea:

@supports ( box-shadow: 2px 2px 2px black ) {
    .my-element {
        box-shadow: box-shadow: 2px 2px 2px black;

The code above uses @supports to check for support for the box-shadow property and then applies a box shadow to browsers that will display it. Of course since many of the features you’d likely be detecting are still prefixed, a more complete example (pulled from the W3C’s @supports page) would look like this:

@supports ( box-shadow: 2px 2px 2px black ) or
          ( -moz-box-shadow: 2px 2px 2px black ) or
          ( -webkit-box-shadow: 2px 2px 2px black ) or
          ( -o-box-shadow: 2px 2px 2px black ) {
    .outline {
        color: white;
        -moz-box-shadow: 2px 2px 2px black;
        -webkit-box-shadow: 2px 2px 2px black;
        -o-box-shadow: 2px 2px 2px black;
        box-shadow: 2px 2px 2px black; /* unprefixed last */

Now we’re checking for not just box-shadow but any vendor-prefixed versions of it as well. We’re also not just applying box-shadow, but also changing the outline color to white, which (assuming a white background) would not be good to do in browsers that don’t support box-shadow since it would make the outline invisible to the user.

As you can see @supports is pretty handy for progressive enhancement and it avoids the overhead of loading a JavaScript library like Modernizr. CSS @supports also works with operators like not and or so that you could write a rule that says the opposite of what we did above. In other words, detect that the current browser doesn’t support box-shadow and do something else.

CSS @supports gets even more powerful when you start chaining @support rules together, which is what Mills does in his post on the Opera Dev center, detecting for animations and transforms to serve one thing to browsers that support 3D transforms, one to those that only understand 2D transforms and a third to those that don’t support transforms at all.

So should you ditch Modernizr and go with @supports? Probably not just yet, but soon. First off, if you’re using Modernizr for more than just CSS detection then obviously stick with it. But, as Opera’s Bruce Lawson notes in a follow-up to Mills’ post, “the reason to use @supports over Modernizr is performance; functionality that’s built into the browser will always be faster than adding it in script.” Getting rid of Modernizr would also mean eliminating an external dependency, which saves an HTTP request as well.

In fact Modernizr itself plans to defer to @supports in future releases. If you’d like to have the best of both worlds today, what you need to do is first detect for @supports and then if it’s not available load Modernizr. See Lawson’s post for a code snippet that does just that.

File Under: CSS, Frameworks, HTML, Visual Design

Bootstrap Framework Plans to Give Twitter the Boot

Web development toolkit Bootstrap is getting ready to part ways with Twitter. The open source project began life at Twitter, but with its two primary developers leaving Twitter for other companies, Bootstrap will be spun off on its own.

Bootstrap co-creators Mark Otto and Jacob Thornton are both leaving Twitter and have announced that Bootstrap will continue but as “its own open source organization.” For now nothing is changing; Bootstrap will remain a Twitter project on GitHub. But eventually the pair plan to give Bootstrap a life of its own.

The Bootstrap project is designed to help you get your website up and running as fast as possible. Somewhere between a framework and a “theme,” Bootstrap offers an HTML, CSS and JavaScript base for your designs, including built-in forms, buttons, tables, grids and navigation elements. Among Bootstrap’s more impressive tricks is the grid layout tool with support for advanced features like nested and offset columns. Bootstrap is also impressively lightweight, weighing in a just 10kb (gzipped).

Bootstrap 2.0, released earlier this year, added some much-needed responsive design tools for creating fluid layouts, including a new flexible 12-column grid system.

The move away from Twitter should be good news for Bootstrap users, particularly with Twitter’s increasingly hostile attitude toward developers. Otto assures anyone worried that Bootstrap will become abandonware that both he and Thornton are dedicated to Bootstrap. “The project has grown beyond us and the Twitter brand,” writes Otto on the Bootstrap blog. “It’s a huge project playing a pretty awesome role in the web development industry, and we’re excited to see it continue to grow.”

To see some real-world examples of what you can do with Bootstrap, head on over to the unofficial showcase, Built with Bootstrap on Tumblr.