homepage Welcome to WebmasterWorld Guest from 54.196.195.158
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor 2014
Visit PubCon.com
Home / Forums Index / Code, Content, and Presentation / CSS
Forum Library, Charter, Moderator: open

CSS Forum

    
Slicing images, how does it differ using div's and floats vs tables
AffiliateDreamer




msg:3586395
 8:15 pm on Feb 27, 2008 (gmt 0)

Hi,

I think I have a basic level understanding now of CSS using floats etc.

Is there a fundamental differece between how one slices up images in a PSD file when one is using floats for layout versus a table layout?

 

fside




msg:3586605
 11:42 pm on Feb 27, 2008 (gmt 0)

You don't really see a lot of the old 'single image' rollovers anymore, whether the slices are floated in or part of an elaborate row and col span table. If you do see something of the sort now, it's probably Flash. I would think the slices themselves would have to be the same, if you intend to mimic the slicing used in table. I wonder if you could count on various browsers to float everything as you imagine? Not all pass the acid2 test.

ergophobe




msg:3586635
 12:23 am on Feb 28, 2008 (gmt 0)

You'll probably be okay if the containing div is sized right and you don't have any margins, padding or border and you aren't trying to test a million things at once as int he Acid2 (which is after all designed to break browsers, not play nice).

AffiliateDreamer




msg:3586707
 2:37 am on Feb 28, 2008 (gmt 0)

Don't all tabless float designs put images in divs tags?

SuzyUK




msg:3586943
 11:19 am on Feb 28, 2008 (gmt 0)

Don't all tabless float designs put images in divs tags?

no, background/decorative images can be attached to ANY element, not necc divs but they should be background images unless the image itself is pertinent to the content e.g. a logo in which case it should go in the HTML, but again it needn't be IN a div it could be in e.g. an h1..

anyway in difference to ergophobes answer I would say that image slicing differs in that you should NOT think about pixel perfect div sizes and image slices like a table grid, think about what happens if/when a div, or any element inside that div were to expand, with content

I can't think how to explain this to you any better than a few of us here have already tried ;) I know you're trying to get it, so I'll try a visual reference.. (using an allowed reference source ;))

here's a csszengarden submission [csszengarden.com], yes it's mine, and it's not that pretty, graphics were certainly not my strong point back then, but it's once of those submissions that serve a technical purpose to showing what css can do rather than a design skills one.. and bears on this discussion hopefully

Pretend that that's a table, and that the top left cell contains "the road to enlightenment" text and the top right is the demonstration text part.

the graphics in question would be the border dividing the whole page vertically, the bottom 'border' of each of the top 'cells', the top rounding of the vertical stripe and the footer graphic, if that where a table you would need to slice all those graphics into squares/rectangles to fit with your markup (i.e. the table cells) and choose which side of the table was to hold the vertical stripe and slice the images accordingly

..now take a look at that page and zoom the text up a few sizes, see the how the vertical space between the two bottom borders increases, and the vertical strip itself doesn't break that's because those images are not in cells/square divs they're background images that are attached to elements within the divs so they move with the content rather than the "grid", those cells/divs don't need to be the same size - in order to create this effect with table cells you might've need to add a spacer gif or emtpy cell to create the illusion of an empty stretch.. but anyway back to image slices..

the bottom "border" images are not attached to the vertical border, at least not in a graphic slice sense they are independent (actually I see I created them so they do contain a wee bit of the vertical border, this was likely to ensure the rounded part remain smooth but anyway that's another story). The border images are only "attached" visually to the vertical border image by positioning the divs containing them (they're floated into position)

the top of the right 'cell' is created by adding a background image ("beauty of css design") to the first element in it, an h1 and not a div at all, this image contains not only the "heading" which is only right for a h1 ;), but also the top rounding of the pages vertical stripe - again it's simply sitting on top of the stripe that's already there so no need to worry about the height of the slice

The horizontal borders are sitting on top of the background stripe too and when the size of the two divs increases vertically to a point where the element containing those backgrounds run out of background (i.e. slice not tall enough), the body background stripe will show through and take over the look

