I would like opinions on my code

I have been doing CSS based sites for about 2 years now. I have progressed immensely in that time. However, I know enough about CSS to know that there is a lot more that I need to learn.

I would like to get some opinions from all of you more experienced coders on my latest site.

www.pool-zone.com

I would like opinions on:

1-Code simplicity, and structure. Let me know if I am doing good, and what can be done better.
2-Page size. I want to make the page size as lean as possible.
3-Better CSS practices, including compatibility with multiple browsers.
4-Anything else that will make this site an easier venture.

Upper management is pretty happy with the visual design, so I won't be able to make many changes to that, but I would like an opinion if you have one. We are in the very beginning stages, and I want to have it set up so that I won't have too many headaches when we start adding products, and other pages.

Thanks in advance.

 

A quick point of note, why have you given header content and footer a left margin? Give your wrapper padding-left attribute and save some code.

 

Great Point. It is now fixed. Thank you for pointing that out to me.

 

Well, it feels a little DIV and class heavy, and you've still got presentational images in your markup making it look kind of silly when CSS is off... Sliding Doors would go a long ways towards simplifying your HTML , and it also has the problem of being a confusing jumble when browsing without images (likely also meaning it ranks poorly on search engines) - Remember, never use images for navigation or headers without REAL text available (alt text doesn't cut it - not even close)

You've got 370k of images doing the job of easily a third or less that, you are declaring px sized fonts for content areas which means it doesn't resize for 'large font' users... you are declaring sizes under 12px which are usually a usability /FAIL/, have multiple redundant CSS properties, are declaring widths on elements that shouldn't need widths declared, declaring width:100% in combination with margins which likely means you spent a LOT of time trying to figure out why the layout kept breaking in IE (hence the need for that silly IE conditional in the HTML) and it appears you don't use headers properly either (the first header on the page is a H3?!?)

Still, you at least have proper and consistant formatting and indenting, I've seen a LOT worse code lately.

 

Thanks DeathShadow. This is the exact kind of information that I was looking for. I have a few of questions though.

1-Do you have a tool that you use to give you the size of a page (including html, images, JavaScript, etc.)?
2-Are there any resources (links, etc.) or pointers where I can learn more about how to best cut down my 370k of images?

I spent WAY too much time trying to figure that one out!

Thank you for this info!

 

The Firefox web developer toolbar includes a handy routine for this - just install it and under "information" there's "document size" about two-thirds of the way down the menu.

The BEST tool I've found for this is Corel (formerly JASC) Paint Shop Pro... during the 'save as' dialog there is a 'options' button - in there you can at SAVE TIME do color depth reduction, choose the amount of dithering to use, set transparancy, and a whole host of other optimizations. The icing on the cake is a image preview of your choices so you know how much your choices are degrading the image BEFORE you save anything.

