6 Tips for CSS Layout Design

CSS is clear-cut and simple for users to learn. There are colors, fonts, and columns, that are simple to use for people, but some will just run into many problems. In order for CSS to be clean on your layout there are a few key points that you need to make a strong CSS layout that is reliable on any browser. Below are six key points that should help your problems with CSS.

Image Substitute

Dull content elements aren’t very vivid to the users. You want to have a Web 2.0 sleek style of images with gloss and gradients. Also instead of using web based fonts that come with Photoshop we need custom fonts that stand out. With image replacement we can use tasteful images or Flash images instead of text.

•Revised Image Substitution
Sums up most, if not all, of the image replacement techniques currently in use.
•Documentation

Floated Menu

Floating columns are similar to floating menus or floating navigations but navigation is trickier although more frequently used as well. Webmasters enjoy nice clean navigation menus in order to find their way through websites.

•Listamatic
•Sliding Doors

Box Model

Box Model’s are the center of CSS. You are probably familiar with margins and padding but when the essentials begin to flow in the programming you don’t know what happens. If you are aware of the browsers of the internet including Firefox, Internet Explorer, Opera, and more you know about cross-browsing. A CSS layout may look best in one browser but turn out as s**t in another browser. If you learn the box model then you can be perceptive on the unique peculiarity of different browsers. Box Model’s are also good to know for those old fashioned browsers.

•W3C CSS2.1 Spec
•The Box Model
•Box model hack
•Doctype

Floated Columns

Complete placement was a key concept when users move towards substituting table-based layouts, then came floating columns that created the genius of CSS. If you learn how to float you can be familiar with many different techniques such as placing images or more over the use of Advertisements such as banners, adsense, and more. Whilst learning the float method you also have to understand how to clear floats so backgrounds of layouts show accurately.

•Floatorial
•Clearing floats
•Faux Columns
•Creating Liquid Faux Columns

Sizing Using Ems

Text for the screen is sized with CSS in terms of pixels, ems or keywords. Pixels is easy, keywords are well documented. That leaves ems. Although there are two recurring problems that appear when sizing ems; those are layouts and fonts.

Using fonts with Internet Explorer 6 and lower (which is why I don’t use Internet Explorer but Firefox) doesn’t let you resize text with your specified pixels. Some people have a tough time seeing the text clearer so users may want to increase the font size to a larger format for reading. Instead of using pixels using size ems can ultimately compare as a more standard and common loom to this dilemma. As the evolvement of higher level browsers such as Firefox occurs the movement to more advanced programming methods which is CSS.

When sizing layouts using ems you can use a higher level of understanding then using pixels, texts, or keywords. If you muddle with HTML on text and font sizes you can come out throwing the layout out of balance. Using ems you can preserve the quality of the layout.

•How to size text using ems
•Elastic Design
•Fixed or fluid width?

Sprites

Formally and more commonly used in video games, compiling more than one image into just a single image is an accepted method to figure out more than one problem. More recently, it's been proven to be advantageous to combine multiple images (in particular background images used in image replacement techniques) into a single file. This method can simplify the response number your server has to apprehend, improving the time required to download all files on the webpage decreasing page load time.

•Fast Rollovers without Preload
•CSS Sprites
•Reducing HTTP Requests

CSS has a vast variety of features that cannot be summed up easily, look around the Dev Network or ask in the CSS forums for help on your CSS real time problems. Digg this story.

 

Bookmarked this, looks interesting, will eventually look into it when I get some time. Thanks.

 

Just bear in mind that a lot of the techniques in there are quickly getting dated (as in old).

 

Hmm and what is making them obsolete?

 

Ok, let me give you a few examples.

The image replacement techniques for the most part are inaccessible to people using screen readers, and one of them (the technique that uses the same background and foreground color for the text) can get your site banned from the search engines for hiding content from the users that they can't see (but the search engines can spot from a mile away). Of the ones used, the Gilder/Levin approach (with Dave Shea's enhancement of adding an appropriate title="" attribute) is best of the bunch reviewd on that page, despite the drawback of not being able to use transparent backgrounds.

