The future is coming fast on the web and if you want your sites to keep up you have to stay a little ahead of the curve. Sometimes that means using new HTML and CSS features before every web browser fully supports them. So how do you know which browser supports which features? Thanks to CSS 3's new @supports rule you can just ask the browser.

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:

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:

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.

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.

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.

A new website helps web developers decipher the often confusing world of HTML5 and CSS 3. Which elements are ready to use? Which are still not widely supported? And where can you find polyfills and fallbacks for older browsers? HTML5 Please has your answers.

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.

Opera Software has released an experimental version of its web browser with support for the company's new "paged media" proposal. Opera Reader, as the feature is known, transforms websites into something more akin to books and magazines where you can flip "pages" rather than scrolling.

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.

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.

Amazon’s new full-color Kindle Fire tablet will arrive next month and with it will come a new e-book format that uses web standards to take advantage of the Fire’s new and improved features. The new format, Kindle Format 8 (KF8), uses HTML5, CSS 3 formatting rules, embedded custom fonts and SVG graphics to create a […]

The new Kindle Format 8 uses HTML5 and CSS for better looking books and graphic novels

Amazon’s new full-color Kindle Fire tablet will arrive next month and with it will come a new e-book format that uses web standards to take advantage of the Fire’s new and improved features.

The new format, Kindle Format 8 (KF8), uses HTML5, CSS 3 formatting rules, embedded custom fonts and SVG graphics to create a richer toolset for book designers. It also means that if you can build a website, you can build a book.

KF8 isn’t the first e-book format to use HTML under the hood. Both EPUB and Mobi — the current Kindle format — are both built on HTML, but KF8 will be the first to embrace nearly all of HTML5 and its associated tools like CSS 3 and SVG.

With KF8 e-book designers can use the same tools web designers have long relied on to handle richer layout options like sidebars, pull quotes, callouts and other common print design elements that don’t translate well to the limited options of current e-book formats. The new tools will be particularly useful for creating better visuals in children’s e-books and graphic novels.

Interestingly, by making it possible to create e-books using the same tools you’d use to create a website, Amazon may be inadvertently making the web the new home of e-books. So far Amazon hasn’t released many specifics surrounding its KF8 format, but if KF8 is essentially a wrapper around HTML5 and CSS 3 then presumably it won’t be too hard to strip away that wrapper. What would be left behind will likely be a “e-book” that’s really just a single page of HTML and CSS — perfect for the web.

Whether or not such an easy dual publishing route is actually possible will be clearer when Amazon releases its updated Kindle Publisher Tools. Amazon hasn’t set a date yet, but you can sign up to be notified when the new tools are available.

Amazon’s Kindle Fire will be the first Kindle to support the new KF8 format, but according to Amazon support for KF8 in the new e-ink Kindles and the various Kindle apps will be added “in coming months.”

One of the best things about CSS 3 is that it reduces the need to use images in your designs. That means fewer HTTP requests, few bytes to download and fewer files to keep track of. Need rounded corners? That’s pure CSS now. How about drop shadows? Yes, pure CSS. The infinity symbol? Actually yes, […]

One of the best things about CSS 3 is that it reduces the need to use images in your designs. That means fewer HTTP requests, few bytes to download and fewer files to keep track of. Need rounded corners? That’s pure CSS now. How about drop shadows? Yes, pure CSS. The infinity symbol? Actually yes, you can draw the symbol for infinity with nothing more than a few lines of CSS.

The web developers over at CSS-Tricks have put together a page showing off the basic shapes you can create using only a single HTML element and all the CSS you can eat. Everything from the obvious, squares and circles, to the somewhat trickier five-pointed star or infinity symbol (contributed by developers Kit MacAllister and Nicolas Gallagher respectively).

If you need to add some basic shapes to your site, but don’t want the overhead of image files, the code on CSS-Tricks might fit the bill. The page has been up for some time now, but it’s periodically updated with new shapes so it’s worth adding to your bookmarks. You should, however, keep in mind that not all of the code works in every web browser.

The developers behind HTML5 Boilerplate have released version 2.0 of their boilerplate HTML, CSS and JavaScript templates for quickly prototyping HTML5 designs. You can grab a copy of HTML5 Boilerplate v2.0 from the HTML5 Boilerplate website. Version 2.0 of HTML5 Boilerplate has several significant changes, including ditching the traditional reset stylesheet for normalize.css. Normalize is […]

Version 2.0 of HTML5 Boilerplate has several significant changes, including ditching the traditional reset stylesheet for normalize.css. Normalize is a bit different in that it retains useful browser defaults and only resets those elements necessary to achieve cross-browser default styling consistency. It’s a minor point, but my favorite part of normalize.css is that it doesn’t litter your dev tools (Firebug, WebKit Inspector, etc) with endless reset rules.

Other new features in HTML5 Boilerplate include support for Respond.js (which helps if your site uses a "mobile first" approach), faster build times (up to 80 percent faster according to the release notes) and, with v2, your IE 6 visitors will now be prompted to install Chrome Frame.

For more details on everything that’s new in HTML5 Boilerplate v2, head on over to the official site and read through the changelog. Perhaps the most refreshing thing about this release, is this note in the FAQs:

Do I need to upgrade my sites to a new version?

Nope. So far there have been no critical bugs within our code that we’ve fixed from version to version. There are some nice changes that reduce your stress, but updating your HTML or CSS to the new stuff is probably more effort than it’s worth.

However, the .htaccess and Build Script you probably didn’t edit and therefore can be dropped into your existing sites with little hassle and likely a significant reward. So feel free to update those, and also update your Modernizr and jQuery versions to the latest versions they have.

