I've started a full-time gig as a "web developer," and a jack of all trades. There's another developer other than me, devoted to SQL, and a third, a consultant. Our main priority at this point is dealing with about 900 asp 3.0 pages, deleting the ones we don't need and rewriting the ones that have value in asp.net 2.0 ... and while I'm getting up to speed mode, that's what I've been focused on.

The first page is a form with a textbox / input field and a button. This is nested in three tables for some reason. So the natural thing is a div styled to look like the crazy page. After the first code review, I get an email: "Do not - I repeat, do not - get obsessed about tabling. More time is wasted on this useless topic than almost anything else I've seen in markup land."

Our policy is to validate the markup to html 4 or transitional. I suggested using strict because the company sells a product through their site, and it should work on a blackberry. The answer is that strict is impossible to achieve. And there have been a lot of other really absurd decisions and priorities made by a higher level of management. Don't use css inheritance. Delete pages, move the rest into different folder structures. And I was actually told not to take the time to use 301s in the cases where we're redirecting at all, since a 302 is one line of code instead of three or four ... if you don't just write a method in the base class.

Now, I have stock options in the company, so it's in my interest for them to do well. For more reasons than just having a continued paycheck; I'm starting to wonder if accepting this offer was the right thing to do. Anyway, my ego isn't tied up in this, but I have a really hard time doing important things the wrong way. I've been called "argumentative" in the past because in a case like this, I can't let the issue drop until whoever is making the decision at least understands the implications. And people think they're making the best choices, pounding a mediocre new site out quickly.

So can anybody give me some advice on crafting an argument from a business standpoint to doing things the right way? "My ethics prevent me from ripping you off" doesn't really work in this context, and apocalyptic scare tactics about things will crash isn't appropriate either. So how do I argue that using the proper tags the way they were meant to be used, taking advantage of css like it's 2007, and not killing the search position for all the pages we've had for years is a good business practice? The last one is easier; the company has been profitable despite all this, but how do I make a case for good markup?

One word...future-proofing. What happens when all the old code doesn't work on new browsers because new browsers render the old code obsolete?

Tabled layouts load more slowly, since they need to make two passes (one for the table and one for the content).

Tableless layouts can allow for code order rearrangement. Tabled can't.

Tableless layouts reduce code.

Those are three standalone reasons right there that should justify it. I'm sure others will suggest more, but that by itself is enough.

Mind you, what you're in sounds like the symptom of a much deeper issue...you've got yourself involved with a company suffereing from a serious case of Cranial Rectal Syndrome, and one that the regular amounts of Vaseline and a clue won't cure.

The good news is that these idiots have given you the one thing that renders you almost immune to any arguing: you're an owner. As long as you have stock, you have ownership interest and can make ownership-level decisions. This sounds like an ownership decision to me that you should be making, boss man.

Originally Posted by ADAM Web Design

Tableless layouts reduce code.

Again, and sorry, I'm in a bad mood thinking about this, but we have a page with a pretty friggen simple form. A text box and button; where this needed three nested tables is beyond me. The one-div-plus-styling version is something a temp could edit down the line, without worrying about loosing a particular td/tr tag, or a set, or breaking colspan and rowspan.

At first the orders were to keep the tables to save time rewriting everything, but since we're doing that anyway, splitting asp into "webforms" and "code-behind" it's faster to type less. Pointing this out, it came up that uniformity of code is important to us. Someone is just married to tables for regular layout.

Originally Posted by ADAM Web Design

Mind you, what you're in sounds like the symptom of a much deeper issue...you've got yourself involved with a company suffereing from a serious case of Cranial Rectal Syndrome, and one that the regular amounts of Vaseline and a clue won't cure.

Yeah, and the saving grace is it's really one individual with undue influence. And this is my second week, so it's kind of presumptive to be rocking the boat. I tend to choose my battles anyway, and not bring things up unless they're important and really do need to be dealt with.

On that note, would it be fair to say removing 90 % of the pages on the site, all of them with navigation links back into the rest of the site, just can't be done without redirects from the 404 page logic?

Originally Posted by ADAM Web Design

The good news is that these idiots have given you the one thing that renders you almost immune to any arguing: you're an owner. As long as you have stock, you have ownership interest and can make ownership-level decisions. This sounds like an ownership decision to me that you should be making, boss man.

I could have stayed at Getty... It's actually a really good job, at a catalog company that's been profitable for 20 years. They've had an old asp site forever, and we're rebuilding it from the ground up. Which means we can do things the right way, and poise for the future ... but that means we have to take the past into account, and we have to look at the present as an opportunity instead of a burden.

On that note, would it be fair to say removing 90 % of the pages on the site, all of them with navigation links back into the rest of the site, just can't be done without redirects from the 404 page logic?

