ansaurus

Question

Is there a business reason for striving for pure CSS layout?

Answer 1

+6 A:

I'm of the thought that CSS layout with as few tables as possible is cleaner and better, but I agree that sometimes you just gotta use a table.

Business-wise, it's generally "what's going to get it done the fastest and most reliable way." In my experience, using a few tables generally falls into that category.

I have found that a very effective way to mitigate cross-browser differences in CSS rendering is to use the "strict" doctype at the top of your page:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"&gt;

Also, for the dreaded IE6 CSS issues, you can use this hack:

.someClass {
    background-color:black; /*this is for most browsers*/
    _background-color:white; /*this is for IE6 only - all others will ignore it*/
}

Terrapin 2008-08-07 21:18:49

Answer 2

+10 A:

Like a lot of things, it's a good idea that often gets carried too far. I like a div+css driven layout because it's usually quite easy to change the appearance, even drastically, just through the stylesheet. It's also nice to be friendly to lower-level browsers, screen readers, etc. But like most decisions in programming, the purpose of the site and the cost of development should be considered in making a decision. Neither side is the right way to go 100% of the time.

BTW, I think everyone agrees that tables should be used for tabular data.

palmsey 2008-08-07 21:20:11

Answer 3

+1 A:

Business reason for CSS layout: You can blow away the customers by saying "our portal is totally customizable/skinnable without writing code!"

Then again, I don't see any evil in designing block elements with tables. By block elements I mean where it doesn't make any sense to break apart the said element in different designs.

So, tabular data would best be presented with tables, of course. Designing major building blocks (such as a menu bar, news ticker, etc.) within their own tables should be OK as well. Just don't rely on tables for the overall page layout and you'll be fine, methinks.

Ishmaeel 2008-08-07 21:22:25

Answer 4

+4 A:

The idea is that Designers can Design and Web Developers can implement. This is especially the case in dynamic web applications where you do not want your Designers to mess around in your Source Code.

Now, while there are templating engines, Designers apparantly just love to go crazy and CSS allows to pull a lot more stunts than tables.

That being said: As a developer, i abandoned CSS Layout mostly because my Design sucks anyway, so at least it can suck properly :-) But if I would ever hire a Designer, I would let him use whatever his WYSIWYG Editor spits out.

Michael Stum 2008-08-07 21:23:55

Answer 5

+6 A:

Keep your layout and your content separate allows you to redesign or make tweaks and changes to your site easily. It may take a bit longer up front, but the longest phase of software development is maintenance. A css friendly site with clear separation between content and design is best over the course of maintenance.

Justin Standard 2008-08-07 21:25:07

Answer 6

+6 A:

I would let him use whatever his WYSIWYG Editor spits out

I just threw-up a little...

Terrapin 2008-08-07 21:25:23

Answer 7

+7 A:

Using semantic HTML design is one of those things where you don't know what you're missing unless you make a practice of it. I've worked on several sites where the site was restyled after the fact with little or no impact to the server-side code.

Restyling sites is a very common request, something that I've noticed more now that I'm able to say "yes" to instead of try to talk my way out of.

And, once you've learned to work with the page layout system, it's usually no harder than table based layout.

Jon Galloway 2008-08-07 21:26:41

Answer 8

A:

:: nods at palmsey and Jon Galloway ::

I agree with the maintainability factor. It does take me a bit longer to get my initial layouts done (since I'm still a jedi apprentice in the CSS arts) but doing a complete revamp of a 15 page web site just by updating 1 file is heaven.

Dillie-O 2008-08-07 21:39:06

Answer 9

A:

Some additional reasons why this is good practice:

Accessibility - the web should ideally be accessible by all
Performance - save bandwidth and load faster on mobile devices (these lack bandwidth to some degree and cannot layout complex tables quickly). Besides loading fast is always a good thing...

BrianLy 2008-08-07 22:09:54

Answer 10

+6 A:

In my experience, the only time this really adds business value is when there is a need for 100% support for accessibility. When you have users who are visually impaired and/or use screenreaders to view your site, you need to make sure that your site is compliant to accessibility standards.

~~Users that use screenreaders will tend to have their own high-contrast, large-font stylesheet (if your site doesn't supply one itself) which makes it easy for screenreaders to parse the page.~~

When a screenreader reads a page and sees a table, it'll tell the user it's a table. Hence, if you use a table for layout, it gets very confusing because the user doesn't know that the content of the table is actually the article instead of some other tabular data. A menu should be a list or a collection of divs, not a table with menu items, again that's confusing. You should make sure that you use blockquotes, alt-tags title attributes, etc to make it more readable.

If you make your design CSS-driven, then your entire look and feel can be stripped away and replaced with a raw view which is very readable to those users. If you have inline styles, table-based layouts, etc, then you're making it harder for those users to parse your content.

While I do feel that maintenance is made easier for some things when your site is purely laid out with CSS, I don't think it's the case for all kinds of maintenance -- especially when you're dealing with cross-browser CSS, which can obviously be a nightmare.

In short, your page should describe its make-up in a standards compliant way if you want it to be accessible to said users. If you have no need/requirement and likely won't need it in the future, then don't bother wasting too much time attempting to be a CSS purist :) Use the mixture of style and layout techniques that suits you and makes your job easier.

Cheers!

[EDIT - added strikethrough to wrong or misleading parts of this answer - see comments]

OJ 2008-08-07 22:16:25

You're talking utter bollocks, old bean. "Users that use screenreaders will tend to have their own high-contrast, large-font stylesheet (if your site doesn't supply one itself) which makes it easy for screenreaders to parse the page." This is not true in any respect.

