“Which CSS preprocessor language should I choose?” is a hot topic lately. I’ve been asked in person several times and an online debate has been popping up every few days it seems. It’s nice that the conversation has largely turned from whether or not preprocessing is a good idea to which one language is best. Let’s do this thing.

Really short answer: SASS

Slightly longer answer: SASS is better on a whole bunch of different fronts, but if you are already happy in LESS, that’s cool, at least you are doing yourself a favor by preprocessing.

Chris Coyier finds an answer to what preprocessor is the better one by pointing out what the advantages of each preprocessor are. And as it turns out SASS is winning the race because it has more power and better features. So if you are asked why you use SASS, you might want to link people to this post.

☰

Harry points out some over all pretty solid ways to keep the markup readable which I use too. The major one is whitespace, I think. To be true, I love whitespace. But I’ll come to this later.

General

Tabs or Spaces?

Personally I’ve learned to use tabs instead of spaces just a few weeks ago. Lea Verou lists up some arguments, why she thinks using tabs is the way to go. But there are still some use-cases for spaces she describes.
At /gebrüderheitz I’ve discussed using spaces with Steffen before. He works a lot with PHP and uses Tabs since… – ever! I have been using spaces because I ran into some difficulties with tabs in the past where code was totally wrong indented and stuff. But at the moment everything runs pretty smooth and I am happy with how it is.

Lettercase

HTML5 and CSS let you write code how ever you want to: UPPER-CASE, lower-case, CaMeL-cAsE. So this is all the same:

<section id="a-lovely-header" class="contains-a-logo">
<SECTION ID="A-LOVELY-HEADER" class="CONTAINS-A-LOGO">
<SeCtIoN iD="a-LoVeLy-HeAdEr" ClAsS="cOnTaInS-a-LoGo">

You have to make sure you use the according class in CSS and id in JavaScript, because they are both case-sensitive.

I use lower-case exclusively. I’ve never tried to use anything different as it does not seem natural to me. Apart for that, WHO THE HELL WANTS SO READ UPPER-CASE ALL THE TIME?! IS THE CODE REALLY YELLING AT YOU? HAVE YOU EVER SEEN THIS IN A SERIOUS BOOK? Ok – to be fair, I’ve never seen a serious book with all lower case. But camel-case? C’mon…
Camel-Case in JavaScript is totally perfect though.

HTML

Harry names a view key parts of HTML styling which I use and some I really do not like.

Unquoted Attributes

I never write unquoted attributes. Harry states that this is something he does, because he can. Well… That’s true. But as he points out he has some rules where he quotes attributes for example for generated content or content that changes a lot.

His opinion on using double-quotes for all the attributes is obvious, anyway:

It is more consistent on the whole, but by introducing rules I make my own consistency; if you can get away with not using quotes, then do so.

For me the rule “Don’t confuse others” applies here: When another programmer who is not familiar with writing attributes without quotes has to edit my code in a later stage of a project or just when checking the source of a project and sees this, she might be confused with what I wrote.
Apart for that, writing attributes without quotes is error-prone.

An example: You use the Media Object as described by Nicole Sullivan for your styles and need a button, you will probably add a class btn to your link. The action that this button takes care of is the primary target of a website. Thus you add another class primary-btn to the class-attribute. If you don’t use quotes, you’ll have to add them now. It may occur that you forget them. And now what?! You are screwed. This will lead into searching your template over and over again until you find this nasty little mistake you made earlier. I don’t want this! I like code that’s pretty much straightforward.

To be fair I have to say, that I use a build script for my code before it goes into production which minifies my HTML-code and thus removes unnecessary quotes. But this does not change my development coding style.

Self-Closing Tags

Omitting self-closing tags is a thing I really love about HTML (over XHTML). You can omit the closing tag. Actually I’ve seen people not using self-closing tags on images or inputs but using them in meta-tags. I don’t know what the sense behind this might be.
I just do not use them anywhere.

Optional Closing Tags

This is a thing people may get confused about, too. Just a view days ago someone re-filed the issue of missing closing tags for HTML5 Boilerplate’s 404-error-page template because he was confused of the missing stuff I guess. That’s why I try to always use the optional closing tags – again: don’t confuse anyone. At least I try to.

I remember Paul Irish had a great usage of optional closing tags for tables where you can align rows by using whitespace, so you can see the table’s layout in HTML. Not working with generated data, though.

Here’s the example

<table>
  <tr><th>Name           <th>Country       <th>Nonsense
  <tr><td>Rick Astley    <td>England       <td>Rickrolling
  <tr><td>Chuck Norris   <td>United States <td>Roundhouse-Kick
  <tr><td>Emeli Sandé    <td>Scotland      <td>Singin – Fo realz!
</table>

Whitespace

Oh yeah, whitespace. As I already pointed out I love whitespace in my code. Everything is a bit more obvious when you divide it into small parts. It gets easier to scan the code I think. Comments help with this too.
I like to divide bigger chunks of a page with a lot of whitespace. For example if you have a content-area and a sidebar, I try to keep them separate by using whitespace.
Apart from that grouping elements like definition-list-entries helps a lot with the readability of code.

I’ve made a gist with an example-file. Check it.

CSS

Using ids in CSS is something I try to avoid but it strikes me sometimes and I just do it if there are already ids defined on some elements. Mostly these are identifiers for header- or footer-sections. But I think it’s better use classes for styling concernes and ids for JavaScript and other stuff.

Anyway… The next part will not be about vanilla CSS. I use SASS (SCSS) nowadays and recently re-factored a corporate website for one of our customers at /gebrüderheitz in SASS. I want to share the way I worked with a lot of CSS in this case and did it sometimes before.

Structure

The website has a lot of styles which had to be refactored. These were organized in one big file that has about three thousand lines of code. I do not like to have a file that has so many code and is not clear by looking at it at first.
So I have decided to split up several parts into different files.

Before the refactoring we made an online style-guide, defining the elements that appear on the side. This style-guide will be used in other projects for the same customer, too and is essential for a corporate website. We tried to define as much as possible but also let designers have a free hand at what they do.

For all SASS-files I use a folder-structure which looks like this:

+ CSS
  + elements
  + helpers
  + modules
  + page
  styles.scss

The styles.scss file has a brief description of the project, who wrote the styles (copyright…) and includes (with @include) all other files which lie in the created folders.

+ helpers

helpers contains a file with pre-defined mixins, another file with all the variables for the project, a reset (in my case this is most of the HTML5 Boilerplate CSS, which contains Normalizer.css) and some other helper-classes which I use via mixins or with SASS’ @extend-method.

+ elements

In the element folder I include files with styles for styling native HTML elements. I’ve got a file named typography which contains definitions for the general copy-text, headlines, links, quotes aso. Another file contains all stylings that are connected to lists in the content (unordered-, ordered- and definition-lists). This folder also includes the styles for forms and tables.

+ modules

I mentioned the style-guide we defined for this project. This was a great help for me when dividing the CSS into parts because I was able to see which modules were needed for the page: boxes, a paginator, an accordion menu, the navigation and some other stuff.
For each module I have an own file which contains the styles of only one modules. So when I need to change something that has to do with the paginator, I’ll head over to the according file and change the desired values. This saves me a lot of searching and scrolling through a file. Apart from that, Sublime Text’s “Find in files” (cmd + Shift + F) feature lets you search trough all files in a project which is pretty handy. Text Mate has something similar I think. And if your editor does not support it, fire up the console and grep for the things you want to find.

+ page

This last folder contains all files that add a separate styling for any page or part of the website. Typical content might be the general layout and the header and footer styling for a page. Furthermore I define styles for an area of a website in this folder – e.g. if events need more styles than defined in the modules section, or a contact-form that has some extended stylings.

And More?

We have not yet done the styling for the mobile version of this website and thus the styles are not yet included into the project’s folder structure. Styles that are specific for devices with smaller width will go into a mobile-folder.
Another thing are stylesheets for print or other media. I’ve not yet found a proper way to include these. If you have any idea for this, let me know.

Whitespace & Comments

Back to the main CSS styling guidelines for my projects.

Typically I try to avoid too much rulesets in one file but sometimes you need to do this to not split one feature into several files, which is not the sense behind this modal.
Comments are a thing that help everyone reading the defined styles to unterstand them better. Most of the class names are pretty obvious and thus don’t require any further explanation. But if you define styles that are not obvious at the first glance or you need to use browser-hacks in any form it can be helpful for other programmers to include a short comment. At least I do it this way.
I try to think about “other programmers” as the programmer I might have become in three month, when I will look at the defined styles again. If I don’t know what I did three month ago, how is anyone else supposed to understand it. This needs to be avoided.

Formatting

One thing Harry mentions is that he does not use a lot of whitespace in his rulesets. I am allergic of this style of writing. I like to have really clean styles as this:

.some-rule {
  float: left;
  color: #666;
  text-decoration: underline;
}

For vendor prefixes he indents every rule so he can use typing in columns. As I use SASS I don’t really have to care about this. But I like the way he does it. I’ve done it the same way when I used to write vanilla CSS.

Indenting is somehow essential for the CSS nesting in SASS. For rules where the nesting does not work I don’t indent though.

And A Lot More

This is not everything that applies to my HTML and CSS workflow / guidelines. I hope I can write more about stuff like this in the future and share more of my thoughts. Feedback on my thoughts would be great.

Also: If you have some time, write down what your way of coding is. Share it on Twitter with the hashtag #codestyle.

Developed at Twitter to support our internal styleguide, RECESS is a simple, attractive code quality tool for CSS built on top of LESS.

Incorporate it into your development process as a linter, or integrate it directly into your build system as a compiler, RECESS will keep your source looking clean and super managable.

As I think reading the source is essential for developers to become good at what they do viewing this source in readable style is essential too. RECESS is a tool which helps you developing good-looking CSS with LESS. It is developed at Twitter and has now been open-sourced.

RECESS is a Node.js module and is maintained by @fat. You can find out more about it by viewing the source at GitHub.

BTW: I’ve decided to not minimize and concatenate my blog’s source anymore. So, feel free to dig deep!

☰

Since a little bit more than a month (as of the time of writing) there is a Editor’s Draft for a CSS Variables Module by Google (Tab Atkins and Luke Macpherson) and Daniel Glazman. Just a few days ago the Working Draft was updated.
The first draft was written in 2008 by Daniel Glazman but was not added to the official specification. The new WD extends this proposal by Glazman.

Disclaimer: This article is part of a small series about the latest CSS working drafts. The first article in this series was about the CSS Hierarchies Module.

CSS Variables

The CSS Variables Module Level 1 suggests to use variables for data that is reused in stylesheets. These key-value storages provide the possibility to store “meaningless” data as you can do in HTML: Variable keys consist of a data--prefix and the variable name.

Any property name starting with the prefix “data-” is a data property. Data properties are defined to be valid but meaningless as they are meant solely for allowing authors to pass custom data around their page, similar to the custom data attributes in HTML.
~ Defining Variables With Data Properties – CSS Variables Editor’s Draft

Using data- as a prefix for variables is still in discussion and may likely be changed to something more “connected” to variables ($ or &).

Edit: The mailing-list www-style is discussing the use of data and Ian Muir wrote an article about the problem.

Syntax

Variables are defined by mapping them to the :root pseudo-class. The WD does not really explain why the variables must be declared on the root-element. Maybe it’s because the data needs to be bound to an element to not “fly around” in the global scope (which does not really exist in CSS).
Defined variables can also be set on every other element and overwrite the existing value of a variable.
So this is how you set variables.

To get a specific variable, you do not declare the variable-name but you call data as a function on a certain property with the variables name (without data--prefix) as an argument.

An Example

So here is an example:

/* Set data */
:root {
  data-main-color: #bada55;
}
 
/* Get data */
.foobar {
  color: data(main-color);
}

As said before, variables can be overwritten for specific elements. So we can add the declaration of the variable to .foobar:

.foobar {
  data-main-color: #fe57a1;
  color: data(main-color);
}

The color of .foobar is now #fes7a1 and not #bada55.

Real World Examples

Well, as this is an Editor’s Draft and pretty new it’s not being implemented in any browser.

I’ve created a test case on dabblet with vendor prefixes which tests the two examples above. I’ve run this test on the major browser alphas and nightlies.

Even though variables are not natively supported by CSS in any browser yet, we can use a very similar approach: All CSS preprocessors support variables. Here is an example with SASS:

/* Setting a variable */
$main-color: #bada55;
 
/* Get the variable's value */
.foobar {
  color: $main-color;
}

Conclusion

We can use variables with preprocessors today which is pretty rad. As with the CSS Hierarchies Module CSS in the future may support ideas that come from implementations in preprocessors somehow.
I think most developers are happy about these adoptions and will likely use it. But as it will take some time for all vendors to implement this feature – and even more time until browsers that don’t support such new features vanish – we will have to use preprocessors to get variables in our CSS working.

Update 16.04.2012

Since last week the CSS Variables Module Level 1 is an actual Working Draft of the W3C.

It’s now possible to define variables with the var-prefix instead of data which is still pretty complicated. I wonder why they not adept an existing concept as in LESS or SASS.

Thus the data()-function changed accordingly to var().

Furthermore it’s possible to set variables on a certain element but use them in a more complex definition. An example might be the usage as follows (while elements with class important and primary are divs):

.important { var-color: red; }
.primary { var-color: blue; }
div { color: var(color); }

Also nestings for variables are possible:

:root {
  var-color: #ddd;
  var-border: 1px solid var(color);
}

The bright and shiny future

As I think there still are some issues with this Working Draft I like the fast step forward in making this a WD in only a view weeks.
So sooner or later variables will be part of the CSS specification and will be implemented in browsers. I hope this will be very soon.

So what’s the Hierarchies Module? And why “Level 3″?

The Hierarchies Module is not exactly new. It exists since the very first steps of CSS and was first released in Dezember 1996 with CSS1. The CSS1 specification is still up, so check it out if you want to.

When you write CSS you always use selectors to target the element you want to style. This works pretty much straight-forward: The right-most simple selector is the one which get the declarations assigned that are defined in the ruleset.
These selectors define a certain hierarchy in your stylesheet.
Note: Please make sure to read Tab Atkins’ Reference for CSS Spec Terms.

An example

Today you would target some links in a navigation like this:

#nav ul li a { color: #000; }

If you’re smart and your markup allows you to do so, you may write:

#nav a { color: #000; }

The li-elements need to be inlined as you want a horizontal navigation:

#nav ul li { display: inline; }

Furthermore the navigation should be aligned on the right and all the links centered:

#nav ul { text-align: right; }
#nav ul li { text-align: center; }

This leaves us with a lot of repetition for the selectors.

#nav ul { text-align: right; }
#nav ul li { text-align: center; display: inline; }
#nav ul li a { color: #000; }

With the Level 3 proposal by Tab Atkins Jr and Shane Stephens (working for Google) this is about to get a little bit easier. The existing system will be extended with some new functionality. This is why it’s called Level 3. (Also it will likely be part of CSS 3 – and not 4 or 10 or something.)

What’s new in there?

Lately you saw the rise of CSS Preprocessors. Everyone has an opinion on this. The thing why so many developers use them is that they help to organize the CSS-code you are writing.
Preprocessors have brought up another idea of CSS hierarchies. And with the CSS Hierarchies Module Level 3 this has been adopted.

The specification draft allows you to nest your rules and use the &-character to reference a parent selector in a certain rule.

Here’s the example from above with the new hierarchy:

#nav ul {
    text-align: right;
    & li {
        text-align: center;
        display: inline;
        & a { color: #000; }
    }
}

As you can see there are no repetitions for the selectors as you can reference them by just writing & and nest them properly.

How can we use this today and when will it be ready for the “real world”?

As you may guess this is not implemented in any browser yet.

As this spec is written by two Google-guys it’s likely that this will be implemented in Chrome in the near future. At the moment this is not working with Chrome 19 (Canary) or WebKit Nightly.
I’ve made this Dabblet to check if the module is supported in a browser or not. caniuse.com does not provide any data for the Hierarchies Module yet.
Aside: Check my Dabblet Chrome App to view all your latest dabblets if you’re a Chrome user.

Tab Atkins proposed another style for nesting. To reference the parent selector you use @this instead of the &-character. Peter Beverloo wrote about this a year ago. Also Tab Atkins has an article about his further plans. This variant was not implement either and is replaced with the new draft for the specification. Anyway you could view the dabblet I’ve made for this propose.

Preprocessors

As mentioned above CSS preprocessors offer the chance to use something like hierarchies in there own way. Here are two examples:

SCSS (aka. SASS)

#nav ul {
    text-align: right;
    li {
        display: inline;
        a {
            color: #000;
            &:hover { color: gray; }
        }
    }
}

Stylus

#nav ul
    text-align right
    li
        display inline
        a
            color #000
            &:hover
                color grey

As you can see there is a difference in how preprocessors treat the &-character as a reference: In the CSS specification draft & is obligatory in every nested rule you write to reference the parent selector. Preprocessors need them only if there is a pseudo-class or -element or a combinator (such as ~ or >) used for a specific selector.

As I stated in the introduction it may happen that the specification will be changed until it becomes final or is adopted by the CSS Working Group. I recommend you follow the discussions about this topic in order to stay up to date.
When this specification will be implemented by one of the browser vendors it’s just a matter of weeks until it will be adopted by the others I guess.

But, as the draft states, this is not yet part of CSS:

This document is purely an Editor’s Draft. It has not yet been adopted by the Working Group, and should not be considered to be part of CSS.

~ CSS Hierarchies Module – Status

Opinion

Personally I hope that referencing the parent selector with & will not be in the final specification as it is now. It’s not needed as the rules are nested anyway and preprocessors nowadays treat them better.

Anyway the new nesting is pretty useful as it reduces the redundancy of writing selectors in CSS. In connection with other upcoming specifications like the CSS Variables Module Level 1 this is what is needed and will be helpful for every web-developer once it will be implemented in browsers.

I think all of you know Lea Verou’s dabblet.

dabblet is an interactive playground for quickly testing snippets of CSS and HTML code. It uses -prefix-free, so that you won’t have to add any prefixes in your CSS code. You can save your work in Github gists, embed it in other websites and share it with others.
~ About dabblet

Some time ago I made this tiny Google Chrome App for jsFiddle which is in case just a bookmarklet with a bigger icon.

I did this for dabblet, too but extended the app to something more: It displays all your dabblets with title and creation-date. You can then visit your dabblet directly.

You can find the app in the Google Chrome App store now.

Download

This project is on GitHub, so please feel free to contribute and report bugs and feature requests.

Changelog

These are the major changes. All commits can be found on GitHub.

v0.7 – Feb. 13, 2012

• Add search – #2
• Rewrite code-basis based on JS AMD with RequireJS
• Display message if user has no gists to display – #3

v0.45 – Feb. 02, 2012

• Add a link to fork Gists on dabblet when visiting them on GitHub

Before we used Git we’ve used SVN but this is by far not as flexible as Git. There are enough posts gathering the difference between Git and SVN so I will not cover any of these.

When working in a team it’s important to keep your different stages of development in sync and control somehow: There is a front-end development going on which is in deep connection with the server-side development; you may also want to develop a new sub-project within your main project; and then there is a tested and fully working live-version of a project.

With Git it’s pretty obvious to use branches to organize different states of the project’s development.

Branches

Branches can consist of the whole project’s files and some more commits covering a specific issue or feature. Also they can show a whole different approach of a project and do not necessarily need to consist of the main project’s files.

For our projects we try to keep these branches tight so we will not have a problem when it comes to merging branches – to let one feature or development approach flow into the main development line. Keep in mind that branches in a project are indeed cheap. So use them where you think they might fit. Don’t think about it to long. It will help you in your whole working-process.

Cherry-Picks

Sometimes, when it comes to bug fixing you don’t want to put fixes in your live-branch. You fix them in your development-branch and commit them over there. The dev-branch might be on a whole other level as your live branch as you’ve developed some things that will be part of a next major update or so. Therefore Git’s cherry-picking has become a perfect addition to our workflow.

With cherry-picking you are able to pull single commits from one branch to another.

Another part where you might want to use cherry-picking is when a colleague and you develop in two different branches and one contributes to the other’s sub-project without changing the branch. There are some other use cases. Please feel free to share where you use cherry-picking through the comments.

How to Use Cherry-Picking

I am using a GUI for doing all the Git-related stuff which is pretty handy and easy. But I think it is important to know how to handle Git via the console anyway.

Here is how to cherry-pick commits.

At first you need to commit your changes in the development branch.

$ git commit -m 'This is some bugfix-message'

You now need the commit-hash for the commit you want to cherry-pick in another branch.

$ git log -1

This will return the meta-data for your latest commit. You can now copy the first 7 or so numbers of the commit-hash. It’s not necessary to copy the whole hash as the hash-partial only needs to be unique above all commits of the project.

Now you need to change your checked out branch to the branch where you want to insert – cherry-pick – this particular commit. While <live> is the name of this branch, do this:

$ git checkout <live>

Keep in mind to commit all your changes in the current branch first or stash them.

Lastly you have to tell the checked out branch to use this commit and do the cherry-pick for real!

$ git cherry-pick <hash-partial>

<hash-partial> is pretty self explaining I guess.

Git now automatically merges the commit into the specific branch.

Merging Branches Later

From what I experienced it is no problem to merge branches later when you cherry-picked some commits. This works just fine!

In the late nineties CSS 2.1 brought us a basic set of good-enough tools to finally get table-free layouts en route. Then came CSS3 which started off by providing us with more creative tools to carve out the details. Today we finally have embeddeable fonts, rounded corners, gradients, semitransparent elements and colors, box and text shadows and so on and so forth.

Yet, comparing our toolset with that of an image editor like Photoshop we still discover a lot to desire. In Photoshop, for example, we have possibilities to desaturate parts of an image, or to sharpen or blur them. How might we need that for the web? Well, desaturating or blurring an area of a web page might be a means of directing your visitor’s attention to where you want it to be. Or it might help your visitor to concentrate better on an area, which you left untouched. Such a case might be magnifying pictures of a gallery:

A sharpen effect on the other hand might be useful when you scale down images in the browser, since without counter-measures you lose a lot of image details.

That said, it would be nice if we had such effects and could apply them the same way we do apply opacity to tranparentize a whole area. Alas, we don’t.

The status quo

Instead, to replicate a desaturation/grey scaling we are currently forced to cycle “by hand” through the color values of every affected element with JavaScript and set them to a corresponding grey value. When we meet (background-)images or videos it gets even more complicated: Then we need to switch to HTML5 canvas to manipulate their color-values pixel by pixel and swap out the original ones. But even if we get help from libraries like CamanJS or Hoverizr, it remains a profound messy affair.

A blur effect can also be simulated, this time by using text-shadows and/or box-shadows that use the same color/background-color as the to be blurred text/box. The thing is, the illusion doesn’t work with multicolored boxes and, as before, not with images or video. This requires again some HTML5 canvas action. Sigh.

Speaking of HTML5 canvas: A very brutal approach to that blurring topic is being made by a library called blurry.js, which extracts all the content, recreates it in a canvas (partially via Cufón), blurs it there and injects the whole thing back to where the original content was.

Finally, for sharpening elements there is no CSS-based trick at all, which leaves us alone with HTML5 canvas.

SVG to the rescue

Interestingly SVG knows a huge palette of so-called filters since ages, e.g. color blending, brightness/contrast adjustments, lighting, displacement mapping, gaussian and motion blur, clouds, noise, sharpen et cetera.

Now, what we might try, since SVG is more and more widely supported, is to not put our content into HTML, but instead to put it into an SVG which we then inline or embed into out HTML “frame”. Inside that SVG we are then able to apply any effect we like to our contents. The drawback is that a HTMLer won’t be too keen on switching to SVG markup like the following:

<text font-family="Arial" font-weight="900" font-size="40" x="20" y="55%">SVG Example</text>

Something way cooler is an SVG thing called ForeignObject/xlink, which allows us to embed foreign objects or areas of foreign markup inside an SVG. Think of it like inlining SVG into an HTML5 document, but the other way ’round. Once you have embedded your stuff, you can apply filters to it like you can for any other area of your SVG. You might embed and filter a full HTML page from A to Z, or you restrict yourself to just embedding and filtering a single bitmap image. Of course, you’d need to put the holding SVG into an HTML page again, which makes up for some Inception-like braintwister (HTML with embedded SVG with embedded HTML). Browser support of the ForeignObject is quite good. Remains left IE, who will follow suite in version 10 both with SVG filters and ForeignObject.

SVG Filters in HTML via CSS

Firefox since version 3.5 goes even further. He allows you to reach out to a filter that resides inside an SVG from out your HTML document’s stylesheet and have that filter then applied to any HTML element. We could for example define a feGaussianBlur-filter in an SVG with a radius of 2px and assign it the id gaussian_blur:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" 
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="1" height="1" version="1.1" 
xmlns="http://www.w3.org/2000/svg" 
xmlns:xlink="http://www.w3.org/1999/xlink">
  <defs>
    <filter id="gaussian_blur">
      <feGaussianBlur in="SourceGraphic" stdDeviation="2" />
    </filter>
  </defs>
</svg>

Then we could reference that filter by the SVG’s file name and the filter’s id in our styles and have it applied to every image:

img {
  filter: url(blur.svg#gaussian_blur);
}

You find a live-demo here. Alas, as I said, this just works with Firefox.

Thankfully this is not the end of the story. IE also knows filters, although not SVG-based, but instead based on early incarnations of the Windows graphics library DirectX. Amongst those filters are not only the well known alpha oder gradient filters that we use to fix bugs or to replicate CSS3 features. There are also filters that are quite similar to many of the interesting SVG filters:

/* blur by 2 pixels */
filter: progid:DXImageTransform.Microsoft.Blur(pixelradius=2);
/* 13 pixel motion blur rotated to an angle of 310° */
filter: progid:DXImageTransform.Microsoft.MotionBlur(strength=13, direction=310);
/* grey scale / desaturate */
filter: gray;
/* Röntgen effect (inverted grey scale) */
filter: xray;
/* light cone */
filter: light();
/* emboss */
filter: progid:DXImageTransform.Microsoft.emboss();

You find a full list of those visual filters here.

So, with the help of conditional comments we can now already serve certain effects to two browser families, which together make up a considerable amount of the browser market:

<!DOCTYPE HTML>
<!--[if lte IE 9]> <html class="ie" lang="en"> <![endif]-->
<!--[if gt IE 9]><!--> <html lang="en"> <!--<![endif]-->
<head>
<meta charset="utf-8">
<title>Blur via CSS</title>
<style>
img {
  filter: url(blur.svg#gaussian_blur);
}
.ie img {
  margin: -2px;
  filter: progid:DXImageTransform.Microsoft.blur(pixelradius=2);
  zoom: 1;
}
</style>
</head>
<body>
  <img src="stadt.jpg"
   alt="Some rights reserved by zigazou76"
   width="500" height="333">
</body>
</html>

margin: -2px counters the increased dimensions of the filtered element in IE. zoom: 1 is needed for most filters to work in IE6/7. Sad fact: IE10 won’t support filters anymore :(

Here you find the extended example

As people liked Firefox’s idea to open up SVG filters for use with HTML, those people formed a new task force in the W3C called W3C FX Task Force whose purpose it got to standardize and even simplify usage of SVG filters for use in all browsers. Because Firefox already pioneered filter effects the first draft didn’t take too long to appear under the label of W3C Filter Effects 1.0. The mechanics proposed in that draft work almost like in Firefox, but with the addition of offering shortcuts to some of the most interesting filters. Filters that have a shortcut defined work without the help of an external SVG. They are sort of permanently hard wired inside browser engine. Those are the filters with shortcuts:

• grayscale
• sepia
• saturate
• hue-rotate
• invert
• opacity
• brightness
• contrast
• blur
• drop-shadow

Another advantage of the shortcut filters is that they are animateable via CSS transitions or animations:

.foo {
  filter: blur(2px);
  transition: filter 1s ease-in-out;
}
 
.foo:hover {
  filter: blur(0);
}

This would be much harder and less efficient to do within an SVG.

Finally the filter effects are planned to be extended with OpenGL/WebGL vertex and fragment shaders. Vertex shaders will let you span a 2D mesh over an element and then let you distort the object by moving all the crossing points of the mesh following a mathematical formula of your choice. Fragment shaders on the other hand will allow you to do such mathematical processing on the colors of every pixel of that element. And all of it, on top, hardware accelerated on your graphics card.

Conveniently last week saw the first implementation of those filters in the WebKit-Nightlies, from were they quickly spawned over to Chrome Canary. That means that within a 3 months timeframe CSS filter effects will be available in your everyday Chrome browser and probably not too much later also in Safari. And this means that we are not too far away from being able to serve some flavor of CSS filters to 90% – 95% of all browsers on the market!

Returning to our code example, all that we need to add for WebKit now is a simple -webkit-filter: blur(2px); which for once we need to put after the unprefixed filter-property. The reason is that once WebKit will support an unprefixed filter-property that Firefox-specific syntax in the last line would kill our CSS transition, which we do apply in order to fade nicely from blurred to unblurred and back via -webkit-transition: -webkit-filter 1s ease-in-out:

<!DOCTYPE HTML>
<!--[if lte IE 9]> <html class="ie"> <![endif]-->
<!--[if gt IE 9]><!--> <html> <!--<![endif]-->
<head>
<meta charset="utf-8">
<title>Blur via CSS</title>
<style>
img {
  filter: url(blur.svg#gaussian_blur);
  -webkit-filter: blur(2px);
  -webkit-transition: -webkit-filter 1s ease-in-out;
}
img:hover {
  filter: none;
  -webkit-filter: blur(0);
}
.ie img {
  margin: -2px;
  filter: progid:DXImageTransform.Microsoft.blur(pixelradius=2);
  zoom: 1;
}
.ie img:hover {
  margin: 0;
  filter: none;
}
</style>
</head>
<body>
  <img src="stadt.jpg"
   alt="Some rights reserved by zigazou76"
   width="500" height="333">
</body>
</html>

And here is the final example.

And that’s it, filter effects for everyone! Let 2012 be the year of the CSS filters and have fun playing with’em.

Christian ”Schepp” Schaefer is a freelance web developer living in Düsseldorf, Germany. He is the author of CSS-JS-Booster, co-author of Turbine CSS Framework, one hosts of the (German) Working Draft Podcast and he follows your tweets with his account derSchepp.

That’s why I created Is Mothereffin’ jQuery up? The service checks three major CDNs for the availability of the latest jQuery version.

View Is Mothereffin’ jQuery up?

How to Check if the File is up

I had some difficulties to find the right method how to detect if a file is already available with JavaScript. If you don’t have to deal with cross-domain requests this is not a big thing and done pretty easy. But I need cross-domain requests.

If a file is not available on a server, the request dies with an error 404 and no callback will be called. See this Fiddle for a test-case. Even a try-catch-expression does not help.

I decided to check all files for availability and if the request ends up in an error nothing will happen. The script will check if all files are available after three seconds and will otherwise “tell” the user that it’s not. This is not a bullet-proof method as it could take more then three seconds to request all files. If you have a better idea please let me know.
For the moment the resources will be labeled as “available” when they are loaded even if they were labeled “not available” before. So you will not end up with wrong result, it just may take a second more to show you that.

The Styles

The project was build “mobile-first”. It makes use of the CSS3 Flexible Box Model instead of float and all the other stuff.

I’m not supporting IE in any way because I think most web-developer don’t use Internet Explorer.

Todo

• Support more libraries such as Mootools, Dojo, Prototype, ExtJS and YUI
• Let users submit other CDN via a form
• Link buttons to their libraryDone with this commit – suggestion by Mathias

Let me know if you want some other features.

Contribute via GitHub

I’ve put this project up on GutHub. Feel free to contribute or just watch it.

Feature requests can also be placed in the issue-tracker there.

• Bandwidth
• Screen size
• Performance / Velocity

The question is how to deliver responsive images on a mobile website.

You maybe use something like img { max-width: 100%; height: auto; } in your responsive design to prevent images from being bigger then the screen of a mobile device.

In most of the cases this shrinks images in its displayed size, which is a processor intensive thing to do – especially when you are on a mobile device and don’t have endless processor capacity this hurts.
The shrinking itself does not change the file-size that has to be loaded; it remains the same as on a desktop for example. As bandwidth is the bottleneck these days if you are on a mobile device, this is the issue where people want to see some improvement.

What can we do about it?

There are a couple of proposals and known techniques on how to solve the problem:

1. Resize images with PHP

This is something you could only do if you know the screen-size before you load the images them self. So you have to inject HTML through JavaScript for example and change the sources for images accordingly.

The Adaptive Images framework a similar technique. Check out the source on GitHub.

2. Request different images using data-attributes

An article by Nicolas Gallagher covers this method using CSS to detect which source would be best to use.

The method could work like this: You have an image which has a really small file size and is served for every device at first (mobile first approche).

<img src="image.jpg" alt="" data-src-600px="image-600px.jpg" />

Now you are going to change the file if the screen is bigger by using the content-property of CSS and its attr() function.

@media (min-device-width:600px) {
    img[data-src-600px] {
        content: attr(data-src-600px, url);
    }
}

Please have a look at the article for detailed information.

An idea that goes beyond the replacement of images with the attr()-function is the usage of content: url(myimage.jpg) replaced;. This is something suggested by Tab Atkins Jr. on the W3C www-styles mailing list – called replaced content.
Something about replaced content appears in the CSS-spec but it does not look to be exactly what Tab is referring to.

3. Introduce new attributes to the <img>-tag

Anselm Hannemann shares the idea of introducing a media-attribute that has some sort of “sizing-parameter”. It is supposed to be combined with the media-src-attribute which also has the sizing-parameter.
The HTML could look something like this:

<img src="myimage_xs.jpg"
media-xs="(min-device-width:320px and max-device-width:640px)" media-src-xs="myimage_xs.jpg"
media-m="(min-device-width:640px and max-device-width:1024px)" media-src-m="myimage_m.jpg"
media-xl="(min-device-width:1024px)" media-src-xl="myimage_xsl.jpg">

As you can see the media-attributes contain media-queries which describe when to take a certain image-source.

4. Using JavaScript

There are some ideas on how to deal with this topic using JavaScript.

The FilamentGroup for example published its “Responsive Images”-project on GitHub. They are using “Mobile-First” to present a small-sized image on every device and replace this with JavaScript on window load.
You can find out more about how it works on their blog. They also published a demo.

Peter-Paul Koch presented a possible way on how to combine media queries with JavaScript. Which is not really new I think but a good summery.

Another approach could be a new attribute for the script-tag: Scott Jehl suggested to call it preparse. The script could then be used to replace sources in HTML fitting the current client-need.

5. A new image-format containing different sizes

People aso had the idea of creating an own image-format which contains for example four layers with different image sizes. The image then “decides” which format to take and serves this to the client without its three sibling-layers.

At the moment there is a format called MrSID developed by LizardTech which can have one or more compression rates.

Another approach is the JPEG 2000 file-format. It can carry out different optimization-levels for images. Read more about it on the Wikipedia-page I linked above.

Media? But this was only about images…

Yup, right! Images are just one aspect when it comes to responsive media.
Videos for example are another thing. YouTube offers different video-sizes for watching. You have to choose manually which one to use. A possibility to select this resource automatically, build into the browser would be awesome!

JPEG 2000 has a video-equivalent developed by the same group of people as the JPEG-format called Motion JPEG 2000. Find more information about this here.

Conclusion

As it turns out many developers are not aware of the problems that come up with a real responsive design – even HTML5-specification writer are calling it “a niche problem”. This is why it is hard to develop a specification for a native API as for example Anselm Hannemann suggests.

But maybe the decision which technique might be best for solving the problem of serving responsive media has to be finished first before anything is spec’d up.

Moar!

Some more resources where the topic is discussed:

• A List Apart started the whole “Responsive Design”-discussion with an article by Ethan Marcotte
• jQuery Standards Team
• Scott Gilbertson on Webmonkey
• Another CSS-only idea by Harry Roberts

Thanks!

Thanks goes out to Anselm, for reading what I wrote and helping me with some further information.