The Box Model Hack is also prone to accessibility issues, since the voice family hack can cause screen readers to go utterly BONKERS when it's encountered. It's best to use a simplified version of the Box Model Hack for IE 5 (if you're having BM problems in IE 6, you need to use a complete and proper DOCTYPE). However, nine times out of ten even THESE issues in IE 5 can be avoided by collapsing margins and padding on the containing elements (like menus and sidebar DIVs) and applying these properties to their children instead.

Here's the Simplified Box ModeL Hack for your viewing pleasure:

	#sidebar {
		background: #FFC;
		display: inline;				/* IE 5 and 6 bug fix */
		float: right;
		padding: 0 1em;					/* this is what causes the box model problem in IE 5.x */
		width: 11em;
	}
	
	* html #sidebar {					/* IE 5.x Box Model Hack */
		width:13em;
		w\idth: 11em;
	}

Code (markup):

This is the style rule for a sidebar DIV being floated to the right in a three column layout. The style rule has a hack applied to it immediately afterword to correct a box model problem in IE 5 and 5.5 - however, it could have been prevented if the padding on the #sidebar DIV (I used the universal selector previously to strip the margins and padding off all the elements on the page so I could reset them to the amounts I wanted when needed) had not been placed on the sidebar DIV itself. Putting the padding on its direct children would have prevented the need for the hack in the first place.

