Why Switch from Table to CSS layout?

[noonnope]

Thank you JBB, but...

Well you got it backwards. UX talk was about not making the mistake and start your web page dev from the designer's view: pretty pictures, rounded corners, funky shades, coded effects.

It was about starting your web page dev from the very basic semantics aspect, relying on just what basic html is about: content wrapped in proper tags linked by anchors. All this keeping in mind two aspects: visual aspect is just a possible scenario you need to account for, images have also to be content, otherwise they have no place in HTML but in CSS.

Then, if you are a good web dev, you will understand to provide progressive enhancement and graceful degradation of your web page, exactly for the reasons you mentioned:

The average internet surfer uses whatever browser came with their computer. (They don't know or care that others are available.) and they never touch preferences.

You need to understand some will not be the owners of the workstation and thus, even if they could, switching/using/downloading JS, Flash, Silverlight etcetera is out of the question (even more so when they own the damn thing but they have no clue; how do you think they will manage to install Flash, if the browsers doesn't provide a plug-in by default, which many UAs don't). And this, only if their device supports the use of this technology. Also, not all have internet connection plans that will permit them to surf friendly in your bloated web page.

It it certainly NOT a big waste of time, once you manage to see the bigger picture

[DaveMaxwell]

The average internet surfer uses whatever browser came with their computer. (They don't know or care that others are available.) and they never touch preferences. I think if you worked as a customer service rep where you had to deal with the typical internet user all day, you would be utterly amazed (and probably disgusted) at how little they know!
<snip />
So in your evaluation of site functionality I think this might be useful information to keep in the back of your mind. If you're spending a large amount of time getting a site to function correctly if they have images turned off, or if they have changed their preferences on font size, it MIGHT be a big waste of time.

Just a thought.

Depends on how you look at it. If you're looking at a significant percentage of your client base (which for me is over 5%), then you have to take things into consideration. How much business are you willing to drive away before you account for them? 1%-2%? 10%? That may seem like a small amount of business, but when you talk money that gets costly. PLUS, there's an old customer service adage which states that for every bad experience, that person will tell seven. And with the proliferation of social networking, that number can grow exponentially very easily. I know people on Facebook who have > 1,000 friends. If they post a negative review of something and those 1,000+ friends are influenced, don't you think that will affect your (or your clients) business?

Not everyone has access to broadband connections. I have a series of friends who live less than five miles from me, and the best connections they can get are 14.4kb/s - and they say it's often less than that. Broadband just isn't an option for them. So they turn images off by default.

Then there are mobile users which are accounting for more and more users every day. Cell coverage and strength limit the effectiveness, so a number of the mobile browsers don't bring the images down unless you specifically tell it to (Opera Mobile is one that works like that).

You'd also be surprised the number of people that will change the functionality for need. I know of a woman who sets her resolution to 800x600 AND increases her default font size.

[noonnope]

Off Topic:

Poor JJB ! I hereby propose the establishment of the quick response team !

[Stomme poes]

These days there are apparently almost as many "silver surfers" as there are younger surfers and the majority of these "silver surfers" will have some sort of visual impairment and will most likely know how to wind up the text to a readable level.

But, her point that there are many people who don't know how to do this is true.

This usually brings up the question of widgets for things like text-resize and high-contrast. I am against widgets but I'll admit for all those silver surfers and more who did not bother to learn how to use their browsers DO use those things. Our secretary got a special mouse thing with a ball on the side for your thumb... I can't use it, but she needs it. Mostly because she hasn't learned how to use the keyboard effectively (if you try to use a regular mouse with the kinds of crappy menus she has to work with, your wrist will go numb and maybe your hand will fall off).

It's also true that every developer sets a limit somewhere on how far they will go. Nobody supports absolutely everybody or every device. So long as you learn coding as well as you can, and keep learning about what kinds of users and devices are out there, you can offer as few barriers as possible when making sites and usually this is not extra code (extra code and cost come in when you have to change a crappy site to an accessible one. That is almost always more difficult than building accessibly in the first place). As a newbie to this different way of coding, many things we should all be doing are going to be more difficult for you than otherwise; this does change and building accessibly eventually becomes a fundamental way of coding. It takes time to learn it though.

[Paul O'B]

But, her point that there are many people who don't know how to do this is true.

True

[awasson]

Yup: http://www.google.com/support/forum/...19548ec6&hl=en

Aaaarrrrrrrrggggggggg!

But I'm sure someone will write a plugin for it, if they haven't already. Like you, I 99% of the time just want the TEXT larger, not the images all pixellated and out of proportion and ginormous scrollbars and other crap. Just, readable text. ARG chrome ARG. But, whatever. I have 5 other browsers to choose from.

YA HEAR THAT CHROME DEVS? YEAH?? Sorry, they can't hear me over the buzz of happy Chrome users. Damn.

What....

I just went to a few sites in Chrome (not my default browser) and hit the CMD + and CMD - to see what all of the fuss was about but it seems to scale things quite nicely. The whole thing gets bigger but the scroll bars don't change size or shape. I also have to admit I would rather see the whole page zoom that have the text increase in size until it no longer fits within the text area.

I don't see what all the fuss is about?

[awasson]

~ ~ ~

....Throughout this thread I've heard many of you talk about user behavior. You've talked of zooming, turning off images, going into your browser and changing preferences and settings, opening a new window by right clicking, etc. I think because you work in the internet business, are surrounded by similarly-minded co-workers, and because of your natural talents for working on computers your perspective of the "average internet user" may be a bit warped.

The average internet surfer uses whatever browser came with their computer. (They don't know or care that others are available.) and they never touch preferences. I think if you worked as a customer service rep where you had to deal with the typical internet user all day, you would be utterly amazed (and probably disgusted) at how little they know!

I know personally having to deal with clients over the last 15 years it still amazes me that I have to tell customers to click Reload/Refresh to see updates/changes to their site. And half of those don't even know what I mean or where that button is!! Hell, when I ask what browser and version they're using, they don't know and aren't sure how to find out. And these are generally intelligent people who own businesses. (One client didn't know what I meant by the word "browser" hehehe)

So in your evaluation of site functionality I think this might be useful information to keep in the back of your mind. If you're spending a large amount of time getting a site to function correctly if they have images turned off, or if they have changed their preferences on font size, it MIGHT be a big waste of time.

Just a thought.

There are some valid points and observations here...

I know the accessibility police feel that every website must be designed for accessibility over form, over function but I don't think that has to be the case. Websites are unique to their audiences and sometimes you can or should design with your demographic in mind. Yes, if you are designing/developing a website for a financial institution, hospital, police dept, public utility, etc., you will pay close attention to accessibility however, if you are designing for a niche audience, you can tailor to that audience because that it your goal and it gives you the freedom to serve that audience better. You can find out a lot about your audience by reviewing your server logs with something like AWStats as well as analytics reports like Google Analytics.

Just a little something out of the box to think about

[JenniferBigBlue]

Guys, don't even try to imply I'm somehow insensitive to those with visual disabilities when that's not even who I was talking about! I was referring to those of you who thought the average user knew how to go in and turn off CSS, images, change the size of their fonts, right click to open new window, etc. The typical user doesn't.

Now if you're saying I should consider the more sophisticated user who DOES know how to do all those things, well, to them, I AM insensitive!

[DaveMaxwell]

Guys, don't even try to imply I'm somehow insensitive to those with visual disabilities when that's not even who I was talking about! I was referring to those of you who thought the average user knew how to go in and turn off CSS, images, change the size of their fonts, right click to open new window, etc. The typical user doesn't.

Now if you're saying I should consider the more sophisticated user who DOES know how to do all those things, well, to them, I AM insensitive!

What we're saying (OK, at least me but I think the others as well...) is that even if your direct customer is not looking out for those clients which are not the "norm", your outlook should encompass those before you present a final product. Deliver your customer a product which degrades nicely for those that are out of the bounds of the everyday.

They may not notice when you provide that service, but there is most definitely more chance they will notice when you don't - like when they find they're losing business or they get complaints or suits (also here)... And guess what? Even though they didn't think about it and make it part of their requirements, guess who the first person they're going to blame? The professional. Buh-bye future business and/or references.

[Paul O'B]

Guys, don't even try to imply I'm somehow insensitive to those with visual disabilities when that's not even who I was talking about! I was referring to those of you who thought the average user knew how to go in and turn off CSS, images, change the size of their fonts, right click to open new window, etc. The typical user doesn't.

Now if you're saying I should consider the more sophisticated user who DOES know how to do all those things, well, to them, I AM insensitive!

I think we were perhaps reading a mixed message in your comment and what you say is true (and we didn't mean to pounce on you so hard) and many users do not know how to work their computers.

My response was mainly directed at this comment:

If you're spending a large amount of time getting a site to function  correctly if they have images turned off, or if they have changed their  preferences on font size, it MIGHT be a big waste of time.

Yes you are right that it is a waste of time to do that for people who just view the web without knowing how to do any of those things but we don't do all the good things for them we do it for all the people who need/want it.

There are a lot of users who require these enhancements as already mentioned in the previous threads and account for a significant share of the market and indeed are some of the power users of the internet. (i.e.the people you really want to target as they will buy things.)

Just as I mentioned before we don't put ramps outside supermarkets for the people that can walk up the steps. We put these things in place for the people that can't walk up the steps.

Apologies if I missed the point again.

[JenniferBigBlue]

Okay, I "should" design it with every possible variable in mind (user agents, typical visitor, sophisticated visitor, sight impaired, etc.) but I'm not going to do it unless the client pays me to do it. So I'll just be clear in the contract what the parameters are.

Separate question... I'm in the final stages of finishing the CSS. I have run it through the HTML validator and pass. But when I run it through the CSS Validator I get one error that reads... Property behavior doesn't exist : url(csshover3.htc).

Is this something I should be concerned about?

Thanks again!

[noonnope]

behaviour it's a specific MS IE property: http://reference.sitepoint.com/css/behavior. So it's not part of the CSS standard, that's why it's invalid CSS code.

[Paul O'B]

Okay, I "should" design it with every possible variable in mind (user agents, typical visitor, sophisticated visitor, sight impaired, etc.) but I'm not going to do it unless the client pays me to do it. So I'll just be clear in the contract what the parameters are.

Separate question... I'm in the final stages of finishing the CSS. I have run it through the HTML validator and pass. But when I run it through the CSS Validator I get one error that reads... Property behavior doesn't exist : url(csshover3.htc).

Is this something I should be concerned about?

Thanks again!

As noonope said its proprietary IE only code and not part of the css specifications. It will never validate but on the other hand it won't cause any problems to other browsers because they will ignore it.

The only issues are the inherent issue with using it and the fact that it slows the page down. Make sure that you only give it to the browsers that need it and don't let others be bothered with it (i.e. feed to ie6 only vis conditional comments or the * html hack).

[JenniferBigBlue]

So my code should look like this... ?

* html body {
behavior:url(csshover3.htc);
}

What does the * do?

[Paul O'B]

So my code should look like this... ?

* html body {
behavior:url(csshover3.htc);
}

What does the * do?

It's actually the "* html" combined that becomes the hack.

The "*" on its own is the universal selector and represents any element in that position. (That's why people used to do *{margin:0;padding:0} which clears margin and padding from every element (until we knew better).)

However when you say * html that would mean that html had a parent which it doesn't. Although the code is 100% valid it should not actually match anything because there is no parent element for html.

e.g if you said "* body" then the universal selector (asterisk) would match the html element and the rule would be parsed. However when you say * html the browser looks for a parent of html but as there is none it disregards the rule.

IE6 and under however have a bug and parse * html as though you had just said "html" and provides us a perfect and 100% safe hack to target ie6 and under.

[deathshadow60]

Sorry for the delay in responding, I've been... busy pretending it's 1984 before computers sucked and back when people took pride in their work.

and I'm okay with the font size.

Thing is, as mentioned it's not about what you see -- it's part of why the mere notion of a WYSIWYG for web design is one of the most retarded concepts out there as what you see is almost NEVER what the visitor will get. With the plethora of different resolutions, screen sizes, dot pitch and font renderers you have to exploit the original intent of HTML -- device neutrality.

... and in this case that means DYNAMIC fonts (%/EM) and not px. Declaring fonts in PX should be avoided whereever possible; While things like image interactions on buttons might force you to do it, PX metric fonts should be the LAST tool in your drawer. Even PT would be an improvement since at least it obeys the system metric (aka DPI setting of the host OS).

Not everyone uses the default 96dpi, no matter what the webkit-tards claim... My workstation runs at 120dpi, my media center runs at 144dpi, my older CE handheld drops everything to 72 dpi. Some Linux devices default to 75 or 100 dpi. %/EM fonts (on browsers that actually CARE about accessibility... so IE and Opera) automatically resize to what the user OR device wants/needs/expects.... You can declare your existing fonts in the same 'size' on your 96dpi display -- and still have them automatically enlarge for the people that need it/want it/expect it. That's what %/EM and even PT are for.

I mean, your menu is completely illegible here unless I zoom in 50%, which wiht the crappy fixed-width layout (something else I never do or recommend) is a pain in the backside unless I use Opera's 'fit to width' option, which introduces all sorts of other fun HELL.

What do you mean? What do I have backwards?

To me, the images you have in IMG tags are not what I'd have in IMG tags in the markup, those belong in the CSS... and many of the images you have in the CSS I'd consider content and put IMG tags in there for.

I tried nexting it and the javascript stopped working.

That's because you shouldn't be using javascript for a dropdown menu in the first place, except as a fallback for legacy versions of IE -- see my example; the majority of browsers use NO javascript and yet the menu hovers work.

RE:headings

I changed that.

The order still makes no sense to me, since you appear to be using <p><strong>test</strong></p> for what should be H2's. Again, see my example code in the previous post...

re:target or scripted equivalent

I changed it and put it in the CSS. The client wants it to open in a new window.

You can't do that from the CSS so I'm not sure what you mean by that -- as to opening stuff in new windows it was deprecated for a REASON -- the reason being it's piss poor accessibility that breaks normal navigation and was a bad idea from day one. If the client "wants" that, I'd take the time to explain to them how outdated, half-assed and outright STUPID a choice it is to do.

Of course if they want to be an idiot with a garbage website, not a lot you can do.

Isn't image replacement for those on screen readers?

... AND people who turn images off because of limited bandwidth, AND for people on browsers that can't display images but still render much of the screen stylesheet (like many handhelds).

While I might be able to get 22mbps downstream where I live, I travel a mere 50 miles north to Coos county and 33.6 dialup is a GOOD DAY. Large swaths of America still lack broadband -- people in many countries are on metered connections -- and don't forget the metered plans many people are stuck with as the only service... or even the people with the free 100megs/mo wireless service that came with their free CR-48's.

Users who fall into that category will turn images off to save bandwidth, especially if they are just looking for actual information. Others will turn them off as a guage of if there even IS information of value on a page or not. Image replacement methods that don't work when images are disabled COMPLETELY MISS THE POINT.

So it's not JUST about screen readers. There are others it is for as well! Search engines, aural, images off/bandwidth limited users, handhelds, etc, etc...

Don't call my drop shadow "nothing", it's nice!

I wasn't referring to the effect, I was referring to the BLOATED FILE filled with "nothing" but whitespace. 18k of "nothing" -- or more specifically about 1.1k of usefulness and 16.9k of nothing -- This is why in my rewrite the shadow is built using two separate images that only total 1.1K...
http://www.cutcodedown.com/for_other...adowBottom.png
http://www.cutcodedown.com/for_other...hadowRight.png

It uses a hair more code, and there is a extra handshake, but it's still worth the 16.9k savings on the image.

You mean the drop down menu? Doesn't look small to me.

Looks fine on my netbook, absurdly undersized and useless on my media center, primary workstation and road laptop. Good rule of thumb; 6px tall capitol letters are USELESS to about half the browsing public. Images for text that small is useless to about 30% the public when they go to zoom in and get this horrific blurry mess... and wasting images on those is exactly that -- a waste; of bandwidth. That's why you've got about 30K or so that could still be trimmed off the page.

I also prefer fixed width. I don't like the fluid thing.

Which ends up a crappy little stripe on my workstation and is too big for my netbook -- net result? USELESS. Fixed width is usually a cop-out used by PSD jockeys who don't know enough about the internet to be making websites in the first place, NOT a practical web development technique! All it does is alienate the people who do not have that magical combination of the same screen size and resolution as the designer.

There's a reason you don't see many REAL websites with fixed widths, and the ones that do usually go down on a equine of small stature.

[Karpie]

Not everyone uses the default 96dpi, no matter what the webkit-tards claim... My workstation runs at 120dpi, my media center runs at 144dpi, my older CE handheld drops everything to 72 dpi. Some Linux devices default to 75 or 100 dpi.

Just for kicks, my Linux desktop machine claims to be 101 dpi

edit: whoa, and my Linux netbook says it's '128x130 dots per inch'. That's bizarre.

[Stomme poes]

My linux box gets switched between large print and default, depending on what I'm doing.

However when you say * html that would mean that html had a parent which it doesn't. Although the code is 100% valid it should not actually match anything because there is no parent element for html.

Yeah, there's a parent. IE apparently doesn't see a difference between the DOM and the DOM, and who is the parent of html? Document. And who's the parent of Document? Window. : )

IE uses same DOM Jscript uses apparently.

[noonnope]

http://www.w3.org/TR/CSS21/selector....ersal-selector

I don't think * html targets the html parent, in the case of IE. Though Sp assesment is correct, when talking about classes.

[noonnope]

Past edit time. At work you have to answer when the boss is calling you

I mean, yeah, the extra root element in IE6 and all that. But I'm still not conviced it's actually going for the <root>, since then it would be so easy to just put: root html and have a valid CSS.

[Paul O'B]

http://www.w3.org/TR/CSS21/selector....ersal-selector

I don't think * html targets the html parent, in the case of IE. Though Sp assesment is correct, when talking about classes.

Perhaps I wasn't clear enough

For "* html" to work it would mean that html must have a parent just as "* p" would target the parent of the p element.

Whether IE6 thinks that html has a parent is just an analogy for what would be needed for it to work but in all honesty it's probably just a broken parser and they forgot to stop when they reached html.

[YuriKolovsky]

@JenniferBigBlue
To start, I'm from the same client environment as you, with the same "average internet user"'s that you get, and yes, I have to show them each time how to press the refresh button, what a favicon is, what a "tab" is, and by far most of them don't know what a "browser" is, where the address bar is, how to use the Ctrl button, what is zoom, that Paint is a program, what is a program, what is a file, extension, folder, sometimes I even have to teach them how to use a mouse...
It is much harder when they refuse to learn even the basics, saying that it's my job that everything "just works" (and they are somewhat right) without their interaction at all.
anyway...

Here are some more reasons to use CSS over DW templates with tables for layout.

1. CSS allows you to create dynamic layouts that are impossible with tables, sparking your creativity and allowing to design webpages that are more than a pretty 2 dimensional picture.

I will probably have to explain this further.
A webpage is not a piece of paper, it allows you to overlap boxes, hide boxes, show boxes on demand, and alter the design of the page depending on the monitor width or height or other external factors, it allows you to express your design and creativity in more ways than a piece of paper ever could, while DW template tables are mostly limited to the design on a 2D piece of paper approach.
Another example are hover links, try and add a hover state to a link with only inline css styles with tables, I can't do it...

A fun example: you could hide some image in the background and have it visible only for people with excessively large or small monitor with a message just for them.

So consider learning CSS and using a mix of both, where appropriate.

2. Inline CSS, as in, CSS that is in the html tags, is not cached, while a CSS stylesheet is cached, meaning that CSS is more efficient for high demand websites, as Paul has explained in detail, it is not a issue for you if you only have small low demand websites or lots of "one single visit" visitors, in this case having external stylesheets hurts performance, so pick whatever fits your current situation best.

3. CSS is a cascading style language, not many people bother to explain what this means, probably because it is hard to explain.

Cascading means that new styles cascade (overlay) on top of the previously defined styles, partially of fully.
Something that is barely visible with inline CSS on tables.

In essence it means you don't have to repeat yourself as much (depending on your skill level), which is what everyone these days strives for, even though DW does the repeating for you, DW still can't handle the more advanced cascading relationships of CSS that are easy to create on your own.

here is a oversimplified example:

em {
font-style:normal;
}
p span {
font-style:oblique;
}

the first bit makes "em" tags look like normal text for any part of the website, while the second bit makes them look special for paragraphs only.

You can let your organizational genius out, and organize the whole structure of styles on your website into something modular (a pack of reusable independent rules) without a single repeated CSS rule. why? Because this way you can copy&paste™ more CSS and you have more control over what you do, and more control means you can create things that you could never create before and thanks to modularity you can create it faster (even though DW allows you to re-use snippets there is still more control with just CSS).


4. People and your website visitors and even your clients spend most of their time visiting OTHER peoples websites.
So they will feel comfortable with what the MAJORITY of websites that they visit are doing, and how the majority of websites they visit look like.
By staying where you are, even if you feel comfortable where you are now, will make you go against the flow, and eventually the flow will wash you away.


but for me, reason #1 that I mentioned is reason enough to work mostly with CSS.

Overall I suggest you learn CSS even if it is hard, consider making it fun, make some challenges, or take part in the CSS contests and quizzes sitepoint regularly holds.

After you have learned CSS, it will seem much easier to design and work with it.
And you will be able to pick the best tool for your current project instead of being stuck using only your old trusty tool-set.


I hope this helps you see some of the benefits, even if your clients don't see most of them.

[YuriKolovsky]

Even if I am more than a month late... and you have solved the question thanks to Paul's charms (and everyone else).
I would still like to point out.

Q. Why switch from Table to CSS layout?
A. Because it will be easier to switch to whatever comes next.

[discarnateEntity]

I think I get the gist of the arguments against using html tables to position non-tabular content, but I'm still not quite clear on where the anti-table folks stand on CSS tables (i.e. divs styled to work like tables). Other than incompatibility with old versions of IE, are there any objective reasons not to use CSS tables for layout in situations where they would provide the simplest solution? There are still some design goals that can only be achieved using elements that behave like tables, right? Or is it now possible to do anything a table can do using only floats, margins, positioning, etc.?

[Paul O'B]

, but I'm still not quite clear on where the anti-table folks stand on CSS tables

We're not "anti tables" we're "anti anything that isn't being used for the purpose it was designed". Tables are fine for tabular data whereas CSS styled divs would be wrong for tabular data.

Regarding the display:table properties then their purpose is to mimic some of the behaviour of tables but only for layout purposes (not to provide a basis for tabular data).

If for example you wanted equal columns then you could use the display:table-cell properties to create a series of equalising columns. They are also useful if you have a number of horizontal elements that need vertical alignment and you can use the vertical-align properties on the display:table-cell elements to align them as required.

The problems width display:table are the same problems that you would have with normal tables in that cells will always stay horizontal and will not wrap to another line which floats will do nicely and thus fit into a smaller window without the need for scrolling.

I seldom see a need for creating a whole site using display:table but rather for the odd element(s) that need a special table behaviour. The rest of the time floats and other methods are usually more suitable.

It's just another tool in the css toolbox which you should use wisely and when needed.