Flubba 2008-12-04 08:38:28

This is also wrong. "When a screenreader reads a page and sees a table, it'll tell the user it's a table... the user doesn't know that the content of the table is actually the article instead of some other tabular data. "

Flubba 2008-12-04 08:40:04

Screen readers typically ignore layout tables and only tell the user about data tables. Have you ever used JAWS or Window-Eyes?

Flubba 2008-12-04 08:41:03

Answer 11

+5 A:

In the real world, your chances of taking one design and totally reskinning it without touching the markup are pretty remote. It's fine for blogs and concocted demos like the csszengarden, but it's a bogus benefit on any site with a moderately complex design, really. Using a CMS is far more important.

DIVs plus CSS != semantic, either. Good HTML is well worthwhile for SEO and accessibility always, whether tables or CSS are used for layout. You get really efficient, fast web designs by combining really simple tables with some good CSS.

Table layouts can be more accessible than CSS layouts, and the reverse is also true - it depends TOTALLY on the source order of the content, and just because you avoided tables does not mean users with screen readers will automatically have a good time on your site. Layout tables are irrelevant to screen reader access provided the content makes sense when linearised, exactly the same as if you do CSS layout. Data tables are different; they are really hard to mark up properly and even then the users of screen reader software generally don't know the commands they need to use to understand the data.

Rather than agonising over using a few layout tables, you should worry that heading tags and alt text are used properly, and that form labels are properly assigned. Then you'll have a pretty good stab at real world accessibility.

This from several years experience running user testing for web accessibility, specialising in accessible site design, and from consulting for Cahoot, an online bank, on this topic for a year.

So my answer to the poster is no, there is no business reason to prefer CSS over tables. It's more elegant, more satisfying and more correct, but you as the person building it and the person that has to maintain it after you are the only two people in the world who give a rat's ass whether it's CSS or tables.

Flubba 2008-08-07 22:25:25

Answer 12

A:

When a screenreader reads a page and sees a table, it'll tell the user it's a table. Hence, if you use a table for layout, it gets very confusing because the user doesn't know that the content of the table is actually the article instead of some other tabular data

This is actually not true; screen readers like JAWS, Window Eyes and HAL ignore layout tables. They work really well at dealing with the real web.

Flubba 2008-08-07 22:28:52

Answer 13

+5 A:

One other thing I just remembered, you can assign a different stylesheet to a page for printing vs. display.

In addition to your normal stylesheet definition, you can add the following tag

<link rel="stylesheet" type="text/css" media="print" href="PrintStyle.css" />

Which will render the document according to that style when you send it to the printer. This allows you to strip out the background images, additional header/footer information and just print the raw information without creating a separate module.

Dillie-O 2008-08-07 22:29:08

Answer 14

+7 A:

@Terrapin I'd really recommend using IE conditional comments instead of CSS hacks / filters to support IE. It's supported, and it keeps your main CSS clean. Most of the CSS heavies are recommending that over using hacks now.

Example:

<link href="Style/main.css" rel="stylesheet" type="text/css" />
<!--[if lte IE 6]>
    <link type="text/css" href="Style/main-ie6.css" rel="stylesheet" />
<![endif]-->

Jon Galloway 2008-08-07 22:31:13

Answer 15

+6 A:

doing a complete revamp of a 15 page web site just by updating 1 file is heaven.

This is true. Unfortunately, having one CSS file used by 15,000 complex and widely differing pages is your worst nightmare come true. Change something - did it break a thousand pages? Who knows?

CSS is a double-edged sword on big sites like ours.

Flubba 2008-08-07 22:31:17

Answer 16

A:

   *I would let him use whatever his WYSIWYG Editor spits out

I just threw-up a little...*

ahh hello? You don't think the graphic designer is writing the CSS by hand do you?

Stephen Cox 2008-08-07 22:40:05

I'm pretty sure most graphic designers write their CSS by hand.

Jess 2009-07-21 18:46:31

Answer 17

+5 A:

If you have a public facing website, the real business case is SEO.

Accessibility is important and maintaining semantic (X)HTML is much easier than maintaining table layouts, but that #1 spot on Google will bring home the bacon.

For example: http://latimesblogs.latimes.com/readers/2008/08/colleagues-we-c.html