Given that the hack is hidden from other browsers via the * HTML selector, there's no need to "be nice to Opera 5" since Opera 5 isn't used anymore (we're very fanatical about keeping our browsers updated). My God, Kestrel (Opera 9.5) is coming out soon, and that will be followed by Opera 10. It would be like using IE 3 to view your favorite Web sites. It's just that crazy!

By the way, in case you're wondering, the sidebar appears after the content (which is floated with a 100% width and negative margins, and then has a wrapper inside that with positive margins to snap the sidebar into place when it too is floated), which causes a double margin bug in IE 5/6. To solve that, I used display: inline; right alongside the float property to kill the margins.

 

The even simpler solution being to put margins on your content INSIDE #sidebar instead of padding on #sidebar itself.

My problems with the original post are more the wording than the intent... "Image subsitute" is not the term commonly used, and makes it sound like you are using something instead of images - Image Substitution would be more correct, though the term more commonly used is image replacement - using images to replace text content 1:1. As Dan pointed out most of the techniques listed on the pages linked to don't 'degrade' well with Glider-levin being the best of the lot. Oh well, it doesn't let you use transparancies - if you cannot color match and/or line up the image dynamically, you probably shouldn't be using images in the first place... (much less that alpha transparancies end up monstrously large files for little REAL gain)

Personally, I reverse glider-levin to put the empty span AFTER my content - Usually using a negative margin to pull the image up over my text, though I will occasionally use the relative outer/absolute inner method as well. (depends on my content)

What those pages do NOT cover, is that you can design the inner content to contain not only the same text as your image, but placement and coloration as well. Images off you should strive for the closest appearance to images on.

- What in blazes does that even mean? Glittering generality much? Then you go into that stupid Web 2.0 bullshit which has nothing to do with techniques that have been commonplace since 1997.

I still cannot figure out what in blazes 'floated menu' has to do with the image-replacement techniques of your second section -

- Say WHAT?!?

Box Model’s are the center of CSS. I think you mean layout, since the box model also plays into pure html designs. You then go into something that seems completely unrelated, and load up on hacks that are IE 5.x specific which frankly, we can drop support for these days. You RARELY have to hack IE6 to get box model same as 'rest of world' if you include a doctype - and when you do, it's usually something stupid like haslayout or lack of min-width/min-height.

Why do I have the feeling I'm reading a conversation between Zathras and Yoda? The intent here is good, but the language is incomprehensable...

The sizing via EM's section - what in blazes do keywords have to do with text sizing. Keywords is not a measurement of font sizes, and in fact last time I checked the only thing it has to do with a website is as a metatag.

I have NO clue what you are trying to say there... even substituting THAN for THEN it's still gibberish and another glittering generality. There is no 'higher understanding' - it's just another metric in which to measure things, with it's own unique set of advantages and disadvantages.

The only REAL advantage EM (and %) brings to the table over other measurements is the ability for IE 6 and earlier users to resize your text.

It brings a LOT of disadvantages: A lack of granularity introducing rounding errors that lead to different font sizes and line-heights between operating systems. Firefox and Safari flat out ignoring the system metric on windows and linux so large font/120dpi (100dpi *nix) users of those browsers have to dive for the zoom every time they come to your page.

There's a whole host of issues with it - which can be seen quite clearly here:
http://battletech.hopto.org/for_others/font_test.html

'default size' is what %/em would be based on, see the problems?

EM layouts end up #2 on my list of causes for people's broken site headaches right behind people using WYSIWYG's like Dreamweaver.

Again, no clue what you mean, unless you are referring to Firefox and IE6 still resizing content like Mosaic's sweetly retarded crack addict cousin.

A Sprite is a single image that is moved around the screen - which oddly enough is NOT what you are referring to. While yes image recombination techniques using sliding backgrounds do condense it down to a single image, that is NOT what 'sprite' means.

Response number? Apprehend? Again, I think I know WHAT you are trying to say, but the use of language means either a lack of understanding the topic, or a lack of understanding the language... though I have a sneaking suspicion the answer is both.

The whole thing top to bottom is little more than gibberish that talks about techniques without even saying what they are or how to use them, followed by links to sites that are 'kind of' related to what was said, but leads to more questions than answers.

/FAIL/ at intarweb.

 

I am not a pro at CSS I just put what I knew and because of that I added links to help support more. But anyways I like using "glittery" sophisticated vocab.

 

And I prefer plain, conversational language that everyone can understand.

Anyway deathshadow, regarding your comment about putting the margins and padding on child elements to avoid the hack, I said that. Twice, in fact. The hack (and the problem caused by the margins/padding) was provided as an example. If you look at the code snip, you'll see I have a comment there that flat out says it's what's causing the problem in the first place.

It was an example for educational purposes (don't do this, but if you must, here's how you can fix it without having screen readers go berzerk).

 

thanks for the info, CSS is a great way for styling, but it absolutly lack standards. Sometimes it is so hard to make it perfect both on IE and firefox

 

Actually it does have standards, and can be used to lay out pages that render identically cross-browser. Most people just don't know how do it properly at first. It's something that takes time to get used to. Deathshadow and I are working on a Web site that will teach how to do this properly (read: our way) using the bare minimum of clean, semantic and valid HTML and CSS. Ironically the Web site is going to be called minimalmarkup.com (it hasn't launched yet, obviously).

 

Maybe it's more because not all the browsers are standard. My husband is a programmer (in Perl even, with it's "more than one way to do it" theme), and can't make heads or tails of CSS. He's decided CSS was written by designers and not programmers. He's repeatedly said the same thing as Directory SEO.

 

Actually, in terms of how it is applied it was written by programmers... the problem is the 'variables' were made by designers.

The biggest thing for a programmer coming into CSS to remember/learn is that you are pretty much working with the DOM directly. Document OBJECT Model - key word there being OBJECT.

In CSS and .js an HTML document is treated as an object - every single CSS property being a sub-property of that object.... which is why you have direct access to every css property via javascript under element.style. Properties can be overloaded via source order, have precedence by type just like elves in Modula... the only thing missing being TRUE inheretance and a differentiation between virtual and normal objects.

Once you realize that the CSS:

h2 {
color:#FFF;
background:#000;
}

Is the same as the following Wirth style psuedocode

type
  h2=object (element) 
    color:dword=$00FFFFFF;
    background-color:dword=$00000000;
  end;

Code (markup):

You're set as far as syntax goes.

Of course, if you never learned OOP or "structured type languages" then both CSS and Javascript are going to be difficult to grasp.

The only other real issue one could have with CSS is grasping the box model and the various interpretations the browser makers have made of it - which if you use a valid doctype, no XML prolog and don't give a **** about IE 5.x... 95%+ of the compatability problems between IE and RoW goes away, the handful of remaining issues being little more than tripping haslayout, working around the lack of min-width/min-height in IE6/earlier, IE sizing form inputs differently, and FF lacking full support for colgroups and malfing up fieldsets and caption. (solution on that last one? Don't use positioning or margins on fieldsets and captions.)

I'm playing with making my own terminology for how the box model works... based more on implementation than specification (which are miles apart). The W3C separation of the box model into margin, border, padding and content does not take into account that position:relative moves the inner 3 as a group without effecting 'flow positioning' - which is why I think of it in my mind as two separate boxes - Flow and Render. Much simpler since those inner three 99.99% of the time act as one when making a layout.

