Forum Moderators: not2easy
#td1 {
background-position: right;
background-image: url('img/s_01.jpg');
background-repeat: no-repeat;
}
#td2 {
height: 313px;
width: 802px;
background-image: url('img/s_02.jpg');
}
#td3 {
background-position: left;
background-image: url('img/s_03.jpg');
background-repeat: no-repeat;
}
#td4 {
background-position: right;
background-image: url('img/s_04.jpg');
background-repeat: no-repeat;
background-position: top right;
}
#td5 {
background-color: #DEDACF;
height: 624px;
width: 802px;
background-image: url('img/s_05.jpg');
background-position: bottom;
background-repeat: no-repeat;
}
#td6 {
background-position: left;
background-image: url('img/s_06.jpg');
background-repeat: no-repeat;
background-position: top left;
}
<table cellpadding="0" cellspacing="0" width="100%">
<tr>
<td id="td1"> </td>
<td id="td2"> </td>
<td id="td3"> </td>
</tr>
<tr>
<td id="td4"> </td>
<td id="td5"> </td>
<td id="td6"> </td>
</tr>
</table>
The only key here is that background image is sliced for loading.
There is a fixed width of 800px so this is the smallest screen that can see the page With Out a horizontal scroller.
The beauty of this dreaded table layout is that the left and right columns are liquid and stretch out to the ends of the users screen while the center column is fixed. See the top left background image is positioned right and the top right is positioned left.
Think of a large picture of someone spreading their hands out (1200px wide). Break the picture into three parts. Their left hand their body and their right hand. Now a user with a screen of 800px will just see the body (centered) while a user with a screen of 1024px will see the body and some of the arms, and while a user with a larger screen will see everything. This is easy to do in css with one large image or even images cut horizontally but not vertically too. Using the table layout it is relatively easy and native.
The design for the site has a background image that totals over 1200px in width. Id like for this background image to stay centered in the back while content is over it. So for users with a screen less than 1200px they will not see the left and right sides of the background image. This is easy to do with a single image by using background-repeat: no-repeat; background-position: top;.
But the problem is Id like to slice the image up some. It seems to take too long for the 100kb background image to load. So right now I am trying to slice it into 3 images for just the header. The top left is 212px wide, the top center is 802px wide and the top right is 233. I am able to do this using tables with the following code. Is there a way to do this with CSS? Please help, I don't want to go backwards and use tables.
#td1 {
background-position: right;
background-image: url('img/s_01.jpg');
background-repeat: no-repeat;
}
#td3 {
background-position: left;
background-image: url('img/s_03.jpg');
background-repeat: no-repeat;
}
<table cellpadding="0" cellspacing="0" width="100%">
<tr>
<td id="td1"> </td>
<td style="height: 313px; width: 802px; background-image: url('img/s_02.jpg')">
</td>
<td id="td3"> </td>
</tr>
</table>
RIGHT NOW MY HTML & CSS CODE is as follows
<div id="header_wrap">
<div id="header_left"></div>
<div id="header_center"></div>
<div id="header_right"></div>
</div>
#header_left {
width: ;
float: left;
height: 313px;
background-image: url('img/s_01.jpg');
background-position: right;
background-repeat: no-repeat;
}
#header_center {
width: 802px;
height: 313px;
float: left;
background-image: url('img/s_02.jpg');
background-repeat: no-repeat;
background-position: top;
}
#header_right {
width: ;
float: right;
height: 313px;
background-image: url('img/s_03.jpg');
background-repeat: no-repeat;
background-position: left;
}
But the problem is Id like to slice the image up some. It seems to take too long for the 100kb background image to load.
Hmm. Unless are you still using HTTP/1.0 to serve your content, slicing up images will not give you any speed increase. Typically in HTTP/1.1 there are only 2 connections used in total to transfer images and the larger image is going to be faster than the slices. Trying to optimize the image for file size (e.g. by lowering the jpeg quality setting when generating it) is more likely to gain something than slicing.
In fact the trend is exactly the opposite of slicing: using CSS sprites: collect all small images in one big one.
You could do this with absolute positioning (you'll need to do something else but floating in order to get the content over it anyway.)
To center using absolute positioning: set left at 50% and apply a negative left margin of half the width.
To add something to the left of that: set right to 50% and apply negative right margin of half of the width of the centered element
To add something to the right of the centered element: set left to 50% and apple a positive left margin of half the width of the centered element.
Also, I have had clients specifically ask for the image to be broken up.
What Im pointing out here is that I think I have found something that can be easily done with tables and not so easily with css. Dont get me wrong, I am PRO CSS and do all my sites in css. In fact in this case I did the layout with both and am using the CSS one, even with the big image!
If anyone can archive this layout with css id love to see it
[webmasterworld.com...]
I also don't really understand your problem....
You'd like a page that displays a potentially wider-than-window background image without horizontal scroll bars?
can't you just do that with one plain div and background-position:center?
I guess the answer to all of this is ONLY due to the image slicing? I really don't think that's something people should do anymore. If you want the page to load at the same time, there are ways to get that to work, so that everything loads at once to the user. Obviously you also want to reduce the file size of the image if loading time is a problem.
[edited by: Xapti at 3:42 am (utc) on Nov. 14, 2008]
I also don't really understand your problem....
You'd like a page that displays a potentially wider-than-window background image without horizontal scroll bars?can't you just do that with one plain div and background-position:center?
Yes you can but thats not what Im asking. My whole point with this is that table layout can do this easily and css can not!
I dont see a real strong argument for leaving image slicing? Lets not avoid the question, can CSS do what tables are doing here? NO
Also, I have found another scenario where tables seem to have the upper hand. When you have a div with a fixed height and a background color or image. When the content grows taller than the height the background stops and doesnt grow. You can use min-height attribute but this is not supported in IE6. So you can use a table and set the td height and if it grows it carries that background with it!
CSS do what tables are doing here? NO
Hmm, actually it's easy to get it working IMHO, did you try what I suggested in 3784087 ?
But if you believe that you need image slices and tables, then by all means use them.
IE6 is an ancient browser it lacks all sorts of things, even Microsoft's very own sites start to work really bad with IE6 (I was just trying to download IE8beata2 using IE6 on a clone of a virtual machine and guess what: I can't click the link cause it's not even displaying here [microsoft.com].[it displays fine in firefox])
To fix the lack of support in IE6, there is an often easy solution: IE7.js . Or go for graceful degradation and give them a reason to finally allow the upgrade.
Again if you've set your mind on abusing tables, you're free to do so. I won't tell you not to use tables even if I will never do it again myself.
ie7 26.9%
ie6 20.2%
firefox 44%
to me 1 in 5 is quite a factor still for IE6. Win 2000 and before cannot use anything above IE6 and also all the non-genuine windows copies that cannot upgrade to IE7.
If it were not for IE6 lack of min-height attribute I would say there isn't much issue. But I think having a separate layout for IE6 isn't too far a stretch for a solution.
Also, if you do some research you will see that the css version we use is actually quite outdated and the new css3 will incorporate solutions that are mimics of tables! AS Kevin yank says things are coming full circle.
The problem is that tables have become so un popular and the cool kids have beaten them into the dirt. Those who are ahead of the curve can see some of the small areas where css lacks.
Can this be done with CSS and no TABLES?Yes
Which makes it difficult to understand the point you are trying to make.
But I think having a separate layout for IE6 isn't too far a stretch for a solution.Many people stopped browser sniffing and coding separate layouts for specific user agents years ago.
They were the same people who realised that the numbers of user agents make it impossible - or at least just plain silly - to code for every possibility. Hence the take-up on the option to move from layouts based on precise control of every pixel and write code that can be interpreted as designed by the majority of user agents, and will remain fully functional for the others.
Where support for ie6 is necessary, I'd suggest you borrow one part of that philosophy and deal with ie via conditional comments - not code a whole different layout.
with the big image there is a tendency that their eyes may start reading the text for that one or two seconds before that big image loads, then when the big image loads they notice and then look at your design. with the sliced images its as if they pause to do anything.Studies show that if users pause while a site is downloading, it's to look for the back button. Currently you've got between 3-5 seconds (depending on which study you favour) to engage or they reach for the back button anyway.
Users simply do not visit a site to admire the design (unless it is a design site). The whole point is to enagage them with enough content they don't leave before a bloated site design downloads.
The problem is that tables have become so un popular and the cool kids have beaten them into the dirt.Tables are extremely popular for marking up tabular data. The real issue is that despite having many years to change mind-set, a lot of coders haven't made the mental jump from "look at my whizzy design" to "can the user access the content from any user agent on any platform on any device".
Tables used by such coders - whose goal is to impose control for the benefit of their design - are characterised by also being routinely used to defeat the benefits of semantic mark-up, and/or usability and/or accessibility. But that's the coder - not the table. Around here beating coders isn't permitted. Even those who use tables in a way that deny users rights and cost businesses money are protected. Apparently. ;)
css behaviour that "mimics" tables isn't proof tables are better. As a 1/2 way step it might advantage users by encouraging coders to remove tables from the html because they can implement control over every single pixel via the css. I doubt it will be successful, but mimicking tables isn't evidence tables are better - it is evidence of a failure to understand the nature and purpose of the web.
Those who are ahead of the curve can see some of the small areas where css lacksI've supported css for years - and I think css lacks in a large number of areas. Take me to the place ahead of the curve!
AS Kevin yank says things are coming full circle.Nope, so far as I can tell its already happened regards design and code - it just got named "web-2" instead of "oh-so-1998".
alt131 can you show me a way to do this with css that works with ie6 since you seem to be on top of this..?
i think that browser sniffing for ie6 may still be valid, its no that hard to do and if it adds to the quality of the site than i think thats a good thing.
the site is about its content, but if it looks nice too than people enjoy its content more. its about the user experience, you dont want anything to annoy them or take away. most my sites have less than 300kb of image for the design. i just wanted to split that 300 up a bit.
alt131 can you show me a way to do this with css that works with ie6
i think that browser sniffing for ie6 may still be valid, its no that hard to do and if it adds to the quality of the site than i think thats a good thing.
I assume ie6 and deal with it by conditional comments. That avoids browsers incorrect identification, server delay (even if usually marginal), and issues for users with javascript disabled (if the sniffer is javascript). If your target market is willing to wait for 300kb of non-content-related images I doubt they'd be irritated waiting for a few extra lines of code.
Admittedly that patience would be applied to the other reasons - I guess I'm just of the opinion that nothing justifies time creating pages that use code that has to be completely re-written to have any chance of working across multiple platofrms, user agents and devices. That's especially the case for any browser, and doubly for ie6, which was the primary browser for such a long time its characteristics are mostly known, so by now it should be possible to write code that only requires smaller adjustments.
