This is a very interesting project. Responsive design will continue to be a steady topic of conversation in 2012 and tools like this help propel us to talking about it applicably.

Without going into too much detail about responsive design itself, I’d like to point out what Response JS does differently. Their spin is to be a mobile-first responsive design implementation. By piggybacking jQuery you’re able to be much more aggressive in optimizing for the mobile experience in a number of ways.

1. Serve resolution-optimized images
2. Swap code blocks based on breakpoints
3. Methods and hooks to trigger responsive actions

There’s definitely some cool stuff to check out, and with the Web moving to an increasingly JavaScript-dependent environment, we might see more implementations along these lines to make responsive designs more mobile-focused.

As with all good things, there are drawbacks however. Being this aggressive can sometimes take away from the core purpose of being a single document with ‘conditional’ styling that responds to the environment at hand. I’m not saying this direction is a bad thing, in fact I really like that it keeps the idea of progressive enhancement in mind with all it does.

Related: Nathan Smith’s Adapt.js can’t go without mention here.

Advertise here with BSA

When reading the term progressive enhancement, JavaScript is usually the first word to come to mind. It’s important to know that the idea of progressive enhancement is in no way limited to JavaScript, and can be applied to your documents in a number of ways. I just finished reading the latest post from John Resig, Progressive CSS Enhancement, which featured an innovative idea that hadn’t crossed my mind before.

Progressive Enhancement and CSS

I’ve written about applying progressive enhancement to your CSS in the past, but John’s article goes above and beyond my idea. To summarize the idea behind my piece written some time ago, I’ll provide a quick synopsis. The general idea was to simply script the DOM to include an external stylesheet which provided classes, ids, and other selectors which are only necessary should the reader have a fully capable browser. These style sheets not only included some extra classes etc., they included some value overrides on existing properties to help out with the behavioral aspect of the document. At the end of the day, applicable CSS would only be included should the browser be capable of effectively manipulating the DOM.

Testing rendering engines with JavaScript

John’s article outlines a much more detailed implementation of progressive enhancement of CSS based on actual tests of rendering behavior. I think it’s a fantastic idea and it’s one of those articles that lead me to sit back and wonder why I hadn’t thought of it. It also had me thinking back on past projects, wondering where I could have applied a technique such as this to make my life a bit easier. I think running some tests using the method outlined by John could have saved me some work by providing a (gracefully) degraded experience to a reader running IE6 (let’s not kid anyone by referring to sub-par browsers in general).

What do you think?

If you’ve had a chance to read John’s article, how do you feel about it? Do you think it blurs the line between document style and document behavior? Can you see yourself using some of these tests to help you create better websites? Do you think it puts too big a burden on the developer? Or is that burden something we’re forced to accept as a way of life?

Advertise here with BSA

There have been many pieces written on both graceful degradation as well as progressive enhancement. Some people feel that they’re one and the same, but personally I think they are very similar, but each have unique characteristics. While a document that gracefully degrades will transparently appear as normal to any reader, progressively enhancing the document adds layers of functionality, if available, after the fact.

Relating Progressive Enhancement to Your CSS

Many times when you read about progressive enhancement on the Web, the discussion revolves around JavaScript. The general idea is to provide unobtrusive JavaScript that will not interfere with the viewing of any document, regardless of browser capability. As Web based applications become more advanced, there are many visual features being included to [hopefully] benefit the reader.

What’s unfortunate is that it is becoming more common for designers to neglect progressive enhancement once unobtrusive JavaScript is obtained. There are countless JavaScript libraries available, full of code that is designed with progressive enhancement in mind. The issue that’s becoming increasingly problematic, in my opinion, is the associated style that is required to achieve desired visual effects.

If your document will be enhanced when a reader doesn’t have a JavaScript equipped Web browser, it’s equally important that your CSS doesn’t interfere. While JavaScript should only control document behavior, that behavior often involves making changes to the DOM that are in turn effected by the document style.

As an example, there are many times that designers will adjust the visibility or display of an element in their CSS for the sole purpose of toggling that property at some point. What’s important to keep in mind is that readers without a JavaScript enabled browser will apply the entire style sheet, but have no script available to execute that fancy Ajax animation.

Use JavaScript to Progressively Enhance your CSS

In my opinion, there’s nothing wrong with altering the visibility or display of certain elements to bring your Web application together. It’s important to keep in mind the necessity of retaining progressive enhancement with your CSS as well.

On a recent project I ran into a situation in which I wanted certain elements to have stylistic elements that required JavaScript for full functionality. It would have been a nice feature to add, but requiring JavaScript isn’t an option. I needed a way to separate a small bit of CSS which would only be applied if the reader were able to make use of the JavaScript provided with the document.

I was reminded of an article I had read some time ago (that I’m having trouble locating) which mentioned using JavaScript to manipulate the DOM and add your CSS. This way, the styles are only applied using the technology which will control other document behavior. What we’ll do is generate a link element, append the proper attributes, and finally insert our element into the document tree by placing a snippet in the head.

<script type="text/javascript">
  //<![CDATA[
    initStyles = document.createElement("link");
    initStyles.setAttribute("rel","stylesheet");
    initStyles.setAttribute("type","text/css");
    initStyles.setAttribute("media","screen,projection");
    initStyles.setAttribute("href","css/js-init.css");
    document.getElementsByTagName("head")[0].appendChild(initStyles);
  //]]>
</script>

This snippet allows us to include the CSS to ‘initialize’ the document in preparation for user interaction via JavaScript. The style will only be applied if your reader has a JavaScript enabled browser, making it extremely likely that your Web app JavaScript will operate as intended.

It’s not the only way

Appending a style sheet to your document using a method like this may not be ideal in your opinion. You could effectively use your existing CSS and manipulate the DOM in a way that doesn’t interfere at all with a JavaScript-less reader. I’m not a fan of using JavaScript to directly control the style of an element. To me, (something like) element.style.color = 'red' triggers nightmarish images of <FONT color="red">Lorem ipsum</FONT>. I try to stray away from using document behavior to control document style, that’s reserved for CSS.

What is truly important is ensuring your document is still equally usable whether you’re working with JavaScript or not. That goes beyond taking your scripts into consideration, any preparation you create with CSS must be monitored as well.

Advertise here with BSA