Eric Terpstra

On web development. Mostly.

Show menu Hide menu

Tagcss

/ /

profile for eterps at Stack Overflow, Q&A for professional and enthusiast programmersI’m a big fan of Stack Overflow and use it on nearly a daily basis for reference.  Once in a while I’ll post or answer a question. Recently, an answer of mine regarding responsive design in the context of Twitter Bootstrap has gotten a lot of attention.   Just for kicks, I’m cleaning up the conversation and posting the meat and potatoes here.

Here are some jsFiddles to demonstrate the difference between fluid only and fluid + responsive.

Fluid-only: http://jsfiddle.net/5JECu/

Fluid-responsive: http://jsfiddle.net/ZnEEa/

Fixed-only: http://jsfiddle.net/eterpstra/ZR4zz/3/

Fixed-responsive: http://jsfiddle.net/eterpstra/rdvaG/12/

In the fixed width layout, the columns change when the browser window reaches a width defined in a media query. So when you have your window greater than 960px wide, it will stay at it’s maximum width. Then when you shrink your browser to 959px, it will snap to a new layout based on a media query that has a maximum width of 768px. So because you are viewing a fixed-width layout, the columns will not change when your browser width is between 768 and 960. Wen you are viewing a fluid-width layout, the column sizes will always change to match your browser’s width. The layout itself will also change in accordance to the media queries, as with a fixed-width layout.

When you decide between fixed width and fluid width you need to think in terms of your ENTIRE page. Generally, you want to pick one or the other, but not both.  In other words, the Scoaffolding page is using a fixed-width layout. The  and  on the Scaffolding page are not meant to be examples, but rather the documentation for implementing fixed and fluid width layouts.  The proper fixed width example is . The proper fluid width example is .

When observing Twitter’s , you should not see the content changing sizes when your browser is greater than 960px wide. This is the maximum (fixed) width of the page. Media queries in a fixed-width design will designate the minimum widths for particular styles. You will see this in action when you shrink your browser window and see the layout snap to a different size. Conversely, the fluid-width layout will always stretch to fit your browser window, no matter how wide it gets. The media queries indicate when the styles change, but the width of containers are always a percentage of your browser window (rather than a fixed number of pixels).

The ‘responsive’ media queries are all ready to go. You just need to decide if you want to use a fixed width or fluid width layout for your page.

When creating rows, be sure to use 

row

 with a fixed width layout, and 

row-fluid

 with a fluid width. Do not mix and match (unless you have a very good reason to do this).

I can’t tell what the difference is between twitter bootstrap fluid responsive vs non-responsive though… (asked by original poster)

Open the fluid example and maximize your window. Observe how the navigation menu is a horizontal list. Now slowly reduce the width of your browser. At some point, the navigation bar will change so that a button appears, and when the button is clicked, the menu appears as vertical. So with fluid, the only thing that changes is the width of the elements. With a responsive design, you can change any css rule based on the width of the browser. See my edited answer for some jsFiddle examples.

 

Learn Some Damn HTML (the right way)

October 7, 2008 / / 0 Comments

Everyone’s seems to be head over heels about standards based HTML/CSS these days.  Web designers and consultancies all seem to tout their ability to create standards compliant and accessible sites.  You just can’t use deprecated tags, and you must separate content from presentation if you want to be a high class webfellow. I remember way back when <center> and <font> were considered perfectly good HTML tags, but today web developers  scowl at these tags like a half eaten egg-roll in the buffet tray – it just shouldn’t be there any more, and anyone who considers partaking is icky.  Time to get serious and learn the correct way of doing things…

Getting Familiar with XHMTL/CSS

I thought I’d do some homework (boring!) and re-learn the HTML that I thought I once learned many moons before.  I fired up my web browser and looked up “HTML and CSS tutorials”.  There were only 22 million results, and the first one had something to do with learning HTML from a dog.  No thanks.

I eventually found the w3 schools, which is a great primer, and has the spectacular feature of trying out bits of code as you learn (learn by doing!).   There are scads of websites that are good for reference, but since I like to learn something new by doing something practical, rather than just reading text, a good tutorial or three suits me just fine. Here are a few links to do some good ol’ research on standards based XHTML/CSS:

Sometimes You Just Need a Good Book

Despite spending hour after hour poring over instructional websites, I didn’t feel like I was pulling it all together, nor in a position to build a fully functioning website.  I needed something comprehensive, something I could put my hands to, and something else that I couldn’t quite put my finger on.  I decided to swallow my pride and buy a book.

My first attempt at learning XHTML/CSS came a few years ago when I was first introduced to WordPress and Drupal.  I wanted to know more about how these tools worked, so I bought .  It was large, comprehensive, and utterly boring.  In short, it was a textbook.  Reading a standard textbook without a teacher to guide you and classmates to discuss the material with is an absolute challenge.  Needless to say, I didn’t get very far.  This was not the case with my most recent purchase – .  This book was spectacular!  It reads like a real person is talking to you, does not take itself seriously, and is based around bite sized projects large enough to teach you something, but short enough to keep your attention.

I did a fair amount of research before selecting the book, and the Head First series has received a lot of praise.  O’Reilly is definitely on to something here, and I’ll probably pick up a few more of their books as I progress in my career.  Rather than regurgitating tons of facts in an enormous tome and tacking on sample problems at the end of each section, the Head First book considers how people learn effectively and applies those educational principles in a way that makes it easier to learn difficult material.  Combine this book with the endless reference material and tutorials on the web, and it’s a snap to get up to speed on the foundations of building websites.

Get Graphics, Get More Practice

After wrapping my head around XHTML and CSS, I went in search of applying this knowledge to building a real site.  In order to have a halfway decent site that people want to look at, it’ll need to be visually appealing.  This requires graphics.

Before coding a site, one will often start with a mockup or wireframe.  These pre-websites are often made in Photoshop, with fancy graphics and what not.  There are a number of decent tutorials that walk through the practice of going from design to code using popular design packages (namely Adobe Photoshop and The GIMP).  Here are a couple good ones:

There is Always More to Learn

This post is a brief summary of what got me started down the path of building standards based code for the web.  There is much more to learn, and techniques are ever changing.  I didn’t even touch on cross-browser compatiblity and the necessary (but troublesome) browser hacks, nor any advanced CSS techniques.  I’ll likely post more info on these in time, as I get a greater handle on things.  I think the most important thing to know when starting to create websites is that not everyone views the web the same way I do.  Some people use Macs, or Internet Explorer 6, or Opera, or a cell phone.  Starting with a solid foundation in standards based code will go a long way towards pleasing a demanding audience.

© 2018 Eric Terpstra

Theme by Anders Norén — Up ↑