Archive for the ‘CSS’ Category

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.

Drink in the Responsive Grid With ‘Bourbon Neat’

CSS grid frameworks are awesome. They simplify development, eliminating a ton of math and letting you focus on what makes your site your site rather than the underlying structure.

Sadly, it’s nearly impossible to create a reusable, responsive grid that doesn’t litter your HTML with grid-specific class names. Even if the non-semantic class names don’t bother you, there’s no getting around the fact that it’s a pain to update and maintain that code.

The solution is to step back from the CSS and turn to a CSS pre-processor like SASS.

That’s what Bourbon Neat does to create one of the easiest to use SASS-based fluid grid systems we’ve come across. The clever name comes from the fact that Neat relies on the Bourbon SASS library and extends it to create a fluid, em-based grid framework.

The project was created by the developers at Here’s what the docs have to say:

Why another grid framework?

Because we are not happy with other frameworks. We built Neat with the aim of promoting clean and semantic markup; it relies entirely on SASS mixins and does not pollute your HTML with presentation classes and extra wrapping divs.

Using SASS 3.2 block mixins, Neat makes it extremely easy to build responsive layouts… Using the breakpoint() mixin, you can change the number of columns in the grid for each media query and even store these values in project-wide variables to DRY up your code.

To give it a try, just install Neat and its dependencies and check out the guide to using Neat over on GitHub. Be sure to look over the example page to get an idea of what you can do with Neat and how it works. If you’re a Rails developer there’s a Neat gem you can install.

The power of Bourbon Neat lies in some new features in SASS 3.2, namely block mixins, which allow you to use the @mixin syntax to “name” media queries. To see how Bourbon is using that feature, check out the source code on GitHub.

File Under: CSS, Web Standards

Adobe’s CSS Shaders Now an Official W3C Editor’s Draft

Adobe’s CSS Shaders proposal, which will bring high-quality cinematic effects to the web through some new CSS tools, has been accepted by the World Wide Web Consortium (W3C).

That means CSS Shaders will become a web standard, though not on their own; instead the W3C is going to roll CSS Shaders into the CSS Filter Effects specification. The feature formerly known as Shaders will now be referred to as Custom Filters

The original name “Shader” has its roots in the 3-D graphics world and roughly describes what “Custom Filters” will do, namely create 3-D effects, like the rippling motion in a waving flag, by “shading” regions.

In the end the name isn’t that important; just know that Custom Filters will allow web developers to easily apply cinema-style filter effects to any HTML content. Think grayscale-to-color transitions, animated shadows, photo-realistic warping and other mainstays of the 3-D animation world.

You’ll still need a special build of WebKit that Adobe put together to see Custom Filters in action. You can grab the experimental browser from the GitHub page, where you’ll also find plenty of examples and sample code that show how shaders, er, Custom Filters work. Also be sure to check out Adobe’s earlier write-up on how Filters work and how you can use them.

Now that Shaders are an official part of CSS, hopefully web browsers will begin adding support.

[Update:The original title of this post was Adobe’s CSS Shaders Now an Official Web Standard, wherein I intended “Official Web Standard” to mean “a part of the web standards process”, not actually a published W3C recommendation. Judging by the comments that’s how most of you took it, but of course it was definitely possible to read it as something more than it actually is, so the headline has been updated to clarify that point.]

File Under: CSS

W3C Hammers Out the Details of CSS Variables

The W3C’s CSS Working Group, the standards body that oversees the CSS specification, is getting closer to defining one of CSS’s most requested features — CSS Variables. However, if you’ve been dreaming of SASS or LESS style power without the preprocessor, the new CSS Variables draft might leave you scratching your head.

Variables used to be one of the most requested features for CSS, particularly from programmers accustomed to languages with variables. But, between then and now, CSS preprocessors like SASS and LESS have largely filled the role by offering variables (and more). Still, SASS and LESS are not CSS.

By the same token, what’s being proposed under the name CSS Variables is not what most developers would think of as a variable. Daniel Glazman, co-chair of the W3C CSS Working Group, calls the new variables “Inherited User-Defined Properties.”