It might not even be all that doable with the redirects. Why not just replace them with pages containing nothing but the redirect code to be safe?

They've had an old asp site forever, and we're rebuilding it from the ground up.

That might be part of the angle you take...if the site were working all that well, it wouldn't need a ground up rebuild. Code is a factor...all code.

I'm thinking it will still be pretty painful with redirects. But as long as we send down 301 status codes, does it matter whether it's from shelled out asp pages, or the 404 page? Or does that automatically send down a 404 response when it starts to process? I might have to use http handlers or isapi filters.

They've made the decision that all asp pages must go, either to the trash or to be resurrected in .net. There's a lot of faulty logic behind that, and people aren't realizing that adding an x to the end of your extension changes the URL. It's not the fact a lot of internal pages have better PR than any in my site, it's that suddenly all these links from the navigation that have existed for years have vanished.

Ultimately I'd rather have them using .net down the line, so it's not worth fighting over like using tables to show lists of links, so this will go through. And people are going to squeal like a pig regardless, but it seems like we need to do what we can to need less, uh, never mind.

Forrest show them this article, specifically the section Clean Code Matters. The advice comes from someone at Google who hinted that clean code might get more of your pages indexed.

Other business arguments you can try are to let them know that cleaning up the code will reduce download times keeping more people on the site.

I would think the need to display well on a Blackberry would have been enough, but it doesn't sound like it.

You can also tell them how it will make maintenance easier and less expensive in the future.

If you plan on working for this company for awhile you don't have to try to make sweeping changes all at once. Make a few small changes here or there and in time you'll have changed over the whole site.

Originally Posted by vangogh

Other business arguments you can try are to let them know that cleaning up the code will reduce download times keeping more people on the site.

I think I'm going to bring this up tomorrow. Browsers will also render valid code more quickly. Text markup is a lot slower than any kind of binary format, like SQL, so obviously less of it, like one div versus three nested tables with lots of rows and columns, means less CPU cycles to render the markup.

But ... the other question is why on Earth would anyone want to go and do it the wrong way?

the company has been profitable despite all this, but how do I make a case for good markup?

The company can still be profitable, because the world doesn't end if you use tables for layout.

And people think they're making the best choices, pounding a mediocre new site out quickly.

But ... the other question is why on Earth would anyone want to go and do it the wrong way?

For web mark-up, I take usability and development speed over rendering speed and time spent fixing CSS browser bugs. I would take a table layout that takes a fraction of the time to create and over a complete CSS design, even if I know I might have to recode the site in 2009. When IE6 and Safari 2 have a much smaller usage rate, then I will change my habits.

I am not against CSS layouts, but there are times where trade offs have to be made. (e.g. I use CSS layouts for personal projects, and table layouts at my work.)

Originally Posted by frost

The company can still be profitable, because the world doesn't end if you use tables for layout.

I can't be profitable using tables, i am absolutly pants at using them! (which as a good thing as i'm no even tempted by them)

Forrest, i think you need to clear the air with the people you work with asap otherwise both yourself and them are going to become more bitter with eachother and less open to comprimise. It obvoiusly sounds like they are blind to the modern way things work.

Originally Posted by frost

For web mark-up, I take usability and development speed over rendering speed and time spent fixing CSS browser bugs. I would take a table layout that takes a fraction of the time to create and over a complete CSS design, even if I know I might have to recode the site in 2009. When IE6 and Safari 2 have a much smaller usage rate, then I will change my habits.

<tablecellSpacing="2" cellPadding="0" width="100%" border="0">
<tbody>
<tr>
<td>
SOME TEXT HERE
</td>
</tr>
</tbody>
</table>

<div>
SOME TEXT HERE
</div>

Which method do you think offers better development speed?

Originally Posted by ForrestCroce

"Do not - I repeat, do not - get obsessed about tabling. More time is wasted on this useless topic than almost anything else I've seen in markup land."

This is frankly the most ignorant thing I've heard in a long time. I agree the world doesn't end when you use a table, but using the right markup elements is about as useless in markup as, I dunno, a parachute is to a sky diver.

Hey Forrest, you might want to peruse thru this post from 456BereaStreet and the resources he has linked there:
It's titled, appropriately enough - business case for web standards

http://www.456bereastreet.com/archiv...tandards_wiki/
You might also check out the "Why Tables for Layout is Stupid" Presentation: http://www.hotdesign.com/seybold/everything.html

Despite it's title, it does have excellent arguments and solutions as to WHY table-less is better from a business standpoint.

Just found another article ala Jeff Zeldman: http://www.businessweek.com/innovate...086_670396.htm