The way I like to think of it (and oddly enough how it seems to be handled inside the browsers) is that they are two separate entities that just happen to start out at the same size and position based on padding, borders and actual content width - but margins can change the size of the flow box without changing the render box, and position:relative changes the position of the render box without changing the position of the flow box... and position:absolute deletes the flow box.

You can see this in action in a lot of your content first CSS column models:

We start with the content which in all of these models has a 100% width float left outer wrapper. An inner wrapper is then used to move the content out of where we will be placing our columns.

#content {
	width:100%;
	float:left;
}

#content .wrapper {
	margin:0 200px;
}

<div id="content"><div class="wrapper">
<p>Some test content</p>
</div></div>

Code (markup):

Floats inherently stack, not going to a 'new line' below another float unless there's not enough room for their entire flow box. Since it's 100% width there's no room for columns, as there's 0px remaining - therin lies the trick.

If you set your right side column to 200px wide, then set it's left-margin to a negative 200px you have reduced the 'flow box' to 0px wide without changing the render box - the render box now being tied to the flow box by it's right edge. 0px? That's how much space is free next to our #content! AHA, that will fit and therin it will stack, despite it's 'render box' still being the full 200px wide! So up it slides into place when we apply the float, the render box still appearing it's full size right atop that outer container put around content.

#right_column {
	width:200px;
	float:left;
	margin-left:-200px;
}

<div id="right_column">
<p>Right column test content</p>
</div>

Code (markup):

For the opposite side column we use the same trick, but with the opposite margin. This puts our left column to the right of our content - not where we want it, but by adding position:relative and sliding it the full screen width (100%) to the left, the content ends up right where we want it... it's worth noting that while it's rendering where we want, it's 'flow box' is still over on the opposite side of the page. If you start playing with making the 'flow box' as I call it wider by using a smaller negative margin, you can see this in effect.

#left_column {
	width:200px;
	float:left;
	margin-right:-200px;
	position:relative;
	left:-100%;
}

<div id="left_column">
<p>left column test content</p>
</div>

Code (markup):

That is probably the most complex thing you are going to find in CSS, but if you think of it in terms of render box and flow box, it's fairly easy to do.

The same way of thinking about it can be seen in most of your 100% height model pages. A quirk of the specification is that any element that has a height declared in % has that declaration changed to 'auto' if the container around it has no height declared.

For example, if you have no height declared on html, declaring a % height on body SHOULD be ignored. If you have no explicit height declared on body, a % height on any tags inside body should be ignored.

Complicating matters further, IE6/earlier has no min-height, so if you declare everything as min-height it's not going to work cross browser.

Because of this, a 100% min-height layout has to use some... tricks to function properly. Thankfully some other details in the specification work to our advantage.

First among those is the default behavior of body is overflow:auto. Because of that, it 'appears' to us that height:100% on body acts as min-height... as such we can just declare:

html,body { height:100%; }