- the footer graphic, the one which holds the rounded corner finish to both "columns" is all in one, at least horizontally it is 100% wide and simply sits on top of the body's vertical stripe, hides the blunt finish and provides the illusion of full column stretch without you needing to make sure a cell or div stretches that far down!

the vertical border splitting the whole page is a 2px high repeating background graphic attached to the body element - it not only provides the vertical border but the background color for the whole page and it needn't be involved in any of the previous slicing at all. it's also the guideline to make sure the horizontal images are positioned properly, your positioning and sizes needn't be pixel perfect as it wouldn't matter too much if the horizontal images overlapped the vertical one by a couple of pixels, though that depends on the actual design! (the rounded bits was my challenge to myself at that point and did mean positioning had to be quite accurate)

The whole illusion is created like a vertical 'sliding door' technique, and without the rounded perfection it could be done with less accuracy

see can't even explain it very well with a visual reference :o - the main thing is if I'd been given that design in photoshop first I would not have simply sliced the images gridlike and then forced the markup to fit by creating divs to hold the images, I would've marked up the document first using logical divisions, headers, paragraphs (which was the point of the csszengarden, it was already logically marked up and you can't touch the markup) - then I would've needed to look at which ELEMENT might be best suited to holding which parts of the graphic.

the body was best suited for the vertical stripe as that ensured it's always in a straight line an avoided the need for it to be included in any of the other graphics

hth and feel free to ask, I know I've not explained it very well!

-Suzy

btw.. if you have firefox and go to tools>page info>media tab you can drill down through the images used to "see" the actual images used rather than trying to visualise it by slicing the screen, try it with some of the other zengarden submissions too, I find it helps

Old_Honky




msg:3586973
 12:04 pm on Feb 28, 2008 (gmt 0)

I thought "slicing and dicing" was now virtually defunct. Is it not considered to be the old way of doing things? I assumed it had gone the way of tables for layout. i.e. only used by the uninformed and the stubborn.

With modern browsers and higher speed connections surely there is no longer any valid reason for this crude method of making a web page as though you are assembling a jigsaw puzzle.

[edited by: Old_Honky at 12:05 pm (utc) on Feb. 28, 2008]

SuzyUK




msg:3587014
 1:19 pm on Feb 28, 2008 (gmt 0)

>>I thought "slicing and dicing" was now virtually defunct.

imho it is, well the dicing part anyway. The slices do not go in grid cells, they do not go into anything coded simply for the purpose of holding an image - i.e. you do not make the grid of <whatever> elements simply fit together just for the sake of the design and like a jigsaw, which is a great description btw!

the question AD has been asking, and not just in this thread, is what a lot of folks struggle with - How you get from that kind of thinking (photoshop to jigsaw) to the CSS design suggestion kind of thinking?

slices, not dices, are still useful in letting existing elements contain the illusion of a complete complex graphic, the background image slices are attached to existing elements in order to suggest the complete picture

e.g. take the zengarden (again) look at all or a selection of the designs - could they have been done with a table, yes they could but the tables would likely all have to be marked up differently as they would have had to have been built to fit the design - they could not all been done with THE SAME TABLE marked up code. Whereas they are all done with the same logically structured HTML markup. "jigsaw" designs are reliant on the markup, 'suggested' designs aren't.

