Archive for the ‘CSS’ Category

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: APIs, CSS, HTML, JavaScript

‘Tis the Season … To Write Better Code

The holidays are here and for web nerds that means only one thing — another wave of advent tutorials is hitting the web.

It doesn’t feel much like winter right now at the Webmonkey lair, but that’s okay because we mark the start of the holiday season by the launch of 24Ways, the grand poobah of advent calendars for web nerds. 24Ways has been an annual tradition since 2005, offering 24 articles packed with new tips and tricks showcasing some of the year’s best new ideas in web development.

This year’s 24Ways kicked off with a tutorial on HTML5 Video “Bumpers” by 24Ways founder Drew McLellan. Other articles thus far include how to start a project on the right foot, how to contribute code to the community and Geri Coady’s excellent article on Color Accessibility.

While 24Ways may be the biggest name in advent tutorials, it’s not lacking for competition these days. We also recommend the Performance Calendar, which tackles the often confusing world of website optimization. There’s also Digitpaint’s advent calendar which we enjoyed last year and has already published some nice articles this year, including this look at CSS filters.

If you’re missing another favorite, the PHP Advent Calendar, fear not, it has returned, but with a new name and domain: PHP Advent is now Web Advent. The name may have changed, but Web Advent offers similarly great content, like this article on Sharing What You Know by Heather Payne, the founder of Ladies Learning Code.

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, UI/UX, Web Standards

Create More Accessible Color Schemes With ‘Contrast Ratio’

Quick, easy contrast ratios. Image: Screenshot/Webmonkey.

Making websites accessible to users with disabilities — things like poor vision, blindness, limited dexterity — has been central to the mission of the web’s overseers since the dawn of the browser.

Following accessibility guidelines actually helps just about everyone, especially when it comes to making your site readable. And one of the cornerstones of accessibility is making sure your background and text colors have proper contrast ratio. But how do you know what’s a proper contrast ratio? For that turn to WCAG 2.0, a set of accessibility guidelines that most government and many private sector websites adhere to.

Unfortunately, while the W3C has plenty of guidelines for building the web, it’s not in the business of creating tools to go with them, which means bringing the guidelines into the real world can sometimes be a hassle. That’s why developer Lea Verou built this awesome contrast ratio tool. Verou works for the W3C (though the tool is not an official W3C project) and needed a way to ensure that her color choices passed WCAG muster. That’s exactly what the contrast ratio tool does: give it any form of CSS color — hex, rgb(), rgba(), hsla(), etc — and it will automatically calculate the contrast ratio and let you know which level of the WCAG guidelines your contrast meets.

Verou’s contrast calculator even accepts semi-transparent colors for sites using overlays. To make the semi-transparent colors work Verou had to write her own algorithm. For semi-transparent backgrounds, the WCAG contrast ratio is presented with an error margin, since the actual contrast can vary depending on what’s under your semi-transparent overlay.

The contrast ratio tool supports all modern browsers and has “basic support for IE9.” The code is available on GitHub.

Also worth noting is Verou’s blog post on accessibility and contrast ratios. Like many of us, Verou “used to think that WCAG-mandated contrast ratios were too restrictive and basically tried to force you to use black and white.” The truth is, as Verou writes, “in practice, I found that in most cases they are very reasonable: When a color combination doesn’t pass WCAG, it usually is hard to read.”