I just started playing with tableless CSS, and I've gotten pretty far along. But one thing seems to be stumping me. I'll start with how I'm going about the design from start to finish (not there yet). Any tips, comments and/or tricks would be appreciated. I do a mock up of the page design in adobe photoshop, I then slice it and export the images. I create a basic HTML page using textpad and put in all the divs I require with some sample data. I create a blank CSS file and pop it into TopStyle. I then open the HTML page I created into the preview option of TopStyle, and start creating the CSS portions. This new design is for Drupal. So I've upload the style sheet and began integrating the design into Drupals template system. I have since changed the design slightly, and removed a couple of divs and changed some images. The following is the original design: http://www.modvb.com/test As you can see, the background images on the columns repeat to the bottom of the page. And the footer is not even finished. However, since I removed the div in between the grey bar at the top and the two columns. Which is (#belownavbar) which was just a shadow. I can't get the backgrounds on the columns to span fully. I also added a grey bar as the footer, which looks funny in Internet Explorer because the columns overlap the footer. I'm a major newb with this stuff, and I've tried to stick to good coding from what I've found on the web. I've also tried my best to solve this issue, and now am asking for some help. Any feedback as well would be great. Thanks.
Being I don't even see more than one column, I take it you are making changes? One thing to remember is there is no way to make multiple floating DIV's stretch to the same height - you have to 'fake' the appearance of that. (so called faux columns) which is VERY difficult in a fluid layout (but not impossible) I would use the position:fixed 'emulation trick' to place your sidebar backgrounds, then position the header over them to 'hide' it. Gets around the fact that cross browser height:100% and/or min-height:100% has problems when nested. A suggestion while at it - you are in the development stage, some tabs for proper indenting would go a long way towards making the code not just easier to read, but easier to maintain and develop. If I have time after work I'll toss together an example for you.
The test template has 3 columns, just no text within them. I added text. I'm not even floating the column's, I'm just doing #leftblock { left:0px;} and vice versa for the right. I saw tutorials on 3 columns with float, but most of them weren't fluid, they all used % values. I noticed this as well. Yes, The drupal template has tabs since I'm playing with it on the web server and using the "joe". Yes, if you could that would be great. However I think I know what I need to do now and might be able to find an example online. I'll look around, and post if I've found the answer. Thanks!
I just noticed that - and that's 99% of your problem right there. Absolute positioning of columns is a guaranteed way to a broken layout - AND to run the risk of the page not having the needed scrollbars. Hang on, I'm starting my 'rewrite' now.
Here's how I'd approach that layout: http://battletech.hopto.org/for_others/comm/template.html The directory is unlocked: http://battletech.hopto.org/for_others/comm/ so you can grab the meat and two bits. I remastered the images while at it so the page only used four images totalling about half the size. The background is done using a variation on 'sliding doors' with palette transparancy. I used my stock 100% height model code, so I tossed on a footer - the footer requires that it be a fixed height, but it's a really nice effect.
Thanks a lot man, you've provided more than I expected. I do have a lot of questions, but I'm still looking over the template. How'd you use the one image? I see how the logo.png was changed, but don't really understand it.
Well the logo is the example of CSS "sliding doors" in which the background position is just changed for each section. For example, background-position:center would center show the center of the image as background - which is your actual logo. Therefore background-position:bottom would show the bottom of the image, which is the gears. I am somewhat familiar with deatshadows coding style, and would say that instead of using background-position: he would just use background: and through all the values in there. Deathshadow introduced me to sliding doors a few weeks back, and since then I have become much, much better at CSS, so read through his CSS carefully and learn what you can. BP
So you're just selecting a specific portion of the image, and the repeat-x kicks in the background. Neat. Honestly, this is really cool. Thank you for taking the time to look at my code, and thank you for the explanations. I'm going to have to make even more templates so I can get this stuff down pact.
For a better example of how far you can push background positioning, have a look at my 'eight corners under one roof' technique. http://battletech.hopto.org/html_tutorials/eightcorners/template.html One can even apply the same technique via javascript: http://battletech.hopto.org/html_tutorials/borderimages_javascripted/template.html There are a LOT of advantages to using a single image instead of multiples for layout items. The biggest comes from less 'handshaking' with the server which in a lot of cases can take more time than the actual data transfer. Ever notice how uploading via FTP ten 1k images takes longer to upload than a single 20k image? Same problem exists in HTML. The less files in a page, the faster it loads - AND the better it appears to render to the end user since instead of watching images render 1...2...3...4, they all appear at once. It's possible to make a 60k page that takes almost a minute to load on broadband just because of all the separate files - while at the same time you can make a 150k page that loads in half that on dialup just because you only have eight or nine files total. This is a major aspect of web design that is rarely discussed or taught and has it's roots in how HTTP works. (though HTTP is NOT as bad as FTP on this subject) A second advantage is that since things like borders and buttons tend to all use the same colors, you only have to save the palette once - eight files all with a 256 color palette end up needing 768 bytes per file overhead for the palette - if you can share that palette you just saved yourself 5.3k. (this is also why occasionally 16-64 color .png's that have already had their color dropped to that level will save even smaller with a truecolor palette.) This is part of why I can charge over a Benny per page, and how I can usually quote 30-70% bandwidth reductions when optimizing other people's pages.
My husband has said to me several times that the file transfer time (he only says "handshaking" to refer to modems-to-ISP) depends a lot on the connecting-persons' ISP's server set-up. As he's not really great at explaining things, I didn't ask him further. Is there a site or a book where all this is explained further-- directed maybe towards web-builders? 10kb is 10kb-- so how is it sometimes not? I've also noticed that on my copies of your sliding examples, every browser does what it should except IE6 (both fake for linux and Tredosoft) where it seems to always lag showing the new image position. Any ideas why? I haven't been able to check with a "native" IE6.
Then he needs to learn a little more about TCP/IP. Suggested reading: http://www.faqs.org/rfcs/rfc793.html Partially correct... HANDSHAKING (which does occur for every HTTP connection via TCP/IP) time depends greatly on every server and point between you and the target server. Ever hear of 'ping time' - ping a server, just pick one. See that average time? On a good day 30ms on a bad day 500ms? That is the time it takes for a message to go between you and that server. When your browser requests a file, first it has to say "Hey, I want this file from you" - if it's in the cache added to that message is "I have this version from this date" - the server then checks to see if the file exists... returning the appropriate code - 404 for file not found, 304 if it's unchanged, etc, etc... as per: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html If it's not in the cache and the file exists, in an ideal world you should get a 200 code - 'OK'. Once you recieve the OK you then have to send it ANOTHER 'fine, send me the file.' - only THEN does data transfer actually start... That's three pings whenever someone accesses a new file. Even if you get a 304 - file unchanged so it's in your cache, if you are accessing a new page on the same site that uses those same files (like say... images) the browser WILL check for changes, meaning you have at LEAST two 'ping times' before the files will load. Thankfully browsers do not check their cache on forward/back - but they WILL usually check at whatever interval the browser makers said to check. (see in Opera where it says "check documents" and "check files" under preferences > advanced > history, in FF under about:config / browser.cache.check_doc_frequency - no clue where those settings are in IE or Safari) ... and those are best case scenarios. You get a 100 code - 'continue' you have to sit there and wait for the server to send you another message. You get a 307 (like because of a .htaccess redirect) you are looking at doubling the number of handshakes because the file is at ANOTHER location. You get a 504 (gateway timeout), 408 (request timeout) or worse a 502 (bad gateway - which could be just one server between point A and B screwing up) you get into 'retry' territory - which can create even more server load bogging down the server without even actually moving DATA. The bridges, switches, routers and servers between you and the target server can also effect the speed of downloads - if the only route between A and B is through a switch that only has 64mbps free, you're only going to recieve data at 64mbps even if you have 3gbps downstream and the target server has a 100gbps upstream... but that is unrelated to the handshake EVERY tcp/ip connection has to do. HTTP 1.1 alleviates the handshaking slightly by way of introducing 'persistant connections', but overused that can in fact create MORE overhead than just letting requests run normal. Inside your usual server each request gets it's own process - a persistant connection leaves that same process open for more requests from the same user - often unneccessarily, which is why 'persistant connections' is ALWAYS a craps shoot. (I've rarely ever had it help, and I've had it hurt a LOT of high-traffic low memory servers) ping time is less of an issue once data starts to be sent, because it is sent as multiple packets as a non-stop stream... Again, this is why FTP (which has much larger handshaking due to all communications being sent as verbose plaintext) it is really noticable how ten 1k files can take three or four times longer to transfer than a single 20k file... it's half the total filesize, but the single big file uploads faster. As it relates to web designers there's very little in the way of books or sites that explain it well, if at all. Kind of wierd since it's an underlying cause of bandwidth hogging without CPU use that can leave many web managers scratching their head. I've never seen what you describe - the technique in question SHOULD (and in my experience on real IE) render faster because it's not swapping an actual image, it's just using something that should be decoded in memory already - *** MIND YOU ***, Wine sucks donkey when it comes to memory handling, so that could be a likely cause for the slowdown.. Another possible cause is just IE6 - IE6 is notoriously slow at dom manipulation of visible elements. IE 5.5 and IE7 BOTH kick it's ass in that department. But then, if you don't have access to REAL IE you are probably developing in the wrong OS environment. Freetype is NOT cleartype - hell, I'd rate it not even as well done as windows 3.1's font renderer when it comes to kerning, (ok, it renders fonts like an epileptic) If I was stuck in a non-windows environment for development I'd install XP under vmWare (or Parallels) and check FOR REAL. (it's what I do with testing linux - I run Ubuntu under vmWare under XP x64)