The rest is my own experience, I've rarely seen any good threads or articles on the subject - sometimes it seems like a taboo subject, other times I think it's just people with their heads in the sand over Photoshops shortcomings. (Photoshop is a fine tool - just don't ask it to save images in an efficient manner)

A good rule of thumb is the following:

Images that can be safely reduced to 16px that are less than 1024 pixels total - Save as .gif - images that can be reduced this low often include monochromatic borders - like the blue and orange borders on your page. Usually if it's a single hue and a repeating pattern, you can easily get away with 16 colors and STILL get some anti-aliasing in there.

Images that run 17-256 colors to still look good are best done as .png - though if you need to make certain the colors match CSS/HTML declared colors, png is NOT going to work as IE applies gamma 'correction' to .png (for no good reason anyone has ever been able to explain apart from malice towards the .png image type). MOST of the time .png is my weapon of choice, though sometimes .gif works too.

Truecolor images - .jpg is most always your best choice, though .png can often give smaller file sizes on small images. Sometimes 256 color or less images save smaller in truecolor .png than they would palettized - you have to experiment as quite litereally this is a case by case situation.

On .jpg encoding the LEAST encoding you should use is 5% loss, which can take a 512 meg lossless .jpg and turn it into 50k. You should test even higher loss rates - contrary to how most people word it, the % setting for .jpegs is NOT directly how much compression will occur, but how much data loss is 'acceptable'. Some images can be cranked all the way up to 80% data loss and you'd never notice (some low color count thumbnails for example) while other images look like crap at as little as 25% loss. WHEN IN DOUBT I suggest 15% loss - it seems the perfect compromise between filesize and quality.

Pretty much though, you have to take each image on a case by case basis as with the endless variations of color, there is no single file format, color tricks, etc to make sure you always get the smallest file.

ON TOP of making the files themselves small, you want to reduce the number of files used on a page. Each extra file is a extra 'handshake' to the server - if you are sitting on the same LAN as your server that handshake might only take 20ms - if you are on dialup it could take a second or more. 'Real world' figures put the average handshake around 200-300ms - this means three images is almost a second of download time - 52 images 'real world' can be 10 seconds or more time wasted that can in many cases be avoided.

"Sliding Doors" is a great example of a 'image recombination' technique - you render your top border at the theoretical widest width it would ever need to be (I usually use 3072px or 4096px) and apply it as a background to your header. One side (depending on how you align the image) will get chopped off, then inside the header you place another element that will be the width and height of your missing corner, put it in that corner - and boom, you've got your header using only one image instead of three... repeat for the footer, and you could COMBINE the footer into the same image. Using some tricks you can even fit the sides on that same image, meaning a single file instead of the eight or nine more conventional techniques would use.

Single image can also exploit how palettized images work - images that have a palette have to store that color palette in their file, 9 files means 9 palettes, one file means only one shaving a k or more off your total. (It's actually the inclusion of the color palette that can make 256 color .pngs often larger than truecolor ones!)

Hang on, I'll work up a quick example of that using your blue border to show you how that works.

 

Here's an example:
http://battletech.hopto.org/for_others/chaosfoo/template.html

All three of those boxes are formed using a single 3078x20 .png - said png file being optimized at 32 color depth, no transparancy, for a miniscule 449 bytes - smaller than any one of the images you used on your page. (testing showed it was actually smaller as a 32 color .png than it was as a 16 color .gif). The only difference in the CSS on them is the width declaration.

said image:
http://battletech.hopto.org/for_others/chaosfoo/images/blueborders.png

Needs some explaining. The 'sides' of the blue boxes need to tile on the y-axis via repeat-y. To do this we need to put them on the outer edges of our combined file - so the outer 3px on each side is our 'tiling' pattern... between those at 3,072px wide I've placed the top image over the bottom image.

.boxTop and .boxBottom are both much the same thing, they show the right corner and most of our image... the div inside them is floated to the right, set to the same height, set wide enough to show our missing corner - as the width expands and contracts the excess border is hidden - hence the term 'sliding doors' (REALLY good analogy). I call using sliding doors twice off one image like this WITH positioning tricks 'eight corners under one roof' (for the coordinator!!!)

This little tutorial I wrote a while back covers the basics of how this works, and shows other ways of using the same technique for a host of other effects like drop shadows.
http://battletech.hopto.org/html_tutorials/eightcorners/template.html

Even when it is more code than other approaches (rare), it usually ends up faster because you aren't handshaking for the extra files, can make better use of compression to make the combined file smaller than the individual files, etc, etc.

Hope this helps.

 

Thanks for all of this information! This is stuff I have never really considered, but I can clearly see the benefits. I really didn't know that that much time could be wasted on additional handshakes to the server. I'll definitely be cleaning up the code on my site.

Thanks for the awesome advice and example!

 

perhaps a check at http://validator.w3.org ? I see one error popped up

 

Other than a missing charset meta tag, his page would validate, but that's NOT what he asked.

 

I'll get the Charset added to make it completely validate. Thanks for the heads up.

 

Thanks for all your input and advice. I have redesigned the site (it still looks about the same), but the code is a lot simpler, and the document size is about 1/2 of what it was. I'm sure it not up to par with what some of you can do, but it is a lot better than it was.

Check it out again and let me know what you think.

www.pool-zone.com

 

Im no expert, it looks good on my side. However, after reading everyone's input and advice, Im enjoying the fact to see different avenues in writing a stylesheet and now it has just encourage me to post up a topic for some expert opinions.

CHEERS

 

I couldnt help but to ask, how do you fix the errors? I have a similar problem please check this out link

Much help is appreciated

CHEERS

 

Aw, Buck, you can't fix those, unless you want to use the Flash Satay code.

All those errors are basically because the "embed" tag isn't a "valid" tag. It's propriatary, invented by I think Netscape way back when and used by Mozilla-family browsers. So, because the validator doesn't know what <embed> means, all the stuff inside it looks wrong. It's expecting to see "src" and "width" etc under a tag it's familiar with.

I've used the Satay method and it works okay, though adding the param="wm transparent" (I may be spelling that wrong because I'm trying to remember what exactly I used) was inconsistant amongst browsers. Opera behaved the worst, along with FF1.5, always adding the unwanted background. IE is just weird with Flash anyway, making an actual new window on top for it to sit on... can't really change that, just have to work around with it.

Hope this helps.

 

Hey thanks for that Stomme,

The Satay Method has helped alot, so I will give this one a try and see what the outcome is.

CHEERS