I think what some find hard with CSS design, is the fitting the image slices into existing elements, (which is truly what's meant by separation of content and design), they can't see where the elements are yet, and don't know how to slice the main graphic so the do they old-fashioned way and slice the image first the try to markup, using divs, to fit. Elements which make up your "design grid" needn't be table cells, in fact they needn't always be divs either. You don't need to force the grid that might hold your complete graphic even though you can see it your head, let it build itself.

To let it build itself, you markup the content using logical divs nav header sidebar footer etc.. add some background colors to these "main" divs and then add main elements like h1, h2, <p> etc - float/position the main divs where you would like to appear, but don't try and force them to height or anything - then superimpose your photoshop design over the top of your naturally built grid and "see" which elements are best suited to hold the main slices that would allow your "complete picture" to appear. a lot of the rest of it (the varying content heights/widths bits) can likely be done with background repeating images or nested span "hooks"

sorry if that sounds silly, but it's really hard to describe a visualisation method in words :)

ergophobe




msg:3587290
 5:17 pm on Feb 28, 2008 (gmt 0)

>>the question AD has been asking... How you get from ... (photoshop to jigsaw) to the CSS design suggestion kind of thinking?

I was thinking about the slicing and dicing where the image is the content. I've never done the "slice and dice into tables" layout since I never really learned to use tables for layout, but I'm into places that show very large images [xrez.com] (though with much better technology than slicing and dicing).

SuzyUK




msg:3587352
 6:18 pm on Feb 28, 2008 (gmt 0)

but that wouldn't really be the job for CSS at all would it ergo, CSS is a mechanism for adding a layer of presentation suggestion to a document of content.

If the reason for slicing/dicing images in the content is page render speed for high res images - it's not for divs (and ultimately CSS positioning) to control the layout of that imho. If that's what someone thinking of using it for then why not just continue to use a table for that bit? You could argue that an image is data and is sliced into smaller chunks for no other reason than you want that data/table to render quicker. I'm also thinking of how the page would read with CSS turned off, a image sliced into a table would still show the full picture whereas positioned divs wouldn't.. or am I not getting what you're saying?

ergophobe




msg:3587362
 6:38 pm on Feb 28, 2008 (gmt 0)

No no... I agree totally with everything you've said since point one.

I just trying to explain that originally I got shortsighted and was replying to the specifics (is it technically possible to combine images in a grid using CSS?) rather than back out a step (why would you do it? what is your actual goal?).

And yes, the problem isn't so much the floats, which can be managed, but the concept.

swa66




msg:3587713
 2:35 am on Feb 29, 2008 (gmt 0)

Personally I think CSS needs a huge step back to understand it fully for those deep into slicig, tables (ab)used for layout etc.

One of the steps is back to the original intention of HTML.
Get back to just title, text etc. tags that say waht they contain. Sure you get more of them but the content is back to being just content.
Next take all the layout and move it to the CSS.

As for the paradigm you use as a layout, try not to think of a page divided in cells that make up a table. Think outside of the box (instead of inside).

You can basically grab content and put it where you like.
You can take content out of the flow.
You can float items and the text will wrap around it without you doing much effort or even knowing the font size.

Don't think of CSS as somethign you apply on div's and spans.

So try a few things, try to position items on a page, try a few floats. And now think of layout as something where you can drop stuff on the page, and then let the main text flow in between it all. Style a h1 tp be as high as the background banner, position the text over the banner determine it's hight to have the menu fit in nicely underneath.

Cover the <ul> collection of links into a sliding doors menu that'll look more stunning than anything you made before.

Live will be cool till you run into that browser ... then learn about conditional comments and i's plethora of bugs that don't get fixed (they're features now).

As soon as you draw a grid to place things on, a 3 col layout or so, -in my experience- you lost more than half of what CSS could do for you.

vol7ron




msg:3587781
 4:51 am on Feb 29, 2008 (gmt 0)


As for the paradigm you use as a layout, try not to think of a page divided in cells that make up a table. Think outside of the box (instead of inside).

You can basically grab content and put it where you like.
You can take content out of the flow.

This is all good until you meet the positional problems between the different browsers. Until all browsers conform to the same standards (proprietary or 3rd party), some problems will exist. There are workarounds, but it depends on how important the site is to you. The best sites are not the ones that look the most interesting, but are more professional looking with meaningful content.

As soon as you draw a grid to place things on, a 3 col layout or so, -in my experience- you lost more than half of what CSS could do for you.

I disagree. The most important thing that CSS provides is the ability to quickly change sites across multiple pages. It also speeds up the downloading of the material by downloading one file that is used for multiple files. This not only saves time/bandwidth for users, but servers also experience a lower transmit cost and are able to afford a lower quota for more users.

These are the most important attributes of CSS, and in my opinion account for at least 75% of why it was developed.

____________________________________________

As for the original question. There is almost no difference b/t slicing and dicing for a div or for a table. DIVs are harder to position, but images that span over multiple rows/columns can also make tables hard to arrange.

Whomever said slicing and dicing was useless does not yet understand how images are loaded in a page and how anti-virus programs can really affect load times. Additionally, what would you rather, missing a corner of a 500x150 image or missing the whole thing? While transmission speeds and other hardware are improving, they are still not at the point that you can just write off the slice-and-dice approach altogether.

ergophobe




msg:3588211
 6:01 pm on Feb 29, 2008 (gmt 0)

>>does not yet understand how images are loaded in a page

Hmmm this is sort of on-topic to how I originally tookb the question... not sure we should go there, but I have to ask: care to elaborate.

As I see it, one disadvantage is that a browser will only stream two http requests at a time (one if it's a script), so if you split an image eight ways, it means that you have eight http requests split over two streams, so you have your network latency times four, just for one image. If it's a large image with a lot of difference between the parts, you might earn that back by really compressing some areas (for example compressing the grass a lot and leaving the sky high quality to avoid jpeg artifacts), but I suspect that for most users latency will be the bigger issue (obvsiously bandwidth comes into play - the lower the bandwidth, the less significant latency is).

Is that what you're thinking?

On your other point, I have to agree in this sense: presentation should be optimised for the reader, not the presentation technology. If you do usability testing and find that a three-column approach works best, that's what you should do. I'm not necessarily advocating three columns or two or four or one, I'm just saying that design principles used in the print world are not all transferable, but they aren't random either and even pre-date print in some cases (e.g. golden ratio, which speaks directly to the issue of slicing and dicing and boxes and columns, and the practice of dividing pages into columns beyond a certain line length).

At the same time, obviously one needs to be mindful of the medium. Page lengths are uniform within a work in the print world for obvious reasons and you just can't get around that. Similarly, some things don't work well in CSS, but there are perfectly usable, readable solutions.

In general CSS, with it's ability to do print-style sidebars using floats (i.e boxes that are the size of the contents, not randomly set as a column or table row), specify layouts where the line length in characters remains roughly the same regardless of physical size, is a boon actually and in most ways CSS allows for more usable, readable design. That said, where it doesn't or where it makes it cumbersome, you may just need to whack it with a bigger hammer (and by the way, my web design skills stink, so no hammer is big enough to save my designs - I'm just talking principles here! - but I actually typeset my books and people tell me they look better than many others in my field).

SuzyUK




msg:3588270
 7:10 pm on Feb 29, 2008 (gmt 0)

I'm lost ;)

but re:
>>does not yet understand how images are loaded in a page

I think that's actually the crux of the matter between images for table layouts and images for CSS Design

in general sliced images for table layouts are ON PAGE content images, and images used in CSS Designs are OFF PAGE, background images - the CSS ethos is that that the style of a page should be kept separate from the content, not everyone views your page using a screen so don't force your design into the content - if a user turns off CSS or prints out a page, they should only see CONTENT images - which is why I previously said that perhaps you might want your logo to be a content image.

Like I said before if you're slicing a content image for rendering reasons then sure put it in a table (or use some of that fancy technology that I think ergo is talking about ;)) - but as far as CSS layouts are concerned forget the "force it" and think "suggestion"

as for not understanding how images are loaded on a page (btw, I didn't say it was useless, I said it was "virtually defunct" AS FAR AS CSS DESIGN is concerned) I think I understand (well I might not understand the best way to compress high res. graphics but I understand the need for it exists.).. but perhaps others don't understand that there is a difference?

For CSS design we don't need load speed, it makes no odds to the page if the graphic loads quickly or not (hence unecessary need to dice), it is after all just a suggestion to the browser. just think I can start reading the content whether the background image has loaded or not. IIRC that is why it's important that tables render the "diced" images as fast as possible because until (at least the top lot) render, you can't start reading the content?

That's what makes the dicing unnecessary for CSS, large slices however can be made once the best place to attach them to is found

the technicalities of slicing images for off page DESIGN are probably not quite as complex as the case being made here for content slicing/dicing

-Suzy

[edited by: SuzyUK at 7:31 pm (utc) on Feb. 29, 2008]

swa66




msg:3588514
 1:07 am on Mar 1, 2008 (gmt 0)

HTTP 1.0 loads images each on their own TCP connection (with a slow start) and connection buildup and termination.
Browsers start up to 10 parallel connections when using HTTP 1.0.

HTTP 1.1 loads images one after the other over the same TCP connection. Only one slow start is involved and a connection can load multiple items (css, images, html, ...)
Browsers typically only start a total of 2 parallel connection when usign HTTP 1.1

So as the servers migrated to HTTP 1.1, our need to code for many small items (in order to get the parallel connections all to work), changed to code for fewer, larger items as they are in total smaller and thus will load faster.

Since browsers show content items progressively on slow links, this might be an issue for those still on dialup of for huge pages. On typical fast network connections, the browser is the slow part, not the network nor the typical server.

IMHO slicing is done with and forgotten even outside the CSS world unless to allow table layout to work. The original reasons don't exist anymore (at least in the area I work in). I guess it can be different if you have many visitors still on dial-up, but since that simply is dead out here I've a hard time imagining using it anymore.

ergophobe




msg:3588559
 2:10 am on Mar 1, 2008 (gmt 0)

One little tip on that note Suzy... I think where people get messed up with background images in CSS is failing to specify a background-color that roughly matches the color and greyscale value of the image to ensure that text is still readable even if it takes a moment for the BG image to load or the load fails.

Ideally, you should see how your page looks with no background images loaded, and take a screenshot, open it up in photoshop and convert to greyscale. That will give you an idea of how failsafe it is and how friendly it is to people with various vision impairments (not just colorblindness).

Poor Suzy... I know this is only tangentially related...

swa66 - Sorry - right, connection is persistent and requests are queued, so no significant latency after the first two requests right? For anyone not following that part of the discussion, check out

[video.yahoo.com...]

SuzyUK




msg:3588914
 7:07 pm on Mar 1, 2008 (gmt 0)

>>Poor Suzy... I know this is only tangentially related...

I'll let you off, but only cos you put that video link in of which a part is highly relevant :)

I watched it all, it's very interesting - wrt this discussion and image slicing it's the first bit (about 8 minutes in) which is an eye opener

Souder say's the rules (that front-end developers can follow) for improving page load times are in order of importance and look what's in at number one..

Rule #1 = Use CSS Sprites

so stop dicing and start merging! :)

in the video he uses an example of 60 icons merged together into one image - load once and reuse using CSS background positioning so it dramatically cuts the number of http requests - the exact same principle could be applied to the larger image slices used in page design, although admittedly in some designs it might be very hard to visualise how to merge "irregular" slices into a single sprite it is possible. (I have such a cool example of complex sprite but I don't think I can link it.. it shows that even merging irregular slices, not just square icons, can be done in a sprite)

when I say slice as opposed to dice that's in effect what I mean really, a slice is already just some merged parts of a graphic that might previously have been diced, a mini sprite if you like, it is just not on such a grand a scale as a full blown sprite

-Suzy

added: found a great online example

ask.com > right click on the ask logo and view the background image!

[edited by: SuzyUK at 1:30 pm (utc) on Mar. 2, 2008]

ergophobe




msg:3590109
 5:54 pm on Mar 3, 2008 (gmt 0)

That's where the two strains in this thread merge. Both matter
- total size of images as an aggregate
- number of pieces it takes to build your page

Ideally, you want to reduce both of those as best you can, but typically there's a bigger gain to merging lots of little images (as in the video, turning 60 requests into 1) than in slicing high-res images and doing custom compression on a per region basis.

That being true, if you're just talking about getting images loaded that provide the look of your site (which are presumably not super high-res), for layout and presentation you are indeed better off merging than slicing.

Now I just ave to learn how to use sprites for rounded corners.

vol7ron




msg:3590280
 8:51 pm on Mar 3, 2008 (gmt 0)

>>does not yet understand how images are loaded in a page

Hmmm this is sort of on-topic to how I originally tookb the question... not sure we should go there, but I have to ask: care to elaborate.

As I see it, one disadvantage is that a browser will only stream two http requests at a time

Correct. I believe I was unclear. Slicing and Dicing should be avoided, except for larger images. It's sort of similar to deciding on whether to use an interlace or not. Many times, images are sent but certain packets either go missing, get corrupt, or are not fully transferred resulting in those missing-image boxes.

Additionally, the prefetch for anti-virus can really effect page rendering. That is, it is easier for the anti-virus application to scan multiple smaller files than it is to scan a large one. As security is becoming more and more intense, a large bulk of page rendering time is going to the pre-processing that the anti-virus application is performing.

Like anything else, it comes down to optimization and not one set answer. The reality is you don't want too many tranmissions, as that is a lot of overhead, but you also don't want too large of files, as the user gets bored with doing nothing.


presentation should be optimised for the reader, not the presentation technology

I think anyone would be dimwitted to disagree with this. However, my point was directed a little more towards the select few that make their page very artsy, with not much to say. That is the page is so out there, with a futuristic design, or lots of well made graphical images, but there's nothing to read. Being a website critic, everyone should realize that the professional-looking sites are the ones that generate the most traffic, not the sites with the best graphics. Keep in mind that the higher traffic generally translates into a higher revenue.


by the way, my web design skills stink, so no hammer is big enough to save my designs

If I were advocating that my sites are the best, then I'd be a liar. Additionally, if I were to say I was the best coder, I'd also be lying. I feel as if we come in circles. We learn something well, move on to something else, but forget the first thing and have to relearn it again. Over time we can incorporate it all into one solid masterful piece. Until then we perfect our skills and help each other out.


vol7ron






swa66




msg:3590314
 9:23 pm on Mar 3, 2008 (gmt 0)

ask.com > right click on the ask logo and view the background image!

I love the example!

Just imagine how easy it is to change things there.

vol7ron




msg:3590581
 6:00 am on Mar 4, 2008 (gmt 0)

What a brilliant example.

One criticism, too much white space; however, wtih 450x450 @ 50KB it's not too bad. Just curious what would happen if they utilized all the white space or reduced the image size.

The only good thing about this is that it might be easier for them to make additions without modifying positions.


vol7ron





SuzyUK




msg:3590639
 8:20 am on Mar 4, 2008 (gmt 0)

>> too much whitespace
haven't studied all of asks image, I don't think the white space is all that much of an issue simply the mere fact that it's one image is the point of it .. anyway I imagine the reason for the whitespace is what I referred to earlier in that when creating a sprite from "irregular" images you would have to allow for text resizing and that a part of another part of the sprite/image won't overlap into anothers space
e.g. despite what the video says, this is the actual image used on yahoo [us.i1.yimg.com] - you can't really make a successful sprite by just cramming the image together - if you go to Yahoo.com home page and look at the menu in the left sidebar.. if you zoom the text up a few sizes (quite a few so I'm not saying it's an issue) the icons on the right side of the sprite eventually start to show on the right of the menu items

>>Now I just ave to learn how to use sprites for rounded corners.
The 'ask' example does that, though again I've not looked at what bits do what, the ingredients are there - the whole of that sprite has a rounded/shaded border and that can be used to create rounded boxes - the rounded multicolored search boxes are also in there, then see that square shaded bit with the white dot in the middle.. that's four corners together, I think it's the ones used on the main background of the home page.

ergophobe




msg:3591265
 9:34 pm on Mar 4, 2008 (gmt 0)

Because of the way GIF compression works, repeated pixels of the same color (in this case white), especially on the horizontal axis, add very little to the file size. Try making a monochromatic white image 1px wide x 10px long. Now make it 1000px long. How big is it? 100 times as big? Nope.

I get 44 bytes for the 10px image and 71 bytes for the 1000px image using PS CS3 Export.

vol7ron




msg:3591354
 10:39 pm on Mar 4, 2008 (gmt 0)

...you would have to allow for text resizing and that a part of another part of the sprite/image won't overlap into anothers space...

That is important to remember, but in terms of borders and corners and buttons that should not be affected by font sizes, this shouldn't matter. Even when pages are zoomed in/out or the browser's text size is changed. This is why you see certain images very close together. None of these images are backgrounds with a text overlay.


Because of the way GIF compression works, repeated pixels of the same color (in this case white), especially on the horizontal axis

Thanks for the lesson on GIFs, but this is a PNG image, which although it too has a great compression, it is lossless. Your point is still valid and will apply in this case, but you shouldn't use the GIF as an example when talking about PNGs, the compression would be much higher because bits are being lost in the process.


vol7ron





swa66




msg:3591390
 11:01 pm on Mar 4, 2008 (gmt 0)

Thanks for the lesson on GIFs, but this is a PNG image, which although it too has a great compression, it is lossless. Your point is still valid and will apply in this case, but you shouldn't use the GIF as an example when talking about PNGs, the compression would be much higher because bits are being lost in the process.

Both gif and png have lossless compression.

png has a much larger colorspace and support for transparency that gif lacks. unfortunately soem rather popular browser maker out of Redmond doesn't finds full png support important enough to actually fix their used versions of their browser.

ergophobe




msg:3591454
 12:40 am on Mar 5, 2008 (gmt 0)

>>this is a PNG image

I was going off the image that SuzyUK mentioned at Yahoo, which is a GIF, but the principle and the compression methods are similar.

As swa66 says, both are lossless (though you can do additional lossy compression with Photoshop) and I believe that if you run the experiment with PNGs you'll find pretty much the same effect - large chunks of similar color results in excellent compression. Basically the same as you'll see with zip and gzip compression. If you had a text that consisted of nothing but the letter "a", there wouldn't be a huge difference in size between a text of 100 characters and one of 10,000 characters (i.e. you don't have a 100-fold difference).

In the simplest terms, all three methods essentially look for patterns and then make a note of how often the pattern is repeated.

Demaestro




msg:3595120
 6:28 pm on Mar 8, 2008 (gmt 0)

For SEO purposes many will argue that divs and css floating is the way to go. BUT hold on there is more to the story.

It really depends on the site in question and what it's purpose is. The fact is that 85% of the end viewers of the site have no idea what is going on in the background and more importantly they don't care.

If your site is a content site and you have ads and your business model is to drive viewers and get revenue from ads then table-less designs and highly SEO'd sites is of primary concern... but if your site is to give you an "online presence" to compliment your brick and mortar store or your local services then it really doesn't matter as long as the site loads fairly quickly, is well organized, and is attractive to the eye ... PHP, CSS, Python, Javascript, HTML, Tables, Divs... this is all noise to the end user. They don't care. They want "sizzle" and "a fresh look". They aren't pulling the source of the page to scrutinize the efficiency of the javascript.

So if your site is something you send customers to and the URL is promoted in your print ad campaigns and is something you want to come up when people do local searches for your business's products or services then tables vs divs is not going to matter again... as long as the site loads fairly quickly, is well organized, and is attractive to the eye.

rocknbil




msg:3595263
 10:08 pm on Mar 8, 2008 (gmt 0)

Been watching this thread develop, as a recovering table junkie I'll add one of the things that's great about breaking away from tabled layout is not having to slice images any more, making it easier to "chunk out" visual elements and change them without having to generate new "slices."

swa66




msg:3595273
 10:23 pm on Mar 8, 2008 (gmt 0)

I've a friend still doing the slices, graphic menu's etc. he does that for customers of his and the results are rather artsy.
I heard him get a phone call from one of his customers asking to have one more button in a menu just before the site was set to go live. He was actually almost in panic, while I didn't see the problem till I looked at the code:
the entire page was sliced, the hover effects were javascript based, so he basically had to redo it all just to add another item on a row of menu items.

I eventually did show him how easy sliding doors are to create fancy looking menus in a simple fashion ... after he recuperated from the all-nighter to fix the site for his customer in time for the launch.
Sure we might occasionally struggle thanks to IE's broken model and the abundance of unfixed bugs. But once it works we typically can add another page without changing everything else.

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / CSS
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved