This article by Ethan Marcotte on Responsive Web Design has been widely touted as the designer's panacea for all things mobile. Other leading designers such as Jeffrey Zeldman and Andy Clarke have all jumped on the band wagon. Considering the amount of influence these guys have on young designers, it saddens me that leading designers, of all people, would sacrifice their art on the altar of a quick fix.

Progressive Enhancement is the accepted philosophical approach to Web development today and demands an increased time investment on the part of Web Designers and Developers. Speaking as a Developer/Designer - yes, I'm one of those "Devigner" unicorns - with a background in ASP.NET Web Forms (gasp), I have finally accepted that my future will involve a return to the three-legged stool of all Web work: HTML5, CSS3 and JavaScript. Because of the importance of Progressive Enhancement and the extra time constraints it poses on any kind of Web project, I am justifiably wary of any and all new fads and buzz words that crop up like a bad outbreak of acne.

So what exactly is Responsive Web Design? In short, it's a technique that adapts a website's layout for multiple screen resolutions using a combination of fluid grids, images and media. CSS3 Media queries are then applied to toggle the layout width in response to the device width. The idea is to take a desktop version of the site and narrow it to fit in the smallest browser - set width breakpoints using media queries, say for mobile, tablet and desktop. This is akin to putting lipstick on a pig, not to mention the scrolling effect the user has to endure on smaller devices.

The focus of this post is on the "fluid" part of RWD and its disastrous consequences on the esthetics of any website built in this manner - designers should be able to get this. The technical problems with RWD are many and varied and have been well documented by others.  First off, here's a simple overview of the technical limitations:

1) Media queries are applied after content has been downloaded. This means that even for a mobile version, all markup, CSS, images and scripts are still downloaded. Considering the bandwidth limitations of most mobiles, this is a performance showstopper.

2) Media queries are not supported by legacy browsers or by most mobile handsets.

3) Fluid images are also a performance killer - you download images at their maximum size and set a maximum percentage width for them, leaving the browser to resize the images as needed - CPU intensive.

The Fluid vs Fixed debate started in the 90s and it's not my intention to fan those flames. Personally, I have always detested fluid layouts; they are anathema to good page composition. Between a mobile browser and a desktop one, there exists an almost infinite range of browser sizes outside of the break point widths used by your media queries. For any of these in-between browser widths, fluid layouts are going to change the composition of your page. And adding even more script to make your images fluid in order to compensate is only adding insult to injury - you just can't fix stupid.

Remember the time constraints imposed by Progressive Enhancement I mentioned earlier - where would you rather invest development time? Do you seriously think that a real world client is going to swallow this extra cost? Real life is all about priorities.

The Desktop and the Mobile are Two Different Animals

There is too much over-analyzing of words like "context" going on these days. Is the user going to be lying on the couch or standing in line at the cinema when they access the site? Context? Bullcrap. Don't insult the user - they can figure out how best to use their devices - all we have to do is make sure that we don't try to display something in a smart phone that defies common sense - like 2MB PDF map downloads. And always include a link to the desktop version of the website. It's not rocket science but smart phones and desktops PCs are worlds apart, and it should be obvious that in most cases the mobile version of a website demands to be created separately and given individual attention. In addition, if future development or design enhancements need to be made to the mobile version, creating it separately makes total sense. Re-skinning a desktop version of a website and calling it mobile-ready makes as much sense as asking a whore for a hug.

The RWD zealots often use the "One Web" argument, citing Tim Berners-Lee:

    "The primary design principle underlying the Web’s usefulness and growth is universality. When you make a link, you can link to anything. That means people must be able to put anything on the Web, no matter what computer they have, software they use or human language they speak and regardless of whether they have a wired or wireless Internet connection."

Henry Ford may have been the first to mass produce the automobile but that doesn't mean I'm going to take driving lessons from him. One Web proponents also misquote the W3C in support of their argument. Here is a direct extract from the W3C on One Web:

    "One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However, it does not mean that exactly the same information is available in exactly the same representation across all devices. The context of mobile use, device capability variations, bandwidth issues and mobile network capabilities all affect the representation. Furthermore, some services and information are more suitable for and targeted at particular user contexts."

In fairness to the designers mentioned at the start of this article, a few of them have come out recently and advocated a more judicious use of RWD and basically said that each case should be taken on its own particular merits. This may be a little too late in my opinion and I think that Web professionals should think before they speak. RWD as an alternative approach to multi-device layouts fails in so many respects, both technical and esthetic, that it cannot be considered as a responsible approach to Web development going forward. In our world, there is no silver bullet. The myriad of Web-enabled devices out there demand extra work and this is a fact of life.

If you're still not convinced, here's a sobering thought: speed is going to be a make or break factor in all websites going forward. After your client gets past the initial "oohs" and "aahs" of viewing their new site on their iPhone, try explaining to them why their new, expensive site cannot be found via Google search...

Recommended Reading:

Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement
Designing with Progressive Enhancement: Building the Web that Works for Everyone 
Why Separate Mobile & Desktop Web Pages?

I was working on a site tonight after being away from it for over three months. I came across some CSS and it took me a while to remember what it was for. I gleaned this online somewhere ages ago, but kudos and credit to the author whoever they are!

For some time I have been having problems using the ASP.NET TreeView control in Sitemaps; every time I would hover over one of the parent nodes it would jump up and down. Here's some sample markup and the CSS to fix it in Firefox:

        <div id="idTreeView">
            <asp:TreeView ID="TreeView1" runat="server"                     DataSourceID="SiteMapDataSource1"
                    HoverNodeStyle-Height="0" Font-Bold="true" ImageSet="BulletedList">
                <RootNodeStyle Font-Bold="True" />
                <ParentNodeStyle VerticalPadding="0px" Font-Bold="True"                     Font-Underline="false"  />
                <HoverNodeStyle Font-Underline="false" ForeColor="#5555DD" />
                <NodeStyle Font-Bold="False" Font-Size="8pt" CssClass="sitelink"
                    ForeColor="Black" HorizontalPadding="5px" NodeSpacing="0px"                     VerticalPadding="0px" />
            </asp:TreeView>
           
            <asp:SiteMapDataSource ID="SiteMapDataSource1" runat="server" />
        </div>

        div#idTreeView img
        {
            display: block;
            float: left;
        }

        div#idTreeView div
        {
            display: inline-block;
        }

        div#idTreeView .sitelink a
        {
            text-decoration:none;
        }

Recently, I have been experiencing some difficulty applying CSS correctly to some of the OOTB (out-of-the-box) ASP.NET controls. Earlier today, I was trying to apply a CSS image border using the ASP.NET image control, but couldn't get it to render correctly. In the end, I had to use a regular HTML img tag.

CSS for Image Border

*
{
   margin: 0;
   padding: 0;
}

body
{
   background-color:#827575;
   color: #c6d3d5;
   font: 75%/1.5em Verdana, Helvetica, Geneva, &quot;Helvetica Neue&quot;, sans-serif;
}

.test
{
   margin-left: 300px;
   padding-top:50px;
   width: 156px;
}

.imageStyle
{
   padding: 3px;
   background-color: #525252;
   border: 1px solid #c3cfd3;
}

ASP.NET Image Control

<div class="test">
  ASP.NET Image Control:
  <asp:Image ID="Image1" ImageUrl="~/Images/fender.jpg"    
     CssClass="imageStyle" runat="server" />
  <div style="clear:both;">Incorrectly Rendered</div>
</div>

HTML Image Tag

<div class="test">
  HTML img tag:
  <img src="~/Images/fender.jpg" id="Image2" alt="Correctly Rendered"
     class="imageStyle" runat="server" />
  <div style="clear:both;">Correctly Rendered</div>
</div>

Feedback from anyone experiencing similar issues would be welcome. One of the projects on my to-do list this year is to create a custom CSS framework for use with ASP.NET sites, and this is something I'd like to get a handle on in advance. If I come across any other issues like this one, I will post them here.