Monthly web report: 127 million page views for July

...

Latimes.com keeps getting better at SEO (search engine optimization), which means our stories are ranking higher in Google and other search engines. We are also performing better on sites like Digg.com. All that adds up to more exposure and more readership than ever before.

If you look at their site, they've got a pretty decent CSS layout going.

Generally, you find relatively few table layouts performing well in the SERPs these days.

Dave Ward 2008-08-07 23:22:57

Answer 18

+1 A:

@Jon Galloway

I'd really recommend using IE conditional comments instead of CSS hacks

Agreed. However, sometimes it's just easier to implement the CSS hack, especially if you want to do it for only one or two elements.

Terrapin 2008-08-07 23:29:46

Answer 19

A:

I don't think there is a business reason at all. Technical reason, maybe, even so, barely - it is a huge timesuck the world over, and then you look at it in IE and break down and weep.

Michael Neale 2008-08-08 00:25:46

Answer 20

+1 A:

*I would let him use whatever his WYSIWYG Editor spits out
I just threw-up a little...
*ahh hello? You don't think the graphic designer is writing the CSS by hand do you?

Funnily enough I have worked with a few designers and the best among them do hand-tweak their css. The guy I am thinking of actually does all of his design work as an XHTML file with a couple of CSS files and creates graphical elements on the fly as he needs them. He uses Dreamweaver but only really as a navigation tool. (I learned a lot from that guy)

Once you've made an investment to learn purely CSS-based design and have had a little experience (found out where IE sucks [to be fair it's getting better]) it ends up being faster I've found. I worked on Content Management Systems and the application rarely had to change for the designers to come up with a radically different look.

Wolfbyte 2008-08-08 01:09:44

Answer 21

+11 A:

Since this is stack**overflow**, I'll give you my programmer's answer

semantics 101

First take a look at this code and think about what's wrong here...

class car {
    int wheels = 4;
    string engine;
}

car mybike = new car();
mybike.wheels = 2;
mybike.engine = null;

The problem, of course, is that a bike is not a car. The car class is an inappropriate class for the bike instance. The code is error-free, but is semantically incorrect. It reflects poorly on the programmer.

semantics 102

Now apply this to document markup. If your document needs to present tabular data, then the appropriate tag would be <table>. If you place navigation into a table however, then you're misusing the intended purpose of the <table> element. In the second case, you're not presenting tabular data -- you're (mis)using the <table> element to achieve a presentational goal.

conclusion

Whom does this hurt? No one. Who benefits if you use semantic markup? You -- and your professional reputation. Now go and do the right thing.

Carl Camera 2008-09-16 18:31:32

Answer 22

A:

i actually can see Tables in Stack Overflow on the user page.

It even has heaps of inline styles...

2008-10-16 01:39:44

Answer 23

+1 A:

Besides being easily updatable and compliant...

I use to design all table based web sites and I was resistant at first, but little by little I moved to CSS. It did not happen overnight, but it happened and it is something you should do as well.

There have been some nights I wanted to toss my computer out the window because the style I was applying to a div was not doing what I want, but you learn from those obstacles.

As for a business, once you get to designing web sites by CSS down to a science, you can develop processes for each site and even use past web sites and just add a different header graphic, color, etc.

Also, be sure to embed/include all reusable parts of your website: header, sub-header, footer.

Once you get over the hump, it will be all down hill from there. Good luck!

Brad 2008-10-16 12:20:16

Answer 24

+4 A:

The main reason why we changed our web pages to DIV/CSS based layout was the delay in rendering table based pages.

We have a public web site, with most of its users base is in countries like India, where the internet bandwidth is still an issue (its getting improved day by day, but still not on par). In such circumstances, when we used table based layout, users had to stare at a blank page for considerably long time. Then the entire page will get displayed as a whole in a tick. By converting our pages to DIV, we managed to bring some contents to the browser almost instantly as users entered to our web site, and those contents where enough to get the users engaged till browser downloads entire contents of the page.

The major flaw with table based implementation is that, the browser we will show the content of the table only after it downloads the entire html for that table. The issue will blow out when we have a main table which wraps the entire content of the page, and when we have lots of nested tables. For the 'flexible tables' (those without any fixed width), after downloading entire table tag, browser has to parse till the last row of the table to find out the width of each columns, then has to parse it again for displaying the content. Till all these happens users has to stare at a blank screen, then everything will come to screen in a tick.

Vijesh VP 2008-10-16 13:16:56

Answer 25

A:

There definitely is. If you are still striving for it, you are not getting it right.

DIV+CSS layout is actually much easier than table layout in terms of maintainability and productivity. Just keep practicing it before it's too early to say that.

Table layout is good too it's just not meant for layouts and have exceptional drawbacks when it comes to minor tuning.

kavoir.com 2008-12-27 12:34:41

ansaurus

tags:

views:

answers:

Is there a business reason for striving for pure CSS layout?

related questions