Skip navigation
Help

CSS

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.
Original author: 
Scott Gilbertson

Look Ma, no floats! Image: Abobe

HTML5 and CSS 3 offer web developers new semantic tags, native animation tools, server-side fonts and much more, but that’s not the end of the story. In fact, for developers slogging away in the web design trenches, one of the most promising parts of CSS 3 is still just over the horizon — true page layout tools.

While it’s possible to create amazingly complex layouts using tools like CSS floats, positioning rules and the odd bit of JavaScript, none of those tools were actually created explicitly for laying out content, which is why it’s amazingly complex to get them working the way you want across browsers.

Soon, however, you’ll be able to throw out your floats and embrace a better way — the CSS Flexible Box Model, better known as simply Flexbox. Flexbox enables you to create complex layouts with only a few lines of code — no more floats and “clearfix” hacks.

Perhaps even more powerful — especially for those building responsive websites — the Flexbox order property allows you to create layouts completely independent of the HTML source order. Want the footer at the top of the page for some reason? No problem, just set your footer CSS to order: 1;. Flexbox also makes it possible to do vertical centering. Finally.

We’ve looked at Flexbox in the past, but, unfortunately the spec has undergone a serious re-write since then, which renders older code obsolete. If you’d like to get up to speed with the new syntax, the Adobe Developer Blog recently published a guide to working with Flexbox by developer Steven Bradley.

Bradley walks through the process of using Flexbox in both mobile and desktop layouts, rearranging source order and elements to get both layouts working with a fraction of the code it would take to do the same using floats and other, older layout tools. The best way to wrap your head around Flexbox is to see it in action, so be sure to follow the links to Bradley’s demo page using either Chrome, Opera or Firefox 20+.