It’s cold here in the Webmonkey offices, Adobe has unveiled a web browser. No, Adobe isn’t really getting into the web browser game, but it does have a few tricks it would like to show off to the world. Adobe’s new demo web browser exists solely to demonstrate the company’s proposed CSS Regions layout tool. […]

It’s cold here in the Webmonkey offices, Adobe has unveiled a web browser. No, Adobe isn’t really getting into the web browser game, but it does have a few tricks it would like to show off to the world. Adobe’s new demo web browser exists solely to demonstrate the company’s proposed CSS Regions layout tool.

If you’d like to check out the demo browser, head over to Adobe Labs and download a copy. Be sure to open up the included sample pages to see how the HTML and CSS is structured.

Adobe has been working on CSS Regions for some time, trying to develop a set of CSS layout tools that make it easy to build complex, print-style layouts on the web — think text that flows around circular regions, or text structured into shapes. If Adobe can convince browser makers and the W3C to get onboard with the idea, web design might be about to make a huge leap forward. Or backward, depending on how you look at it.

Adobe’s CSS Regions proposal is a back-to-the-future effort to bring some of the layout tools print designers have enjoyed for years to the web.

Typography on the web has improved by leaps and bounds since the dark days of the blink tag and six universal fonts, but it’s still a long way from ideal. Sure there are great ways to serve custom fonts, and you can even use JavaScript libraries like Lettering.js for even more control over your layout. But when it comes to the flow of text around images, pull quotes and other block level elements, well, web typography falls apart.

While web developers have hacked together grids and other print-style layout tools for years, such tools are essentially hacks and limited in their capabilities. But that will change in the near future. The W3C is currently toying with no less than four new grid-based standards designed to handle multi-column text, wrapping text around images and other fancy layout techniques. We’ve looked at the Flexible Box Model, Template Layout (based on Mozilla’s XUL syntax), and Grid Positioning modules before, but so far none are finalized.

CSS Regions shares some similarities with the other proposals (and from what I can tell would play nice with them if multiple proposals end up becoming finalized specs), but goes a good bit further, by abstracting sections of an HTML page into “regions.”

Regions can be both positive and negative space. In other words, you can write CSS rules to flow text into a region — say, as below, a pie graph — or around a region (as in the image of Arches National Park at the top of this post).

Inserting text into regions

Among the interesting layout tools in the CSS Regions proposal are Story Threading, Region Styling and the arbitrary shapes and exclusions concept. Story Threading allows text to flow in multiple disjointed shapes (not just columns) which you can define in CSS and HTML. That means you could easily flow two side-by-side columns of text around an image or a pullquote the way print magazines often do.

The second interesting element is Region Styling, which allows content to be styled based on the region it flows into. For example, if the first few lines of your text fall into one region, you could style it with a different font than the rest, which falls in a different region. Curiously, this part of the proposed Regions spec is not currently implemented in Adobe’s demo browser.

The arbitrary content portion of the draft spec is what allows the layout shown in the screenshots above — flowing content into or around arbitrary shapes.

Lest you think that Adobe is simply trying to improve the web — which may well be true — nevertheless, it’s worth bearing in mind Adobe’s own agenda. We suspect it’s no accident that the company has used WebKit to power the CSS Regions testing browser. WebKit is, after all, the engine that powers the iPad’s web browser.

With Apple banning Flash from its iOS devices, Adobe has little in the way of iPad-friendly tools to offer its big magazine clients. Given that publishers are betting heavily on the iPad’s ability to save their business model, the more iPad tools Adobe can offer, the happier magazine publishers will be. By rolling CSS Regions into WebKit for a demo, Adobe is already one step closer to a toe-hold on iOS devices.

Still, in this case, assuming the W3C pushes forward with the Regions spec, and that browser makers include support in future releases, what’s good for Adobe may end up being good for the web as a whole.

Of course whether or not multi-column layouts on the iPad (or any other web browser) are a good idea is open to debate. Multiple columns combined with scrolling often makes for a reading nightmare. Certainly in the hands of poor designers the results will be ugly, but that doesn’t mean the tools themselves are to blame.

]]>http://www.webmonkey.com/2011/05/adobe-envisions-brave-new-world-of-web-layouts-with-css-regions/feed/10CSS 3 Brings Iconic Mad Men Titles to Life on the Webhttp://www.webmonkey.com/2011/05/css-3-brings-iconic-man-men-titles-to-life-on-the-web/
http://www.webmonkey.com/2011/05/css-3-brings-iconic-man-men-titles-to-life-on-the-web/#commentsWed, 04 May 2011 15:00:32 +0000Scott Gilbertsonhttp://www.webmonkey.com/?p=50838

Web developer Anthony Calzadilla has recreated the opening title sequence of AMC’s Mad Men using only CSS 3 animations and some carefully crafted images. The result is an impressive showcase of what you can do with the animation powers available in CSS 3. Head on over the official Mad Manimation demo and click the “Watch” […]

Web developer Anthony Calzadilla has recreated the opening title sequence of AMC’s Mad Men using only CSS 3 animations and some carefully crafted images. The result is an impressive showcase of what you can do with the animation powers available in CSS 3.

Calzadilla points out that the not-yet-released Animatable would have made the staging and animating process easier. Animatable looks impressive — an online IDE for CSS 3 animations — but sadly it’s not available to the general public just yet. You can see a preview of the project in this video.

And just to head off the Flash fans who will note that they could have built the Mad Manimation demo in 1995 using only gotoAndPlay() and some duct tape, sure, we all know that, but the web has moved on.