(oh, I'd null all margins and padding first via the universal selector)

then we just need a container set to min-height:100%;

#container { min-height:100%; }

but IE6/earlier doesn't have min-height - BUT it does treat height as min-height, so we can just use the * html hack to target those browsers.

* html #container { height:100%; }

So what does this have to do with the flow box? Well, how do we position the footer at the bottom of #container without absolute positioning (which doesn't work if the content is longer than the page)?

We put the footer AFTER we close #container, then set it's top margin equal to negative it's height. If we add position:relative we trip a flow order quirk that makes certain our footer appears over #container.

#footer { height:64px; position:relative; margin-top:-64px; }

That makes the footer's render box 0px tall, at the very bottom of the render box - placing the render box over #container. Simple. You then just need to make sure that whatever content is inside #container has it's bottom padded the same as the height of #footer.

Again, pretty much just using a reduction in size of the flow box without touching the render box. There are a handful of other things like if you wrap it all in a container, that container needs to be position:relative so that 100% returns the container width for #left_column instead of screen width - but for the most part that's all that's involved.

Which touches upon one of the most common problems you see - people using position:relative and not realizing that it moves the render box, not the flow - leading to them putting position:relative and some 'top' amount over and over again - then wondering why their layout is broken cross browser... or using position:absolute for everything and then wondering why there are no scrollbars when the screen is too small. (no flow = no scroll)

Mind you, the terms 'flow box' and 'render box' are my own way of thinking about it - in no way tied to any official CSS spec... It's just how I think of it when setting up layouts.

I do think it's kind of stupid that I had to come up with my own way of thinking about it before I was able to understand what the specifications were prattling on about - but if it's stupid and it works - it's not that stupid. A lot of people try to overcomplicate the box model by breaking it down into more and more subgroups - or making wild claims about 'there are 21 different box models' or some such bullshit. I take the opposite approach, break it into just two boxes per element that appear to be all you need to work with - and be done with it.

 

I got about as far as the three layers being a render box and the margin being a flow box. The example confused me, though. I figured I should just try it, because I usually have to see an example to get it.

First I did the 100% width #content and the inner #wrapper with Some Content. I put red borders around so I could at least see where the render part was.

I got a red lined box that stretched from left to right and then another box sitting inside it in the middle (200px from each side, right?) with content inside it, aligned left. That seemed okay.

Then I added the right and left columns and the right was off the screen-- I could see a bit of one side (the border only) sticking out from the left side of my screen. Reducing the -200 margin brought it under the Some Content (#wrapper), and between the outer box edge (#content) and the Some Content box edge-- like two reds on a checkerboard. Left was nowhere to be found, until I remove the -100% (or, I can leave the -100% and add the red border after it-- I see no red border for left_column, but I see text right next to the right_column).

This was with moving the html for left and right to within both the #content and #wrapper divs.

This is why I'm skipping the first like 7 chapters of Html Utopia and trying to just get the positioning right, because it seems like it makes sense when I see other sites' css, but then when I do it I get "The Short Bus kids have been playing with legos again."

 

Don't use borders, Stomme. They will affect the flow since they add to the overall dimensions of the container. I suggest you use background colors instead.

 

Thanks for the tip. I can see that the right column is 200 px and sits at the far left of the #content div. The left column is nowhere until I lower the left:-100% down to like -20% (where it pretty much sits on top of the right column) and at 0% it sits next to the right column. Was the left supposed to bump the right further to the right?
How come I don't float:right the right column?

 

It's some complicated CSS at work. You're taking an element that is below the content and forcing it to appear to "ride up" alongside it. However, the reality is it's sitting on top of the content column, which is why the wrapper (which really contains the content) has the margin applied, so the right column sits alongside THAT.

If you were to use float: right, all you'd do is float it to the right, but at its current location.

 

Because float:right can introduce the opposing float margin error in IE. Float:left stacks it, so we're ok.

I wrote up a working example to show it in action and explain it - Work in progress I still need to clean it up more (switch it to full fluid layout, add more explanations, etc, etc).

http://battletech.hopto.org/html_tutorials/3coldiv/template.html

The directory is unlocked:
http://battletech.hopto.org/html_tutorials/3coldiv

To show all the nice little bits.

Maybe that will clear up what I mean?

 

It cleared up a lot, esp. after I realised I wasn't supposed to have the columns also under the #content div.
After every thing was introduced, I played with the margins to figure out what was going on. Why does it matter which direction you remove the margins from? Is it like, if you remove them from the left, you're now moving the column box from its right side? Because I could keep the right column under the #content/wrappers div with just one pixel margin (margin-left: -149px).
I tried to get the same results taking the left column and also removing the margin from the left, and then making the position-relative left: -70.6%... this seemed to mean that it mattered from which direction you removed margin, as if this determined which side of the column the movement was based on... ?

I'm going through those other columns after lunch.

 

You probably had some padding or a border applied to the element. Remember that the box model is additive, not subtractive (as is the case in IE 5 and 5.5, or IE 6 in quirks mode).

When you set a left margin, you're pushing the element to the right. However, when you set a left negative margin, you're actually pushing the element to the left.

 

Well, that's not ENTIRELY true - which is why I think a distinction of 'flow box' is necessary.

You are pushing the flow box narrower towards the right - meaning the rendered content hangs out over the flow box to the left. This can have the appearance of pushing the element left, though in fact the element itself has not moved - just it's flow is being handled different.