Happens to all of us at the start – it’s very easy to get ahead of yourself with ‘copypasta’ when often you have to bang the breaks, and take the time to understand things one at a time from the top down.
“sandBag” is the generic term for an empty tag used for presentational purposes – typically a DIV or SPAN since they have no semantic meaning; or more specifically do not semantically change the meaning of their content. In the CSS I use a ‘negative bottom margin’ equal to it’s height, to ‘ride up’ the pageWrapper over it… this gives you the horizontal stripe across the top… inside pageWrapper this is erased by the full height white background, which is why I repeat it again on the h1. The H1 also uses a ‘negative margin’ to make the menu ride up over it. This is often easier than adding extra wrapping DIV to the markup and dealing with floats.
Sticky footers come in two types – fixed and min-height. This is a min-height one, it means if the screen is taller than the content, the footer stays at the bottom instead of riding up. a “fixed” sticky footer would stay on the screen even when the content is too tall. I dislike that type because it can often make users not realize the content continues past the footer. The “inverse of your header” just means I used the same background image, I just flipped it upside-down.
header:
http://www.cutcodedown.com/for_others/unconformed/images/headerBackground.png
footer is ‘inversed’ – flipped vertically:
http://www.cutcodedown.com/for_others/unconformed/images/footerBackground.png
It often helps to tie layouts together by doing things like that.
Pull #footerWrapper and everything inside it, likewise pull all references to #footer and #footerWrapper from the CSS… should do the trick.
As I’ve said probably a dozen times on these forums, Adobe wouldn’t know an optimized image file from the hole in it’s DVD… I generally use OptiPNG or the save-time optimizer in Paint Shop Pro for my PNG’s, and php’s GD module for JPEGS as they seem to do the best.
But the tool used to save the file is just a fraction of the equation – it also helps to understand what image type works best for each type of data.
Photographs for example are best in JPEG – the detail of the image hides the ‘artifacting’ caused by JPEG’s being “lossy” – lossy means that every time you save you ‘lose’ a bit of data in exchange for compression. The simpler the image and the larger the areas of the same color, the more noticeable JPEG ‘artifacts’ can get – likewise higher compression means more artifcacts – which is why JPEG is poorly suited to line-art and simple graphics; like your background pink stripes, your background gradient, etc.
PNG’s are better for line-art, and massively bloated for photographs; and they’re a bit more complex because they come in five major types –
-
24 bit without transparency – fat, bloated, slow, but NO LOSS. These are best used for “master” images that you work on and edit before saving to another format (like JPEG for photos)
-
24 bit with 8 bit alpha channel (32 bit) – everything wrong with 24 bit, featuring 33% more bloat. Your die-hard artsy fartsy types SWEAR by them, web developers who have the slightest clue what they are doing have been cursing them since they were introduced! They are RARELY necessary for the effects they are used for, and generally result in files significantly larger than need be. Legacy IE needs javascript assistance and/or special use of the proprietary ‘filter’ property to use them… so I just don’t bother. IF I do need those effects, I do what’s called “precompositing” to put them together – I make the transparency I want, show it over the background I’m using, then screencap the final version and crop it to fit.
Which is what I did with your logo:
http://www.cutcodedown.com/for_others/unconformed/images/h1Logo.png
Saving it as:
- 8 bit palettized PNG - forces each ‘pixel’ to be 1 byte in size. No transparency, but is automatically a quarter the size of it’s 24/32 bit counterparts. Because each pixel is stored as 8 bytes, you can only have 256 distinct colors in your image. For line-art or monochromatic images this is rarely an issue since even 32 bit images are typically 8 bits each of red, green and blue… if as color each piece of the spectrum is only 8 bits wide, the fraction used for a monochrome image easily fits into 8 bits or less. The ‘pink on white’ background is monochromatic, so PNG’s 8 bit palette easily gets the job done… in fact, ALL of the images I redid for it are saved in this format.
But there’s also:
- 8 bit palettized PNG with palette transparency - a single color is chosen to be transparent… 100% transparent… you either have see-through, or you don’t. A lot of the PSD jockeys hate this format because anti-aliasing is a bit trickier… but there’s a method called “close enough anti-aliasing” where you pre-composite over a solid color that’s roughly equal to the ‘nearest sum’ of background color (100% gaussian blur often works good for this), then use that background color (or floodfill with a unused color like magenta) as the 100% transparent part. The anti-aliasing pixels around the edge will usually blend into the background ‘close enough’.
An example of ‘close enough AA’ can be seen on my ewiusb site, where the buttons and bottom of the EWI:
http://www.ewiusb.com/theme/images/h1TopButtons.png
http://www.ewiusb.com/theme/images/mainMenuBackground.png
Have the handful of darker pixels around the edges, but on the page you don’t notice them. Sneaky trick, and it works 90%+ of the time while giving you a smaller overall image.
The final ‘major’ type is
- 4 bit palettized PNG - this too can have palette transparency, or you can use all 16 colors. 4 bits == 0…15, hence the 16 colors you can use with it. Best reserved for line-art, this results in a very small file in most cases…
Then there’s GIF. GIF can do 4 or 8 bit, with palettized transparency just like PNG… No option for alpha, but it can also do animations… GIF is a very old format that doesn’t compress things very well unless the total “raw” byte count is less than 32k… so for example 256x128 in 256 color (8 bit) or 256x256 in 16 color (4 bit). At those sizes or smaller GIF often gives you a smaller file than PNG – BUT, at sizes larger than that PNG typically wins. This makes sense since when GIF was invented most computers couldn’t handle more than 64k as a single variable. (and on many systems significantly less than that).
Worst of all – automated tools and ‘trusting’ your paint program to handle it itself (much like when it comes to HTML and CSS with “WYSIWYGS” or even many normal editors) just doesn’t work well. You have to take the above as a loose guide, try a few different programs and different formats, until you find one that works ‘best’ for each image… or at least ‘better’ than the default…
… and again, Adobe’s “save for web” has been, in my experience at least, totally useless rubbish in that regard – but to keep it in perspective I say the same thing about Photoshop and most other Adobe tools so far as web design is concerned… To paraphrase a dearly departed friend: “The only thing you can learn from Adobe is how NOT to build a website!”
– the max-width is pretty close to the min-width on small font/96dpi machines, but for large font/120dpi users it opens it up a bit more – likewise the content text was swapped to %/em instead of px so it’s not useless on the accessibility front. “font-size: 14px;” on BODY is basically completely defeating the entire point of using %/em elsewhere on the page – since EVERYTHING else inherits from that. PX for fonts should be reserved for the handful of spots where you ‘have to’ – like in a sticky footer (less important content anyways) where the height has to be fixed, or on menu buttons to control how they fit… for the content area? BAD design choice all-around.