Here's another resource to help you - look at #2:

http://idevs.co.uk/blog/enough-with-...eb-developers/

Edit: Sorry, the anchor text is being cut of. It says "Enough With The Ignorant Web Developers."

frost I want to point out that tables aren't quicker to develop. That's only true for people who don't know css well. I know I can develop a css site much faster than I could a table site at this point.

I'd also rather spend a little more time upfront to get things right or in better shape than just throwing something out there quicker. It's not about having to change the site completely a couple of years down the road. It's making a change or adding something new in a month.

I'd also say how quickly a page downloads is more important than how long it takes to build. In the end the site has to work for your visitors. If it doesn't then all the time you spent was wasted.

Originally Posted by vangogh

frost I want to point out that tables aren't quicker to develop. That's only true for people who don't know css well.

The other side of the coin is that CSS layouts are not quicker. That is only true for people who don't know tables well.

It's not about having to change the site completely a couple of years down the road. It's making a change or adding something new in a month.

It's really not hard at all to make to make small changes with a table layout.

I'd also say how quickly a page downloads is more important than how long it takes to build. In the end the site has to work for your visitors. If it doesn't then all the time you spent was wasted.

In all programming, unless your project is not time critical, then there must always be some balance between development speed and application speed. Using CSS layouts over table layouts is just one way out of many to increase page load times. Compression, caching, and keeping scripts and stylesheets in external files (not inline) are three ways which will decrease page load times, all of which (in most cases) have a greater effect than using CSS layouts over table layouts.

I was actually under the impression that CSS layouts took more effort and time than table layouts. I generally run across several browser bugs, especially when making fluid layouts with multiple columns. If you can consistently create css layouts, both complicated and simple, quicker than table layouts, then by all means, go ahead and only do css layouts.

Originally Posted by frost

The company can still be profitable, because the world doesn't end if you use tables for layout.

Right, and to think otherwise would be alarmist. But when tables for layout is only one of the issues - but the one that's appropriate in this forum - there's room to be a lot more profitable if we fix all of what's wrong.

And, honestly, in a non-tech company that depends heavily on their web site or application, one div is a lot cheaper than three nested tables, for an asp.net form; changes to the appearance of course are made in one file and apply instantly across the site, but when you have to make tag-level changes, a wider range of people are able to make the needed changes, in less time.

Originally Posted by frost

The other side of the coin is that CSS layouts are not quicker. That is only true for people who don't know tables well.

That's not factually true; everybody who knows html knows tables for layout well. It was the only method for years. It's only recently that some of us have moved on to better suited layout mechanisms.

Originally Posted by frost

Using CSS layouts over table layouts is just one way out of many to increase page load times. Compression, caching, and keeping scripts and stylesheets in external files (not inline) are three ways which will decrease page load times, all of which (in most cases) have a greater effect than using CSS layouts over table layouts.

Now this is factually true, but you have to look at the bigger picture. Compression is part of the transfer protocol, caching is implemented in the browser - and in server based apps pretty flexible and easy to use. Most people keep their js and css in external files already, because it lets you make changes in one place instead of making a huge job out of it, makes your pages smaller, and lets the browser cache your site more efficiently.

So while these things can add up to more difference than an entire table layout, everybody's already using them.

frost most everyone I know who knows both tables and css will opt for css on every project. It's not harder than tables once you know how and it isn't nearly as hard to learn how as most people think.

I agree there are other ways to get a site to download quickly and there are time constraints, but css doesn't take longer to develop so why use tables. CSS does make things easier to change later. If you're talking about one change to one page then it doesn't make much difference, but when you're talking site wide changes css is far and away easier.

CSS is also more flexible in what you can do with it.

The other side of the coin is that CSS layouts are not quicker. That is only true for people who don't know tables well.

I too must differ on this. I've been building websites for 10+ years and I spent YEARS building with tables, so I DO know them. Now I would never go back to using tables for layout. CSS is so much better, much more flexible and, like Vangogh, I can whip up a CSS-based site pretty darn quick these days, and my sites use very few hacks for cross-browser compatibility too. Once you know what the bugs are and how to beat them, it's not all that hard to code to keep them out of your pages.

One of the biggest problems with tables for layout that I see is the massive maintenance time. I maintain a pretty large intranet site, over 10k pages, all table-less. To make a site-wide or section change I only need to edit the css file. When the site was all tables (3 years ago), it would take far more time to pick thru the code of EVERY page affected to make changes.

I maintain over 60 sites for my company - I'd have to hire a person full time for changes if they were all tables-based ! Today I had to change out the header for an entire site - all I had to do was plop in the new jpg and the entire site was changed w/o changing a single line of code in a page or, in this case, the css file.