All posts tagged ‘CSS’

File Under: CSS, Web Standards

It’s Official, CSS Media Queries Are a Web Standard

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

The W3C, the group charged with overseeing the creation of web standards like HTML and CSS, has given its official blessing to one of the cornerstones of responsive web design — CSS Media Queries.

Media queries allow web developers to change the layout of a page based on the media that’s displaying it — whether that means adapting it to fit a smaller screen or just stripping it down to the essentials before it heads to a printer.

Chances are you’ve been using at least the print media query on websites for ages, but now media queries have gone legit, becoming an official W3C recommendation (and yes, that is as strongly-worded as the W3C ever gets).

That may not mean much for developers who long ago embraced media queries to serve print stylesheets, but making media queries a recommendation means web browsers need to support it. The backing of the W3C is also often a requirement before large corporate or government organizations will even consider “new” ideas like responsive web design.

Media queries are the cornerstone of responsive design, which, at its simplest, just means building websites that work on any device. That way, when a dozen new tablets suddenly appear on the scene — Microsoft Surface anyone? — you can relax knowing your site will look and perform as intended, no matter which devices your audience is using.

Indeed while Microsoft’s new tablet isn’t yet storming the web, if you’ve been using media queries and following the best practices of future-friendly design then you don’t need to worry when the Surface finally does start showing up in your server logs.

File Under: CSS

CSS Variables: WebKit Brings the CSS Jackalope to Life

The mythical Jackalope surrounded by CSS bunnies. Image: Wikimedia

The mythical beast known as the CSS Variable is about to be released into the wild.

The WebKit team, which builds the browsing engine that powers both the Safari and Chrome web browsers, recently landed preliminary support for CSS Variables, which means variables will likely turn up soon in Chrome/Chromium and Safari nightly builds.

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, and do require compiling, so there may still be a place for variables in CSS.

There’s nowhere to actually test out CSS variables yet, but you can read up on the proposed variable syntax at the W3C. The spec is currently a working draft and may change considerably before it is finalized, but the proposed syntax looks like this:

: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 use that variable throughout your stylesheets with the var(header-color) syntax. Also note that you can use variables within variables like this:

:root {
    var-my-color: #06c;
    var-background: linear-gradient(left, var(my-color), white);
}

There are some more examples of how to use variables on the W3C page, as well as in WebKit’s test suite.

The bad news is that variables aren’t backwards-compatible at all. Older browsers will simply ignore them (right now all browsers will ignore them) and if you’re defining key elements like background colors with variables the results in older browsers won’t be pretty. Eventually old browsers will fade away and CSS variables will probably become commonplace, but for the next few years at least we suggest looking to a preprocessor if you simply must have your variables.

File Under: CSS, Programming

Write Better CSS With ‘Idiomatic CSS’

Wooly, the CSS Sheep Image: W3C

If you’ve ever worked on a large programming project you know all about the joy of trying to read other people’s code. And of course that’s how everyone else feels about reading your code. That’s why formal programming style guides exist — to help bridge the gap between individual styles.

There is no right or wrong style of writing code, but there are styles that are easier to read and share with other people. Search the web and you’ll find formal guides to writing readable JavaScript, Python, Ruby and countless other popular languages, but one language that doesn’t get as much attention is CSS.

Developer Nicolas Gallagher wants to change that. To do so Gallagher has put together Idiomatic CSS, a style guide for how to format, organize and craft quality CSS that anyone can work with. Here are the general principles of the project:

“Part of being a good steward to a successful project is realizing that writing code for yourself is a Bad Idea™. If thousands of people are using your code, then write your code for maximum clarity, not your personal preference of how to get clever within the spec.” — Idan Gazit

  • All code in any code-base should look like a single person typed it, no matter how many people contributed.
  • Strictly enforce the agreed upon style.
  • If in doubt use existing, common patterns.

Idiomatic CSS follows in the footsteps of Rick Waldron’s Idiomatic JS, which does the same thing for JavaScript.

If you’ve made the leap to a CSS preprocessor like SASS or LESS, fear not, Idiomatic CSS has you covered as well. Preprocessor syntax varies and Idiomatic CSS offers examples in SCSS, but the more general rule, “your conventions should be extended to accommodate the particularities of any preprocessor in use,” apply to others as well.

Wrangling CSS on large projects can be a pain, but if you take the time to create a set of conventions and ensure that everyone sticks to them it becomes a much more manageable task. If you’ve got experience and insight to share, head on over to the Idiomatic CSS GitHub page and contribute your knowledge.

File Under: CSS, Programming, Web Basics

Learn to Code by Watching Others Write It

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.

File Under: CSS

‘Vendor Tokens’ Offer Another Way Out of the CSS Prefix Mess

Sisyphus

Sisyphus, by Max Klinger. The four ladies up top are named Gecko, WebKit, Trident and Presto. Image: Max Klinger via Wikimedia

CSS expert Eric Meyer thinks that a new proposal, CSS Vendor Tokens, might offer a way out of the CSS vendor prefixes mess.

CSS vendor prefixes were designed to help web developers by providing a way to target CSS rules to specific browsers and use proposed standards before they were finalized. Alas, while they have helped, they’ve also hurt the web.

The W3C’s CSS Working Group is currently in the process of trying to fix some of the problems. We’ve covered one proposed solution from Florian Rivoal, which would make vendor prefixes into aliases and ensure that when a browser implements a new CSS feature, it will work both prefixed and unprefixed.

Another proposal that Meyer wrote to tell us about comes from François Remy, who proposes what he calls Vendor Tokens. “I propose we use unprefixed properties from start,” writes Remy in a message to the www-style mailing list, “but with a token explaining which version of the property we built our CSS for.”

Essentially what Remy proposes is to use a flag much like !important, but to signal which version of the CSS property the rule is aimed at. The advantage is that instead of targeting browsers directly, you’re targeting a draft version of the spec.

Here’s Remy’s example of the syntax:

selector {
    border-radius: 1em !webkit-draft;
}

It’s a bit less typing than the current method, which would require four lines to convey the same information and, as Meyer suggests, dropping the -draft would simplify things even more. But more important than a simpler syntax is that, as Remy explains it: “any browser which is not webkit but implemented border-radius in a way that is compatible with the ‘webkit draft’ can support the declaration.” That’s a little different than vendor prefixes. With Remy’s proposal other browsers wouldn’t need to impersonate webkit, “they just acknowledge they support one specific property the way the webkit draft defines it.”

So a more full-featured declaration might look like this:

selector {
    border-radius: 1em !webkit-draft !moz-draft !o-draft;
}

Remy also includes a way to handle scenarios where Apple’s version of WebKit might differ from Google’s or even account for differences in versions of the spec.

As Remy admits, there are some drawbacks to this approach, and the syntax isn’t the cleanest we’ve seen, but as Meyer writes, “it feels cleaner than trying to do the same thing with prefixes.”

It will likely be some time before the CSS Working Group makes a decision on what, if anything, to do about vendor prefixes. If you’re interested in keeping up with the discussion on this and other proposals keep an eye on the www-style mailing list.