Well… lemme see if I can explain it piece by piece.
The markup is pretty much your normal semantic markup for a website. Headings to start each subsections, horizonatal rules for semantic section breaks when a heading might not be appropriate (like before the footer) or for consistency of flow (between the menu and the content area). If you view the page with CSS off, you get a decent idea of what screen readers, search engines, and people on narrow bandwidth who disable … everything… tend to see. That’s why we have the concept of progressively enhancing a page; write the markup first with no real concern for what it’s going to look like on screen, print, or any other specific target.
The ‘magic’ of the markup are our presentational hooks. It should be noted that presentational hooks are NOT presentation – it’s why we have DIV and SPAN, to allow us to hook into the content without changing the meaning… that our content should already have.
It’s also why HTML 5’s “section”, “nav”, “header” etc are a pointless waste of markup, and amount to applying meaning around things that already have meaning.
div#pageWrapper as the outermost container is naturally used to control our widths across the entire page. It’s SO much easier to use one element for that than to waste time declaring widths on every last little blasted thing. This is where a LOT of people screw up on their page designs and CSS.
div#columnWrapper is there to contain our floats, and provide any extra style we might want. If you want to add something like faux-columns, this element would be where that would go.
div#contentWrapper, div#content – using a double wrapper lets us do a holy-grail type layout of having the most important thing – the main content, be our fuild center column and keep it first in the source order – without the headaches and hacks needed to implement it using just one DIV… oh noes, an extra DIV that’s actually serving a purpose. (You’ll see me railing against pointless DIV all the time – this isn’t one of them!)
The outer div#contentWrapper is floated at 100% width, so it takes up the entire screen. The inner DIV gets margins to make room for the columns to be rendered over, and normal padding.
div#firstSideBar and div#secondSideBar would be our two seperate columns for the three column layout – but to treat them as a single column we have to wrap both of them in a third div.
For the two column layout, our default which as discussed so far is the ‘lowest common denominator’ of desktop browsers that don’t know media queries, simply applies a right margin to Content… then uses the classic holy grail trick of a negative margin on #sideBarWrapper to reduce it’s width below 0px.
#contentWrapper is 100% width and floated left – so there’s no pixels left for a float to go next to it. Using the negative margin to make #sideBarWrapper 0 width or narrower, floats it up OVER it. Poof, two columns.
Our first media query for making the three column layout uses this:
<link
type="text/css"
rel="stylesheet"
href="bigScreen.css"
media="screen and (min-width:64em)"
/>
Which means any screen device wider than 64em gets that stylesheet layered on top of the non-query one.
Inside that stylesheet all I do to make the third column is put a margin on each side of Content to make a place for the sidebars to render, strip the style off the outer #sideBarWrapper and instead apply columns to the inner #firstSideBar and #secondSideBar.
I set them both to the same width, and float them both the same way. For the second sidebar I just swap what side the margin is on, making it overlap to the right instead of the left, and then slide it back over -100%… basically the normal holy-grail type three column layout. IF you want them reversed with the first one on the left, just change the standalone #secondSideBar to #firstSidebar. You could even do this:
#content {
margin:0 38em 0 0;
}
#sideBarWrapper {
float:none;
width:auto;
margin:0;
}
#firstSideBar,
#secondSideBar {
position:relative;
float:left;
width:18em;
margin-left:-19em;
}
#secondSideBar {
left:-19em;
}
It also increases the max-width. You have to remember I designed for queryless FIRST… if we can go to three columns using queries, we can go wider.
For the small screen version, we just want to strip out the columns… so first, let’s target small screens:
<link
type="text/css"
rel="stylesheet"
href="smallScreen.css"
media="screen and (max-width:640px)"
/>
Anything 640px or narrower gets that stylesheet applied to it in additon to our queryless one. All I did here was decrease the min-width to that of the lowest end Opera mini devices. Anything smaller… really shouldn’t be used for web browsing or is going to ignore all this anyways. I set the width to 100% so it goes edge to edge – screen real-estate on small screens is precious, don’t waste it on a background…
Stripping off the columns is then easy. Get rid of all the margins, remove the floats on #sideBarWrapper. On a real layout you may have other styling you might also want to strip off it – I would advise stripping background off of body, so the mobile browser isn’t wasting time trying to render or load it. Excessive use of CSS3 properties can really hog memory and slow down rendering, so axing a number of those can also help.
Testing is important on that; getting a real iPod/Pad/Phone AND a droid device is a good start – though getting a Mac, building a Hackintosh, or tricking OSX into running under VirtualBox to use the iOS Simulator that comes with xCode lets you nab several Apple devices at once.
I have a legal Hackintosh to that end – cute loophole; you can only legally run OSX on Apple branded hardware. I gave my ‘parts pile’ Apple IIe Platinum (no psu, busted mainboard – as opposed to my good one that still runs fine) a ‘upgrade’ by stuffing a Atom 330 motherboard and the USB keyboard from a dead G3 iMac into it… Though I’m thinking on using this dead G5 Tower a friend gave me with a i7 920 board for a more capable one.)
Again why I consider this an example, NOT a framework to be perfectly copied. On top of the idiocy of frameworks in interpreted code on narrow pipes, they are often inflexible or require so much effort to learn well enough to modify with confidence, you’d be better off just working with scratch for each different type of page.
It’s all about the process of building up a page with progressive enhancement… Content should dictate layout, NOT the other way around. Make your non-css semantic page, use CSS to bend it to your will for non-media query screen and print, then use media queries to further refine screen by size. That way when/if some fancy bit of new technology is missing, it gracefully degrades.
… and again why drawing some goofy picture of a layout in Photoshop first tends to be little more than a disaster filled with ‘not viable for web deployment’ concepts.