Archive for the ‘CSS’ Category

File Under: CSS, Programming
Jun
11
2012

Write Better CSS With ‘Idiomatic CSS’

By

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.

Tags: ,
File Under: CSS
Jun
7
2012

W3C Gives Its Blessing to Prefix-Free CSS Animations

By

Sisyphus

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

The W3C’s CSS Working Group, the group charged with creating the CSS standard, has given browser makers the go-ahead to remove the prefixes from CSS 3 Transforms, Transitions and Animations.

CSS vendor prefixes were designed to help web developers by giving them a way to target CSS to specific browsers and use proposed standards before they were finalized. By prefixing properties developers can target any quirks in specific browsers until the standard is finalized. Unfortunately that’s not always what has ended up happening. Vendor prefixes have come under considerable fire recently, with Opera going so far as to implement other browsers’ prefixes.

That’s why the announcement that three more properties are ready to go prefix-free is good news for web developers. Obviously it’s a bit early to get rid of your transition and animation prefixes, but look for coming updates from browser makers to do away with the need for prefixes like -moz, -webkit, -o and -ms when using Transforms, Transitions and Animations. In fact the latest preview release of Internet Explorer 10 already supports the unprefixed versions.

The IEBlog recently posted a nice overview of all the new prefix-free CSS properties in IE 10.

Unfortunately, as is often the case in web development, using the prefix-free version of CSS rules is not a simple as it should be. Even those who followed the best practice of including an unprefixed version of CSS rules after the prefixed declarations may, in some cases, need to tweak their code a bit.

Consider for example the syntax of CSS gradients. The prefixed gradient syntax supported by today’s browsers is in fact based on a now obsolete draft version of the gradient specification. The earlier syntax is incompatible with the current Candidate Recommendation version of the spec. That means if you wrote out the unprefixed rule on a site two years ago, using the correct syntax for the time, your unprefixed code won’t work when gradient prefixes are removed (as they have been in IE 10). Fortunately, gradients are something of an anomaly and most of the time you won’t need to change too much. With the Transforms, Transitions and Animations you shouldn’t need to change anything at all.

Either way, browser makers will likely need to continue supporting the prefixed versions of CSS rules even after the W3C declares the non-prefixed versions ready for prime time.

Tags: ,
File Under: CSS, Programming, Web Basics
May
31
2012

Learn to Code by Watching Others Write It

By

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.

Tags: ,
File Under: CSS
May
11
2012

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

By

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.

Tags: , ,
File Under: CSS, Web Standards
May
8
2012

New Proposal Could End the CSS Prefix Madness

By

Photo: Ariel Zambelich/Wired.com

The W3C continues to wrestle with the problems CSS vendor prefixes are causing the web. While they’re useful for web developers, prefixed CSS rules as they are currently known may be causing more problems than they solve. Now W3C member Florian Rivoal has proposed a new solution to the prefixing problem.

CSS vendor prefixes were designed to help web developers by giving them a way to target CSS to specific browsers and use proposed standards before they were finalized. The idea was to move the web forward without rushing the CSS standards process. Unfortunately, it hasn’t always worked out that way.

Rivoal blames the prefix policy itself, writing, “I believe the current prefixing policy is hurting more than it helps, and that the problems are fundamental to the policy itself, rather than something that can be blamed on various parties for not following it correctly.”

The result is that the web is now in a situation where browsers are planning to start supporting other browser’s prefixes, which just might defeat the entire point of having web standards.

Rivoal’s proposal would change the way prefixes currently work and would solve some, though probably not all of the problems. Here’s Rivoal’s full proposal:

When a browser vendor implements a new CSS feature, it should support it, from day 1, both prefixed and unprefixed, the two being aliased. If a style sheet contains both prefixed and unprefixed, the last one wins, according to the cascade.

Authors should write their style sheets using the unprefixed property, and only add a prefixed version of the property (below the unprefixed one) if they discover a bug or inconsistency that they need to work around in a particular browser.

If a large amount of content accumulates using a particular vendor prefix to work around an issue with the early implementation in that browser, the vendor could decide to freeze the behavior of the prefixed property while continuing to improve the unprefixed one.

The biggest win for web developers — should Rivoal’s proposal be implemented — is that it greatly simplifies the process of trying new features. It would give developers the tools they need to work around individual browser quirks with new features, but is less likely to lead to a situation like today, where WebKit-only CSS rules litter the web.

Another nice benefit of Rivoal’s approach is that it solves the Opera dilemma — that no one is using prefixes for less well-known browsers. “No browser, however new or obscure, would have the problem of being excluded,” writes Rivoal, “authors might not test in it, but if the browser does a good enough job of implementing the property, sites will render as intended.”

Obviously this proposal is just that, but there’s already an extensive dialog on The W3C’s www-style mailing list and it appears that most members are supportive, though some have expressed reservations and possible problems. Mozilla’s Henri Sivonen does a nice job of addressing many potential issues and shortcomings in a very long, thorough post to the mailing list.

It will likely be some time before any changes are made to the way vendor prefixes are handled, and of course none of this solves the problem that’s already on the web today. But, hopefully, with a few changes to the way prefixes work, the web can avoid the WebKit-only problem in the future.

Tags: ,
« OLDER POSTS