In fact what is being proposed are custom properties which use a function to access the value of the properties later — more of a Mutator getter/setter pair than a directly accessible variable.

When variables were first proposed many assumed the syntax would look something like SASS or LESS, roughly like this:

$foo = myvalue;

/* and then */
.selector {
    color: $foo;

We showcased the actual syntax back when WebKit first landed preliminary support for variables, but here’s a quick refresher:

:root {
    var-header-color: #06c;
h1 { background-color: var(header-color); }

The first rule is the new variable syntax and defines a property named “var-header-color” on the root element. Then you can then access that value throughout your stylesheets with the var(header-color) syntax.

Why not use the more familiar PHP-like “$var” syntax? For one thing this proposal makes it easier to understand the cascade. See Glazman’s blog for more details on how variables will inherit. Tab Atkins Jr, a Google representative at the CSS Working Group, explains another reason to switch to the new syntax: “If we use $foo for variables, we’ll be unable to use it for future ‘variable-like’ things.”

So what are “variable-like” things? Atkins continues:

For example, if we do define an alternate form that are more SASS-like (can be used anywhere, but are global; more “macros” than “variables”) we’d have to use some other glyph for them. That’s suboptimal. More specifically, if we ever do some sort of “variables” in selectors, we must use a compact form like $foo or something. Anything else is unusable, I believe.

So we have our variables in CSS, but with a syntax that’s not quite the way many developers wanted it. As Glazman writes, “Before shouting, don’t misunderstand us: we clearly see the simplicity, readability and maintainability of the $foo syntax… we do understand why Web Authors prefer a compact and simple notation like $foo but we have decided it comes at a too expensive cost right now.”

If you’re really put off by the new syntax, take comfort in the fact that the variables draft remains just that — a draft spec. Glazman and Atkins both leave the door open to adding $foo style variables back to the spec. As Atkins writes, “If we don’t find anything that needs this kind of syntax, then we can go back to letting Variables consume this kind of syntax for its own use.”

File Under: CSS

Safari, Chrome Ship Proposed High-Resolution Image Solution

The WebKit project recently added experimental support for the proposed CSS level 4 image-set specification. Image-set is designed to offer web developers a way to target high-resolution screens, solving one of the design challenges of Apple’s Retina displays.

Both Safari 6 and Chrome 21 support image-set with vendor-prefixes and developer Jason Grigsby has put together a test page over at Cloud Four, where you can see the new image-set in action.

The syntax will look something like this:

#selector {
        background-image: url(no-image-set.png); 
        background-image: -webkit-image-set(url(myimage.jpg) 1x, url(myimage-hires.jpg) 2x);
        /* other prefixes for -moz, -o and -ms go here */

[Update: I’ve removed the unprefixed version in the above example. As Peter Linss, CSS Working Group Co-Chair, writes in a comment on Grigsby’s post, “It’s fine to try out experimental features on non-production web sites, and reasonable to try to anticipate other vendor’s experimental implementation… But putting a non-prefixed version of a property or value (as in this case) into any style sheet when the feature does not even exist in an official working draft of a specification, let alone in any kind of stable form, is flat out wrong.”]

That may look a bit odd since the prefix is on the property value instead of the property itself, but the basic syntax is pretty straightforward. These rules tell the browser to use myimage.jpg if the pixel density of the screen is 1x and myimage-hires.jpg if the pixel density is 2x.

The big question is why would you want to use image-set instead of media queries, which could accomplish nearly the same thing?

As Grigsby points out, one of the big advantages of image-set is that it doesn’t tell a browser which image to use, it just provides options. That leaves the door open to situations where a screen may be high-res, but the browser is smart enough to know when it’s on a slow network and thus still opt for the lower-resolution image.

For some more details on the syntax and to see it in action head on over the Cloud Four blog, though note that you’ll need either Safari 6 or Chrome 20+ to see image-set in action. It’s also worth noting that image-set is still just a proposal and not yet an official part of the CSS 4 spec. Things could and most likely will change, so proceed with caution in your work.