All posts tagged ‘CSS 3’

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: Browsers

Google Chrome Speeds Up Fancy CSS Filter Effects

Meet Fuzzy Brown Monkey, WT Monkey's CSS Filter-laden cousin. Image: Screenshot/Webmonkey

CSS filters offer web developers some very powerful tools, powerful enough that it wouldn’t be too hard to create a web app capable of producing the kind of effect-laden photos popularized by Instagram. There’s just one problem: CSS Filters can be hard on the CPU.

Few things on the web get your PC’s fan spinning quite like CSS Filters — just give Google’s abstract painting demo page a try to see for yourself. Filters alone can send your fan spinning, but combine them with some CSS transitions or animations and you’ve got a recipe for battery draining excess.

That, combined with the fact that so far they only work in WebKit browsers, means right now you should use CSS Filters with caution.

Fortunately the roaring sound of your fan may soon be a thing of the past, at least for Google Chrome users. The Chromium blog reports that CSS Filters with GPU acceleration have landed in Chromium. It will be some time before the acceleration makes its way into the stable version of Google Chrome, but it is coming and that’s good news for the future of CSS Filters. Stephen White, a Software Engineer at the Chromium project, writes, “GPU acceleration of these filters brings their performance to the point where they can be used for animating elements in conjunction with CSS animations powered by -webkit-transition or even HTML5 video tags.”

It might be a while yet before Adobe launches a web-based version of its Premiere video editor, but expect other browsers to follow Chrome’s lead in supporting and speeding up CSS Filters.

It’s worth noting that, while the Instagram use case tends to get all the press, CSS Filters can do a lot more than just sepia toning images. In fact potential uses go far beyond just images or video. For example, CSS Filters could be used to blur backgrounds (or make them black and white) thus highlighting foreground content in online diagrams, charts or educational apps. CSS Filters could replace image sprites in navigation elements (less to download means faster page load times) and could also be used in conjunction with some animation to let users know that something on a page has changed.

For more info on CSS Filters, check out our earlier coverage and have a look at the HTML5Rocks site, which offers a nice overview of CSS Filters along with some example code.

Responsive Design Tricks: Fluid Typography With CSS 3

Photo: Ariel Zambelich/Wired.com

Building responsive websites means that your design has to adapt to different screen sizes. That there is no such thing as “pixel perfect” has long been a maxim of good web design, but nowhere is this more true than when you start working with percentage widths, em-based type and other flexible techniques of responsive design. While fluid grids, adaptive images and other tools help, sometimes even basic things like the flow of type can look wrong without a little extra help.

One common problem when designing for multiple devices is handling the changes that happen when the user rotates the screen. It’s frustrating to see your elegant portrait-oriented designs fall apart as the device moves to landscape mode (or vice versa). Frequently the problem is that images, videos and other embedded content in your page is sized in relation to the pixel width of the viewport, but the type is not. That means that the type fails to adapt to layout changes, leaving ugly gaps, whitespace or hard-to-read, overly long lines.

There are a number of ways to solve this problem, but one of the simplest and easiest is to use fluid typography in addition to your fluid grid. BBC developer Mark Hurrell wrote up an excellent tutorial some time ago that shows how, by specifying font sizes in rems, you can “adjust every font-size on the page by using media-queries to change the font-size set on the BODY or HTML element according to viewport width.”

To find the right size type for various screen widths, Hurrell calculates a resolution-independent font scale based on target widths. That is then applied using a series of media queries and the new CSS 3 unit rem. The rem unit means ems relative to the root (the HTML) element. That means your type gets proportionally larger overall, rather than in relation to its parent element as would happen with a simple em. As Hurrell notes, support is pretty much universal on tablets and phones (browsers that don’t support it will fall back to px sizing, so all is not lost).

In the end what you get using rems and media queries is fluid typography that scales just like a fluid grid. That means that when the device rotates the type resizes to fit the new screen dimensions. For more details on how to make it work on your site be sure to check out the Responsive News blog post, which also has a few links to websites already using this trick.

File Under: CSS, HTML, HTML5

‘HTML5 Please’ Helps You Decide Which Parts of HTML5 and CSS 3 to Use

Keeping track of the ever-evolving HTML5 and CSS 3 support in today’s web browsers can be an overwhelming task. Sure you can use CSS animations to create some whiz-bang effects, but should you? Which browsers support it? What should you do about older browsers?

The first question can be answered by When Can I Use, which tracks browser support for HTML5 and CSS 3. You can then add tools like Modernizer to detect whether or not a feature is supported, so that you can gracefully degrade or provide an alternate solution for browsers that don’t support the features you’re using. But just what are those alternate solutions and polyfills? That’s what the new (somewhat poorly named) HTML5 Please site is designed to help with.

HTML5 Please offers a list of HTML5 elements and CSS 3 rules with an overview of browser support and any polyfills for each element listed (CSS 3 is the much more heavily documented of the two, which is why the HTML5 emphasis in the name is perhaps not the best choice). The creators of the site then go a step further and offer recommendations, “so you can decide if and how to put each of these features to use.”

The goal is to help you “use the new and shiny responsibly.”

HTML5 Please was created by Paul Irish, head of Google Chrome developer relations, Divya Manian, Web Opener for Opera Software, (along with many others) who point out that the recommendations offered on the site “represent the collective knowledge of developers who have been deep in the HTML5 trenches.”

The recommendations for HTML5 and CSS 3 features are divided into three groups — “use”, “use with caution” and “avoid”. The result is a site that makes it easy to figure out which new elements are safe to use (with polyfills) and which are still probably too new for mainstream work. If the misleading name bothers you, there’s also Browser Support, which offers similar data.

If you’d like to contribute to the project, head over to the GitHub repo.

File Under: Browsers, CSS

Opera 12 Swaps Scrolls for Swipes With New ‘Opera Reader’

Alice in Wonderland gets the fancy paged-layout treatment in Opera 12

Opera software has released an experimental labs build of Opera 12 with support for what the company is calling Opera Reader.

Håkon Wium Lie, Opera Software’s CTO and creator of cascading stylesheets, previously proposed a new set of CSS tools that transform longer web pages into a more book-like experience, where the reader flips from page to page instead of scrolling down one long screen.

The new Opera Reader feature in Opera 12 is the first implementation of Lie’s proposed Generated Content for Paged Media standard. To try out the new Opera Reader and its book-like browsing experience, head on over to the Opera Labs site and download the latest build of Opera 12.

At its core, the Paged Media standard would offer web developers a way to paginate content — that is, take a single webpage and break it into multiple “pages,” with each page automatically fitted to the screen size of the device you’re using. For example, this article might be two “pages” when viewed on an iPad. However, because the pagination is done with CSS and the HTML remains as it is, there’s no added load time when you flip to the next page. So it’s not a tool that can easily be abused by publishers to mine extra pageviews. It adds all the good things about multi-page layouts and none of the bad.

If you’ve got Opera 12 installed, visit the new Opera Reader demo site where you can see some early experiments including the Alice in Wonderland demo shown above (note that the previous link only works in the latest build of Opera 12).

Keep in mind that this is an early version and so far the demos (and the browser support) are still very limited. Still, if you’d like to dive right in and learn how you can create book-like websites using the new Paged Media layout tools, check out the Opera Labs blog, which walks you through all the new CSS rules and how to use them.

See Also: