Flexible, Mobile-First Layouts with CSS3

Flexible, Mobile-First Layouts with CSS3

on Jun 28th 2010 with 27 comments
Tutorial Details
  • Program: CSS
  • Difficulty: Medium
  • Estimated Completion Time: 30-45 min
Download Source Files
Demo View It Online

Some experts are projecting mobile devices to become the dominant medium for web browsing within five years, overtaking browsing on desktop computers. Regardless of how accurate this projection turns out to be, it is clear that formatting websites for mobile-friendly viewing needs to become a staple of web design and development. There are many ways to accomplish this, of course. However, CSS3 provides a fairly rich toolset for mobile-friendly formatting, relying on the client’s browser capabilities instead of back-end templating.

Step 1. Think Ahead

There are a few issues that should be thought about before diving right into styling a layout.

Mobile Web Browsing

First, what should one keep in minds when designing for mobile browsers? Well, here are a few things…

  1. Limit HTTP requests: data transfer over 3G can be quite taxing. This includes limiting images where possible (from the CSS, for example).
  2. Varying screen sizes: Mobile devices tend to hover around the 320-480 pixel screen widths but can vary greatly depending on the device. So, predefining widths in the CSS is generally a bad idea for things like paragraphs and DIVs.
  3. Optimize for a subset: There are TONS of mobile devices, browsers, OS’s, etc. Try to focus your testing on what you assume to be the most important. For me, this includes iPhone, iPad, Blackberry, and Android. This list should also include Windows Mobile but I simply do not have access to a Windows Mobile device.
  4. Hover must die: Okay, that’s a little dramatic. However, touchscreens don’t tend to support hover. So, when building menus, don’t hide things behind hover events. Hover should only be used to enhance some effects (like color changes) not deliver important content (like drop-down menus).

“The overall point is to know ahead of time what your site is likely to look like in various browsers before seeing it.”

Browser Support (on Desktops)

Secondly, keep browser support in mind. The proverbial “elephant in the room” is IE, of course. Good news, though! As it turns out, websites don’t really need to look exactly the same in every browser. As long as it doesn’t interfere with the content of the website, generally a browser not capable of processing CSS3 will still provide a more-than-acceptable experience. The overall point is to know ahead of time what your site is likely to look like in various browsers before seeing it.

Step 2. The HTML

The Body

“Keep the markup simple and clean.”

Not only do we want to produce valid HTML, we also want to simplify it as much as possible. While it has always been a good idea to keep HTML streamlined and free of unnecessary DIVs, it is even more important now with the rise in mobile web browsing. Also, a lot of the effects that required 7 nested DIV tags can now be reproduced with a little CSS3.

Since this is not an HTML5 tutorial, I’m going to stick with XHTML strict. With that in mind, a lot of the markup here can be made even cleaner using some HTML5 elements. So, here’s some HTML for a typical layout. We’ve got a page containing a header, footer, content area, and sidebar.

<body>
  <div class='pg'>
    <div class='head'>
      <h1><a href='#'>My Blog</a></h1>
    </div>
    
    <div class='pg-main'>
      
      <div class='entries'>
        <h2><a href='#'>An Entry About Something</a></h2>
        <p class='preview'>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Fusce lorem elit, suscipit tempus pretium eget, varius ut erat. Donec lobortis est sit amet felis pellentesque vel egestas sapien iaculis. Maecenas eget quam nisi. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. </p>
        <p>Mauris nunc metus, pellentesque eget porta ut, facilisis ut metus. Etiam dignissim egestas semper. Aliquam tincidunt tortor non mi ultricies quis interdum quam scelerisque. Aenean risus libero, aliquam vel rhoncus sed, elementum eu leo. Pellentesque vitae ante urna, ut rhoncus sapien. In iaculis tristique lobortis. Nulla feugiat elit at odio dictum dignissim. Fusce tristique lacus nec justo porttitor egestas. Etiam vitae arcu risus, at interdum lacus. Ut dignissim, dui eu imperdiet accumsan, dui mauris hendrerit leo, vel fringilla mi ipsum vitae orci. Nulla libero quam, euismod eget rutrum sed, ullamcorper vitae felis. Mauris aliquam dignissim interdum. Sed sagittis blandit urna, sit amet pellentesque lorem egestas sed. Nam adipiscing, lorem non ornare volutpat, turpis ante sagittis elit, ac hendrerit arcu nunc ut est. Vivamus at arcu felis, eget porta odio.</p>
        <hr/>
        
        <h2><a href='#'>An Entry About Something Else</a></h2>
        <p class='preview'>Maecenas vitae metus ac est lobortis tincidunt laoreet et enim. Maecenas purus magna, condimentum at mattis vel, pellentesque sed nibh. Curabitur scelerisque pulvinar ante, quis pellentesque enim faucibus ac. Etiam suscipit fringilla mi, et tempor mauris convallis sit amet. Phasellus eros dolor, tempus at pulvinar ac, mollis sed eros. Morbi viverra pellentesque tellus, et tincidunt lectus fringilla non. Donec quis turpis in nunc venenatis rhoncus eget eget felis. Donec ut malesuada lorem. </p>
        <p>Vivamus placerat bibendum placerat. Nullam pretium, nisl vitae sodales rhoncus, ante massa ultricies purus, ac blandit ante felis sit amet erat. Nullam cursus ornare placerat. Sed accumsan malesuada iaculis. Proin suscipit ultrices mattis. Sed semper facilisis est in luctus. Etiam et quam a ligula laoreet iaculis vel quis leo. Etiam et purus a quam vehicula feugiat. Praesent ac ligula mi. Donec ut sapien in nunc sagittis interdum ac a tortor.</p>
        <hr/>
        
        <h2><a href='#'>A Third Entry</a></h2>
        <p class='preview'>Maecenas vitae metus ac est lobortis tincidunt laoreet et enim. Maecenas purus magna, condimentum at mattis vel, pellentesque sed nibh. Curabitur scelerisque pulvinar ante, quis pellentesque enim faucibus ac. Etiam suscipit fringilla mi, et tempor mauris convallis sit amet. Phasellus eros dolor, tempus at pulvinar ac, mollis sed eros. Morbi viverra pellentesque tellus, et tincidunt lectus fringilla non. Donec quis turpis in nunc venenatis rhoncus eget eget felis. Donec ut malesuada lorem. </p>
        <p>Vivamus placerat bibendum placerat. Nullam pretium, nisl vitae sodales rhoncus, ante massa ultricies purus, ac blandit ante felis sit amet erat. Nullam cursus ornare placerat. Sed accumsan malesuada iaculis. Proin suscipit ultrices mattis. Sed semper facilisis est in luctus. Etiam et quam a ligula laoreet iaculis vel quis leo. Etiam et purus a quam vehicula feugiat. Praesent ac ligula mi. Donec ut sapien in nunc sagittis interdum ac a tortor.</p>
      </div>
      
      <div class='sidebar'>
        <h2 class='not-there'>Blog Menu</h2>
        <h3 class='subscribe'>Subscribe</h3>
        <ul class='subscribe'>
          <li><a href='#'>RSS</a></li>
        </ul>
        <h3>Social</h3>
        <ul>
          <li><a href='#'>Facebook</a></li>
          <li><a href='#'>Twitter</a></li>
        </ul>
        <h3>Categories</h3>
        <ul>
          <li><a href='#'>Something</a></li>
          <li><a href='#'>Nothing</a></li>
          <li><a href='#'>All Things</a></li>
          <li><a href='#'>No Things</a></li>
        </ul>
        <h3>Archives</h3>
        <ul>
          <li><a href='#'>June 2010</a></li>
          <li><a href='#'>May 2010</a></li>
          <li><a href='#'>April 2010</a></li>
          <li><a href='#'>March 2010</a></li>
        </ul>
      </div>
    </div>
    
    <div class='foot'>
      <p>© No one in particular 2010</p>
    </div>
    
  </div>
</body>

As you can see, it’s a pretty simple and typical blog layout with a few article and some menu options in the sidebar.

Viewport Metadata

In our head element, we will put all the typical pieces like stylesheets, content type, title, etc. However, there is one extra piece that we will include to smooth out mobile browsers.

<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;"/>

This is a little metadata tag, suggested by Apple, to help iPhones render a page. It essentially auto-fits the page to the viewport and prevents zooming. Several other mobile browsers support this too, including Blackberry’s native browser. In my testing, keeping this tag doesn’t harm desktop browsing whatsoever. So, let’s just stick it in the head and forget about it.

Thinking About the Layout

This particular tutorial will focus on taking the above HTML and styling it into two layouts. One layout will be targeted at mobile browsing and one at desktop browsing. In practice, it will probably be useful to break such a layout into several different “targets.” However, for the sake of this simplicity, this tutorial will only focus on those two.

Step 3. The Mobile Styling

Disclaimer

The purpose of this tutorial is not to talk about rich typography or brilliant graphical design. So, the presentation here is kept very simple. What is important is the thought process that drives the stylesheet.

The Approach

The main thrust of all of this is to think about designing a mobile layout first. The reason for this is that its likely that whatever you come up with for a mobile devices will also work on a desktop. Then, instead of ending up with a thrown-together mobile layout and a brilliant desktop layout, you’ll start with a brilliant mobile layout and enhance it for desktop. This will also make sure that your website doesn’t lose its audience as the world goes mobile.

The Inspiration

This approach is inspired by Luke Wroblewski who spoke at An Event Apart in Boston this year. His presentation was centered around thinking “Mobile First”.

While this tutorial does not capture his presentation in any sort of entirety, one piece of it hit home more than the rest (for me). The current trend is design is to work on the desktop version of a website first, then strip it down and throw together a mobile website if there is time. Instead, we should start to design for the mobile world first, then change that design as desired for the desktop. The rational is essentially one of progressive enhancement… if the design is useful on mobile, it will work on desktop also. The reverse, however, is not usually true.

Some CSS

So, let’s think about mobile browsing for a moment. Long scrolling screens are difficult to deal with. So, let’s take the blog menu list items and make them easier to deal with.

.sidebar ul{
  border-left:solid 1px #ccc;
  padding:0 0 0 5px;
}
.sidebar ul li{
  display:inline;
  padding:0 5px 0 0px;
  border-right:solid 1px #ccc;
}

That should give us a nice, clean-looking menu with some pipe-looking separators. You’ll notice that I didn’t choose to move the menu away from the bottom of the screen. Menus at the bottom can be useful in mobile browsing. If you think about scrolling through a webpage, when you get to the bottom you’d have to scroll all the way back up in order to go somewhere else. Depending on the device, scrolling can be somewhat burdensome. There are pros and cons to this method but in this case, I think it works well.

However, I would like to move the RSS to the top banner, so let’s do that too.

h3.subscribe{
  display:none;
}
.sidebar ul.subscribe{
  position:absolute;
  top:25px;
  right:10px;
  border:none;
  color:#fff;
}
.sidebar ul.subscribe li{
  border:none;
}

Aside from that, the rest is pretty much just some font-sizing of the heading elements and coloring of the anchors. For the purposes of this tutorial, I included a CSS-reset at the top of the sheet just for simplicity. The full CSS sheet can be found in the source code for this tutorial.

As you can see, there isn’t really anything special about the mobile styling when approaching design from a mobile-first angle. Instead of thinking, “what do I want this to look like on my screen,” you think “how can I use styling to make this most useful on a mobile device.”

Step 4. The Desktop Styling

Media Query

In case you haven’t guessed it, this whole thing is going to end up being driven by CSS3 media query. In case you aren’t familiar, media query is a way for the stylesheet to flip declarations on and off based on various conditions. One such condition, and the topic of this sheet, is screen dimensions.

Again, the full CSS can be found in the source attached to this tutorial but let’s examine this for a moment:

.pg{
  width:800px;
  margin:0 auto;
}

In this case, we don’t really want an 800px page width unless we are sure the user’s browser window is at least 800px wide. Otherwise, we will end up with one of those annoying horizontal scrollbars.

So, we’re going to wrap that declaration (along with several others) inside a media query.

@media all and (min-width:800px){
  .pg{
    width:800px;
    margin:0 auto;
  }
}

That reads pretty easily, right? The “all” refers to “use this style for all types of media.” There are other things that can go here, such as “print” for printer but there isn’t a lot of consistent support. Anyhow, “all” will work just fine for this.

“Override” Previous Styles

We will put a lot of other stuff inside this media query too but the important thing to remember is to essentially override previous styles and add some new ones to achieve the new layout. This will allow browsers that do not support media query to simply fall back on the original styling. Even though they are optimized for mobile, there’s nothing wrong with displaying that layout on a less-capable desktop browser.

For example, we’ll move that sidebar out of the bottom and make the lists look like lists again.

@media all and (min-width:800px){
  .sidebar ul{
    border:none;
    padding:0;
  }
  .sidebar ul li{
    display:block;
    padding:0;
    border:none;
  }
  h3.subscribe{
    display:block;
  }
  .sidebar ul.subscribe{
    position:static;
    top:auto;
    right:auto;
    border:inherit;
    color:inherit;
  }
  .sidebar ul.subscribe li{
    border:inherit;
  }
}

That will put the sidebar off to the left (combined with a couple other floats found in the stylesheet) and place the subscribe back where it belongs for people browsing the site in atleast 800px width.

So, if you open up the source in a browser and resize it horizontally, you’ll be able to watch the layout flip between the desktop format and the mobile-friendly format

You may be asking yourself, why 800px? Is there anything magical about an 800px width? No. In fact, I would argue that it is too wide. With the introduction of “snap” in Windows 7, I would argue that 600px should be the new target width for a desktop website. That way, the browser can be “snapped” to the right or left on a 1280px screen and still maintain its layout. However, this is really neither here nor there. Just be aware that 800px isn’t anything special.

Browser Support

Important: The website will be styled as the mobile version in IE8 and below. Is this okay? I think so. Also, I’ve done this before and so far no one has arrested me. Plus, media query support is promised in IE9.

Step 5. Alternative Methods

This isn’t the only way to accomplish this. However, the purpose of this tutorial was to show a very practical use for media query and present some ideas of mobile layouts based on CSS only.

That said, here’s a few other ways to put together a mobile layout…

  • Serve different templates: If you have access to the templates for the site, a themeing system can usually be put in place where the requesting browser is detected, then a different HTML template is served based on the type of browser (mobile or not). This is usually accompanied by a separate set of CSS as well.
  • Subdomains: m., mobile., and .mobi tend to be the standards here, where an entirely different website is served. That said, it’s usually the same as “serve different templates” to avoid content duplication.
  • Fluid layouts: One can also make their layout completely fluid such that no matter what size the browser window, the content adjusts itself. In fact, the “mobile” stylesheet in this tutorial is a fluid layout. The nice thing about using media queries is that you can reduce the background-images and produce fewer HTTP requests.

There are likely several other methods of handling mobile web browsing but often it will come down to a hybrid of some sort. However, whether it’s a fluid layout with certain “kick” points based on media query or a subdomain redirection serving different templates, the important thing is begin planning mobile layouts ahead of time, so that your websites don’t become increasingly less useful over the next 5 years.

 
Enjoyed this Post?

Subscribe to our RSS Feed, Follow us on Twitter or simply recommend us to friends and colleagues!

By

Rollover to read this author's bio or click through to see a full list of posts by this author.

This author has yet to write their bio.  

Plus Premium
 
 
Note: Want to add some source code? Type <pre><code> before it and </code></pre> after it. Find out more
  • http://www.therustedmusket.com Tony

    Very nice! Now if only IE6 would die (well, I suppose a few other browser version would have to die to support all the cool CSS3 stuff)… Seeing as how the iPhone’s Safari browser has good support for CSS3 it does make sense to code CSS3 for the mobile space. I would hope there is more browser innovation there considering the faster hardware/software turnaround.

  • http://frijal.com/about Rijal

    Hi there…
    You’re master on web design…
    I hope you create this for WordPress too…
    Thanks for your appreciation. ;)

  • http://www.codecrunchers.net Kevin Groenendaal

    Very great article! I remember this website made it that way! :D

    http://hicksdesign.co.uk/journal/

  • http://taylorhutchison.com Taylor Hutchison

    While I always think choice is a great option, the fact the new phones come with HTML5/CSS3 is a great thing for developers. I have have a hard time convincing myself to “fork” my sites for different browsers but for some reason I am much more willing to fork between mobile and desktop.

  • ScaraX

    Nice article, but why do you force the user to keep the initial zoom level?
    using “width=device-width; initial-scale=1.0;” insted of “width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;” should do the job!

    Additionally, I have tested your page with my Motorola Milestone (resolution 480 x 854) and it looks like the implementation is quite strange:

    with the “viewport” meta-tag, I always see the mobile layout, even in landscape mode (> 800px).
    if i change the media query to “min-width:400px”, i see the mobile layout in portrait mode and the blog layout in landscape mode.
    I think the Android browser internally uses the iPhone-Resolution for these queries so it can display iPhone-optimized websites.

    If I remove the “viewport” meta-tag, i always see the desktop layout, in portrait and landscape mode.
    If i change it in “min-width:900px”, i always see the mobile layout.

    As long as these media queries use the iPhone relolution instead of the real device resolution i wouldn’t use this.

    Another problem with the media queries is that i have no possibility to switch to the desktop version…

    Personally, when browsing on my Milestone I prefer the original websites (usually designed for a screen width of 960px with a content column size of 600-800px) to the iPhone optimized websites with a forced zoom level and optimized for 480px width…

    • Brant
      Author

      Thanks for the feedback.

      As for the viewport, I prefer to disable zooming… but I think its mostly because of Opera Mini on the Blackberry. That particular browser makes it pretty easy to accidentally zoom. My hope is that with the layout being formatted for mobile, it may not be necessary to zoom.

      You’re probably right though, zooming should probably be left intact.

  • http://www.tunetek.square7.ch/tunetek/index.php Basti

    Very nice ;)

  • John

    “As it turns out, websites don’t really need to look exactly the same in every browser.”

    Funny as it may be, just cause Dan Cederholm made a website with that says “NO” does not make it true. I know there are some alleged “experts” who’s portfolios are so weak I would not hire them, saying the same thing. And, while I wish it were true, it is NOT true.

    Any real client will require it to look identical in every browser including IE6. I have yet to hear an argument for not making things look identical that doesn’t sound lazy. And I don’t mean your youth groups ministry site, or your blog, or the bike shop down the street. I am talking about real clients, guys who actually pay your bills. The kind of clients you deal with a marketing project manager, and not an owner type of clients.

    I have done work for Apple, AT&T, Sage, and several others, and I would be fired on the spot if I tried to say that their design didn’t need to look the same. Besides most companies have a separate mobile site for these purposes.

    • Rich

      6 months ago I would have agreed, but things seem to be changing. I also work with large multi-national corporations and they are generally starting to accept, with some ‘education’ from us, that while sites need to be presentable and function correctly in all browsers they don’t need to be completely identical. I think there are a few reasons for this: clients wanting to take advantage of new tech, their internal infrastructure being updated to more modern browsers(in some cases), mobile fracturing encouraging the idea of varied experience between platforms.

      Regarding the tutorial’s premise, I think there are some issues with the idea of designing for mobile first. The problem is that mobile users have different goals than users browsing from normal machines. Therefore, the presentation and functionality of the site should reflect this and not try to accomodate both. Even when sites manage to achieve the same design as the desktop equivalent, the user experience is generally awful so I think separate subdomains targeting the needs of mobile users is the way forward.

      • John

        I definitely agree, mobile and desktop users have different goals. Using sub-domains for mobile makes the more sense than designing for mobile first.

        Now if I could only get my clients to accept the IE thing. I have clients that still use IE6 because it is the corporate standard.

      • Matt

        If you think of mobile design as “limited screen width” design, suddenly it makes sense to design once, style twice, rather than design and style for multiple devices on separate sub-domains. I’m not, of course, talking about so-called rich internet applications which may by necessity work differently in the mobile space for not just screen size but interface reasons.

        More than likely we’ll see mobile browser makers continue to improve mobile browsing for wide screen-centric sites and non-touch screen friendly controls, while we implement new sites with flexible designs.

        Either way, I don’t think anyone can do better than wildly guess how and with what we will in five years be browsing the internet. One thing is for sure: only the die hard (e.g., guys who really need quad SLI, etc.) will still think about hardware, and the operating system will become transparent, too. Apple has been on the right track for decades: make the computer transparent to the user. iPhones, iPads, and Droids are the next step, and I believe they will feed back into the desktop environment.

      • Rich

        I think the problem is that the differences between mobile and desktop sites is far more than a difference in screen size and browser capabilities. Even if mobile browsers were as capable, I don’t think it would make sense to serve content in the same way to mobile users. They generally want information quickly and easily. Desktop users however may want to read around the subject, see supporting material, etc. This may change as mobile browsing becomes more common as the primary way people view sites, but at the moment there is a clear division.

    • Brant
      Author

      The website link is clearly (at least in my mind) there for comedic effect… I’m hardly trying to cite a website that says “nope” as a credible source.

      More to the point, yes I agree that “corporate” clients will want the cross-browser layout to be similar, if not identical. That said, I think this “different look in different browsers” movement represents a mindset shift that is beginning to look quite appealing, especially considering the volume of mobile devices being produced.

      It isn’t about laziness, it’s about optimizing the website experience based on the browser capabilities. Admittedly, this tutorial shows a _very_ simple example but CSS3 does provide some powerful tools; tools that will take their place among a larger toolset, I suspect.

  • DJ

    On the whole I agree pretty much with most of the concepts you espouse, the implementation – not so much. I like “future-proofing.”

    And, I realize the purpose of the article is to have it published and a good way to do that is to do “bleeding edge” stuff, however bailing on reality and boarding the “it might happen” bus – not yet. In addition, Your stated position: “The website will be styled as the mobile version in IE8 and below. Is this okay? I think so.” mentality, I have to admit, offends me a little.

    Ok, I agree that IE6 has served its purpose (and then some); but IE7 and IE8 are fairly new and I don’t think that we have to be so arrogant that we can’t use our skills to “take care” of users of those systems. Real people have invested a lot of time and money in systems which support those browsers, for whatever reason; and even if it isn’t to your liking, that’s what they have obtained (and in many cases all they are able to.) In a lot of cases, those real people are seniors with “hand-me-down” systems (from their kids) or other such limitations.

    But under your scheme of things – we can’t just let IE7 and IE8 users be – we should degrade their experience NOW! To me, that seems just plain lazy. You/we all can do better. Even if your rhetoric is true you said yourself that it’s only “some” experts who are “projecting” what “might” happen – and ramp up is 5 YEARS! As long a way as they have already come, price points, user interfaces, display technology and individual privacy still need to improve a very, very long way before – THE PHONE – matures to take over the population’s default browsing over what a desktop display can provide now.

    It may happen, and probably will, but hopefully not before programmers/designers have matured enough as well so as to come from an ethic of “diversity” and not just take the “lazy way out.” I don’t think we need to euthanize the web in order to make your dreams happen more quickly.

  • http://www.jordanwalker.net Jordan Walker

    Great tutorial on mobile web styles.

  • Ubuntu

    Just wondering if you have any good resources for mobile device detection and redirect?

  • http://ryanswedal.com Ryan

    Good article. While I don’t necessarily think that the mobile layout should be developed first, I do think we should be giving more forethought to how the site will be presented on mobile devices. Of course, the approach will always depend on the specific project. It may make sense to create a separate mobile site on a subdomain or it may only require some mobile optimized CSS. If your sites focus is mainly towards mobile users then it may make sense to design the mobile layout first and perhaps it might even make sense to utilize that layout for IE users. The main things is to make sure mobile layout is a part of your initial planning process and not just an afterthought.

    So now, DJ, I have to add my two cents regarding IE…

    I agree that with a little extra effort we can assure that IE users don’t get a degraded experience. We, developers, should not shun IE users like Microsoft has shunned us. However, the true “laziness” is with Microsoft and the IE development team. I mean they essentially went on hiatus for several years. Now, in the last few years, they have developed two new versions with another on the way and they still have yet to be classified as a modern browser.

    While real people have invested in Microsoft products, for whatever reason, real clients have also incurred additional expenses in order to develop their sites for IE. Choosing to utilize the power of CSS3 and other progressive enhancements and being OK with a “downgraded” experience for IE users isn’t always about laziness. I hope that more and more real people are starting to see downgraded or even broken websites in IE and stop saying: “Wow, that must be one lazy web developer” and start writing Microsoft to ask why their browser is defective.

    • Dom

      If you look at http://gs.statcounter.com/#browser_version-ww-monthly-200906-201007

      IE 6 is virtually dead, it’s down to governments and corporations essentially. My theory is if someone is using IE 6, it’s either because their PC is vastly outdated, or they refused the upgrades…

      IE is always the absolute last thing I make my designs compatible for, I even do oldish Java based mobile compatibility before I touch Internet Explorer.

      • http://www.wpsnippets.com Flick

        If it’s any help: my work PC is what I regard as fairly new (circa December 2009) but it still only has IE6.0 because of IT restrictions.

        I work for a public/govt organisation, so I doubt it’s going to change any time soon, along with many other organisations.

  • http://www.vivacases.com cell phone leather Flip cases

    Viva Creation has released a series of Genuine cell phone leather Flip cases for the iPhone 3GS. Riding on the popularity of their Snakeskin and Carbono cases, it is no surprising that they will release these series of real premium calfskin leather cases for the iPhone 3GS.

  • http://viral-notebook.com Michael

    Nice layout and CSS styling. I like what this method offers for mobile learning. Thanks for the effort and tips.

  • http://northmoorpodcast.com TIm White

    Great tutorial, and a good discussion-sparker.

    In the corporate world, I think there is room for the progressive-enhancement approach…but it has to be messaged carefully.

    Good discussion as well.

    For me the main thing is that you can do the new site now, and it runs fast and looks good for the people who are most excited about that.

    As long as it’s not broken in IE, it’s ok if it’s not AS good looking.

  • http://www.rehabilitasyonturkiye.com rehabilitasyon

    Hi, I’m beginning to learn css program. Write your thank you letter will help me a lot of work.

  • http://funnyfacebook.tk gecko

    I think you will explain a boring one colomn layout. it’s awesome. tanks

  • http://www.wpsnippets.com Flick

    Just to say that the test site looks just fine when viewed with an HTC Hero (3.2″ screen)

    Thanks for an excellent tutorial. I’m looking forward to building a test site using the code above.

  • http://paperisboring.blogspot.com/ Ken

    Great post but sure I agree with designing for mobile first.

    It makes sense if that is your primary goal but most sites see less mobile than they do desktop browsers. Of course there are exceptions. But if you want the same flexibility of style sheets snapping and popping styles appropriate for the different resolutions you can just tweak the example code. Put your main sheet at the top set the @media to a max-width and put that below. So the mobile styles override the main ones. Like this:

    I haven’t done extensive testing but seems to work for me.

  • http://www.gadtecho.com Kumar Gaurav

    Good tutorial…