I'm not sure why this is not working, but when this site is viewed on 1024x768 resolution you'll notice the brown area does not start at the very bottom anymore and leaves a little gap, and i'm not sure how to remove it, please help! www.tdd-designs.com/cream/home.html thanks.
Well, being that I think the entire layout is broken on large font/120dpi setups, I'd say you might have bigger problems than that... but that begs the question just how uselessly tiny DID you make the text in that center area (loads it in FF which ignores the system metric) - so tiny I'd have to zoom in 200% to approach usable on my setup... In either case your text is running right past the bottom of the container. Here's a tip, fixed height + dynamic fonts = /FAIL/ hard. Your content area should probably be dynamic height, even if that means resorting to a table to get that area centered. Otherwise it's just going to break, and keep breaking. In general though, there's a reason you don't see websites laid out like this... they tend to break badly the moment you change the resolution.
Agreed - just not practical within the limitations of HTML - at least, not without resorting to at least ONE table given what a total RETARD CSS is when it comes to vertical positioning.
well, i'd really like to get this layout up and running properly, so if it means using one table *shudders* i guess i'll make that sacrafice. but any clue on how to fix the problem at the bottom first?
Well, I'm not seeing any 'problem at the bottom' in any browser here, what I am seeing is problems at the side as scroll bars are added/removed at lower resolutions, content not stretching to the full scroll region (making that sideways scroll fairly useless), and content pushing out past the container. Compared to that, I see nothing wrong at the bottom of the page. Sorry. Hang on, lemme see what I can come up with for code to implement this - it is a VERY unique layout, would require some not so normal positioning tricks to pull it off... One thing I see right away is that menu needs MAJOR changes, since images for menu as transparancy is a total /FAIL/ on accessability. (since you can't do image-replacement on them). Page title has similar issues, though some background tricks MIGHT be able to turn both into something functional. As layouts go, it rings of "Hey look I know how to use photoshop - but not the first thing about HTML/CSS" - and therin lies the problem. There's a reason I still say start with semantic markup, THEN design the layout in CSS, and only THEN do you hang the graphics on it - starting in the graphics program is just completely back-assward to me. Silly question, but is any browser rendering this as you want it to appear? I'm looking at four different appearances in four different browsers here...
it's rendered fine in IE 7, FF and Opera 9 on my computer at 1024x768 (except for the extra cream bit at the bottom) and 1280x1024, and renders fine on my mother's computer in IE7 at 1024x768, also checked it on a few other people's computers and has rendered fine in 1440width by i forget the height, and another crazy resolution... so i didn't think there was any problems.
probably 900 or 960 - fairly common widescreen LCD size. I run 1600x1200 - but I do so with 'large fonts/120dpi' turned on in windows or 100dpi set in linux - so all %/em/pt fonts by default are 25% larger on my setup at default size. About 15-25% of windows users use the setting, and not planning for allowing it defeats one of the major points of HTML, fonts scaling by default. I was surprised as I started going through the files that the menu is SUPPOSED to look like that, with the bottoms of each word chopped off - I thought that was a rendering bug... I do imagine those little blue pixels sticking down though ARE a mistake. Either way, I'd probably axe the images being that text is so close to times new roman, one really needs to say 'close enough'. Likewise I'd axe the alpha .pngs as much as possible, though the content area would likely need them if we convert to dynamic height... Either that or I'd say **** the transparancy and just go with a flat color or uniform shading there. Alpha transparancy .png is generally wasteful, unneccessary and just plain impractical for web designs. If you precomposite your alpha, do some simple positioning tricks, you can usually pull off the same effects. This is how I'd approach that layout: 100% height model with the 'position fixed' emulation code simplifies any scrollbar problems - so that's height:100% overflow:hidden on the html and body, height:100% overflow:auto on a #container around the entire page. fixed absolute positioned height:50% element to render the 'top' background. This has the drawback that at lower resolutions (anything below about 740px) it will not render in the correct place, but at least the content is still accessable at 800x600 (something your version doesn't manage) H1 header, image replacement over the h1 text, negative margin-bottom to effectively remove it from having an effect on flow WITHOUT messing with absolute positioning. Table so we can actually vertically center dynamic height content - left TD gets a single border center right, right td gets the opposite. I rendered the images down and recaptured them as palettized .png to save bandwidth and avoid the whole 'IE doesn't support alpha .png' problem. Because the columns are not fixed width they'll auto-chop off their backgrounds at lower resolutions without forcing scrollbars. The center column handles our vertical centering with ease cross browser, so we just stack the menu atop the rounded border top, atop the content area atop the rounded border bottom. I would probably axe the background transparancy on this and just use your desired colors - the light on the top border placeholder, the dark on the bottom one, and then have 1px wide repeat-y stripe for the middle. Due to your design not lining up top-to bottom 100% centered, we'd have to pad the bottom of that image equal to double the offset, PLUS the height of our menu. A negative margin on the bottom of the menu and position:relative on that top border will slide the content area up over the menu, replicating that 'chopped off' effect you had. There's a 19px offset from how you were rendering and 'exact center', so we slide the backgroundTop div up 19px... Which all put together looks something like this: http://battletech.hopto.org/for_others/tdd-designs/template.html As always, the directory: http://battletech.hopto.org/for_others/tdd-designs is unlocked so you can grab the gooey bits. I remastered all the images to NOT rely on alpha transparancy, so no worries of it choking on IE6. Because of the glider-levin style image replacement the header CANNOT be transparencies, so I did a render over the centered background tile, then screencapped and cropped it at 384px wide. I also performed a gamma correction on the bottom half background as it's pattern was below the 5% visibility threshold. (Overall luminance was maintained in the process) The layout has an additional bonus with this approach, turning images off you still have a completely functional page. The use of image reduction, palette reduction and a host of other optimizations nets us something even more important - total filesize reduction and a reduction in the number of files. Your original was 259k in 19 files, my rewrite is 97k in 10 files. In file reductions alone that's 2 seconds off broadband and up to 10 seconds off dialup before we even TALK filesizes. Though the big bonus is the content area is now a proper dynamic height, allowing us to use fonts that adjust to the system metric. Hope this helps.
wow! thanks a million for that, I have definately learnt alot, I certainly didn't expect you to do this for me, let alone on christmas! thanks again!