For some it may still be too early to use Flexbox. Browser support is improving, but obviously older browsers will never support Flexbox, so bear that in mind. Opera 12 supports the new syntax, no prefix necessary. Chrome supports the new syntax, but needs the -webkit prefix. Like Opera, Firefox 20+ Firefox 22 supports the unprefixed version of the new spec. Prior to v22 (currently in the beta channel), Firefox supports the old syntax. IE 10 supports the older Flexbox syntax. Most mobile browsers support the older syntax, though that is starting to change. [Update: Mozilla developer Daniel Holbert, who is working on the Flexbox code in Firefox, wrote to let me know that the Flexbox support has been pushed back to Firefox 22. Actually the new Flexbox syntax is part of Firefox 20 and up, but until v22 arrives it's disabled by default. You can turn it on by heading to about:config and searching for layout.css.flexbox.enabled pref. Set it to true and the modern syntax will work.]

So, as of this writing, only two web browsers really support the new Flexbox syntax, though Firefox will make that three in the next month or so.

But there is a way to work around some of the issues. First off, check out Chris Coyier’s article on mixing the old and new syntaxes to get the widest possible browser support. Coyier’s methods will get your Flexbox layouts working in pretty much everything but IE 9 and below.

If you’re working on a personal site that might be okay — IE 9 and below would just get a simplified, linear layout. Or you could serve an extra stylesheet with some floats to older versions of IE (or use targeted CSS classes if you prefer). That defeats some of the benefits of Flexbox since you’ll be writing floats and the like for IE, but when usage drops off you can just dump that code and help move your site, and the web, forward.

0
Your rating: None
Original author: 
Scott Gilbertson

Photo: Ariel Zambelich/Wired.com

Building responsive websites means that your design has to adapt to different screen sizes. We’ve covered a number of ways to do that in the past, including working with percentage widths, em-based type and other flexible techniques of responsive design.

There’s another way to achieve flexibility that doesn’t involve keeping track of ems or percentages — the new CSS REM unit. REMs are just like ems — REM stands for Root Em — but instead of being relative to the parent element like Ems, REMs are relative to the document root’s font size. Most of the time that means the html element.

We’ve previously looked at REMs as a way to achieve fluid typography, but REMs can help with more than just type sizing.

Mobify’s Roman Rudenko has an article on CSS-Tricks that shows how to use REM units to scale specific page elements while leaving others unaffected. Rudenko even shows how you can use REM units as a replacement for the very powerful, but not very well supported, viewport width unit.

For those wondering why you might want to resize some elements and not others, here’s Rudenko’s use case:

This style of sizing can be useful for user-driven customization, or to adapt layouts for cases that require secondary elements to be more touchable (tablet) or visible (TV). Without REM, every adjustable element would have to be resized separately.

This technique can be applied to whole pages as well. For example, if your type is all sized in REMs and you want it to be a bit larger as screen sizes get bigger, all you need to do is adjust the font size on the html element with each media query and all your REM-sized type will get bigger based on that single line of code.

For more on REMs and what you can do with them be sure to check out Rudenko’s post and our earlier write up.

0
Your rating: None

Adobe’s proposed text-balance rule (right) versus no balancing (left). Image: Screenshot/Webmonkey.

Adobe is continuing its effort to bring better typography to the web with a new proposal for what the company is calling “Automatic Text Balancing.” If browsers adopt text balancing it could mean the end of typographic unsightliness like widows, orphans and ragged lines, and would go a long way to creating more readable text on the web.

Adobe’s proposal is based on Adobe InDesign’s “Balance Ragged Lines” feature, and works a bit like justifying text except that instead of expanding text with ugly spaces between words, the algorithm would adjust line lengths to “balance” text for easier reading.

Adobe’s Randy Edmunds outlines the basic idea behind automatic text balancing on the company’s Web Platform Blog. Essentially text balancing would mean eliminating widows (single words pushed to a new line), and also automatically presenting text so that it’s even wrapped instead of a long line followed by a shorter line.

Here’s how Edmunds and Adobe see text balance working:

I propose we use a text rendering algorithm that would be applied by browser when asked by the designer to do so to automatically balance text across multiple lines, like so:

h1 {
  text-wrap: balance;
  }

This would make all h1 elements whenever they span more than one line to be automatically rendered such that they have balanced text. As you notice, I only propose an additional value to the existing text-wrap property of CSS.

If accepted by the W3C, Adobe’s text balance proposal would add a new balance value to the proposed CSS text-wrap rule. The text-wrap property was originally part of the CSS 3 spec, but has since been removed and remains in flux.

Adobe has already created a jQuery plugin polyfill that implements the proposed text balance algorithm. You can grab the code from GitHub. There’s also a sample page where you can see the jQuery text balancing in action. (Be sure to resize the window to see the reflow difference between balanced and unbalanced text.) There’s also an ongoing discussion on the CSS WG mailing list if you’d like to dig into the details.

0
Your rating: None

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.

0
Your rating: None

A handful of the many screens your responsive designs must handle. Photo: Ariel Zambelich/Wired.com

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.

0
Your rating: None

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.

0
Your rating: None

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.

0
Your rating: None

Stopwatch in CSS 3, no JavaScript necessary. Image: Screenshot/Webmonkey

Five years ago the hotness in web development was showing what you could create without resorting to Flash. Now it seems the same is true of JavaScript. While we’ve nothing against JavaScript, the increasingly powerful tools in CSS 3 mean that JavaScript is no longer a necessity for building cool stuff on the web.

The latest JavaScript-free demo we’ve run across is this very cool stopwatch demo made using only CSS 3, no images or JavaScript necessary. Now before you dive into the code and get all Karl Van Hœt on us, yes, there is a script used to handle CSS prefixing, but the actual stopwatch doesn’t require it to work.

But what caught our eye even more than the JavaScript-free stopwatch demo is the tutorial that accompanies it. The tutorial — which is one part screencast and one part code dump — is part of Code Player, which helps you learn how to do things by showing you the code as it’s written. It’s an interesting tutorial method, one we haven’t seen before.

Watching code being written isn’t for everyone, especially beginners who might not be able to easily follow what’s happening, but it’s well suited to those that already understand the basics and just want to see how some particular function was written. It also provides an interesting look at how other developers work, which in turn might teach you a new trick or two.

The Code Player offers a variety of playback speeds depending on how fast you want to run through the tutorial, and there’s a timeline scrubber for pausing and rewinding any bits you miss. Our only complaint is that Code Player forces focus in the browser; when you try to click another tab or do something in the background Code Player steals focus back immediately.

If learning something new by watching someone else type sounds intriguing, head on over to the Code Player site. And don’t worry if the stopwatch demo has no appeal for you, there are plenty of other tutorials to choose from.

0
Your rating: None

The high-resolution web is coming. Photo: Ariel Zambelich/Wired

Given enough time, all simple, already solved problems of the web eventually rear their ugly heads again.

Remember when limited bandwidth was a huge problem? Then bandwidth was infinite. Now it’s a problem again. And that means serving up images is once again a complex problem with no elegant solution. Its seems simple. Websites should serve the right image to the right screen, high-resolution images to high-resolution devices and low res to the rest. But of course it’s not that simple. Factors like bandwidth as well as screen size and orientation complicate the matter considerably.

Arguably the best solution right now is to send low-res images to every device. Sure, your images might look terrible on high-res screens, but at least you aren’t wasting people’s time or worse, costing them money.

While that’s the safest solution for now, the web doesn’t get better if no one takes any risks. Fortunately, until some standard or best practice emerges, we’ll likely continue to see developers pushing the boundaries and discovering new ways to handle the seemingly simple task of serving the appropriate image to the appropriate device.

The latest image cleverness we’ve seen is Adam Bradley’s Foresight.js. Foresight.js is designed to make it easy to serve up high-resolution images to devices like the new iPad, but what sets foresight.js apart from half a dozen other solutions that do the same thing is that it not only checks for a hi-res screen, but also checks to see if the device currently has a fast enough network connection for larger images. If, and only if, your visitor has both a device capable of displaying high-res images and a network connection fast enough to handle the larger file size, are larger images served.

Part of what makes Foresight.js appealing is its use of the proposed CSS image-set() function, one possible solution to the problem of serving up the right image at the right time. The image-set() function, which works in WebKit nightly builds and is under consideration by the W3C, looks like this:

myselector {
    background: image-set(url(foo-lowres.png) 1x, url(foo-highres.png) 2x) center;
}

Foresight.js takes the image-set() proposal and uses an ingenious hack to make it work in other browsers: the font-family property. Yes, it sounds crazy. But it works and remains technically valid CSS because font-family allows for arbitrary strings (to handle font names). That means browsers have no problem with a rule like this:

myselector {
    font-family: ' image-set( url(/images/foo.png), url(/images/foo_2x.png) 2x high-bandwidth ) ';
}

It’s a hack to be sure, but it’s our favorite kind of hack: clever and functional. Because browsers successfully parse the font-family rule (even if they can’t apply it) the value is added to the DOM and JavaScript has no problem accessing it, which is exactly what foresight.js does.

For more on foresight.js, head over to the GitHub page which as links to plenty of examples uses and copious documentation on the script’s many tricks. Also be sure to read through Bradley’s Challenges for High Resolution Images, which offers some background on foresight.js and the design decisions he made.

0
Your rating: None

A handful of the many screens your site needs to handle. Photo: Ariel Zambelich/Wired.com

Responsive design means making your website readable no matter what screen it might be on. In the words of karate master Bruce Lee, “Don’t get set into one form, adapt it and build your own, and let it grow, be like water.” Lee may have been talking about your mind, but his words apply just as well to your website. To paraphrase the rest of that quote, you put water into a cup, it becomes the cup; so, you put your content on a tablet, it becomes the tablet; you put it on a TV, it becomes the TV.”

On a more practical level, achieving a Bruce Lee-like command of the fluid web means ditching the pixels and points for flexible units like ems or percentages. There’s a lot more to responsive design than just fluid layouts, but it’s definitely a key part of the process.

Curiously, when it comes time to use the other universal element of responsive design — the @media query that applies the actual responsive design — most of us revert right back to pixels with something like @media all and (min-width: 500px) {}. It seems logical; after all, you’re trying to fit your content into a window with specific dimensions, so why not use pixels?

Certainly you can, and most sites we’ve seen up to this point use pixels for the actual media query breakpoints, but it’s worth noting that you can use ems here as well.

Lyza Gardner over at Cloud Four recently posted a look at why Cloud Four’s new responsive design uses ems in its media queries. Here’s her reasoning for Cloud Four’s em-based approach:

Folks who design for traditional reading media — where the content really is king — don’t center design decisions around the absolute width of content-holding elements so much as around the optimal line lengths for the content they’re flowing. There are some tried-and-true numbers one can shoot for that make for the “right” number of letters (and thus words) per line for comfortable human reading.

Thus actual column width is a function of font size and ems-per-line.

The rest of the post walks through how Cloud Four used em-based media queries to create a better navigation experience on their site. Some of the advantages may not apply to every responsive design, but there is one additional benefit that works nearly everywhere — em-based media queries mean that your site will handle user zooming much better, applying media queries instead of allowing content to overflow its container.

But perhaps the best part of an em-based approach is that it seems to work in nearly every web browser. Cloud Four’s post doesn’t get into the specifics of their browser testing so I fired up a couple of virtual machines and tested their site and my own simplified demo page in every major browser.

According to my testing, em-based media queries work properly in all OS X browsers. (I tested the latest versions of Safari, Firefox, Chrome and Opera.) Only Firefox and Opera apply media queries on zoom, though. (Chrome and Safari need a page refresh before the query is applied.)

On Windows 7 Firefox, Opera and Chrome behave the same way they do on OS X. IE 9 also worked fine and, like Firefox and Opera, applies media queries when zooming without needing a page refresh. Judging by the comments on the Cloud Four blog, Chrome on Linux may have some issues, but in my testing Firefox and Chrome on Fedora worked as expected.

All the mobile browsers I tested on Android worked as well (Firefox, Chrome, Opera Mini and the default Android browser). On iOS Mobile Safari applies em-based queries as you would expect.

In the end you certainly don’t need to use em-based media queries. As many sites out there demonstrate, pixel-based queries work. At least for now. However, as a wider range of screen sizes begin to access the web switching to em-based queries may put you ahead of the game. Em-based queries mean addressing the content-width rather than just the screen width and that feels like a more future-friendly approach.

0
Your rating: None