#Nested Tables Aren't Necessarily Bad There are things you can do with nested tables that you can't with CSS and <div>s, especially with regard to re-sizable width layouts. Tables may be old fashioned, but they are more versatile and work equally well on every browser. I personally prefer CSS where it works equally well on every browser and use tables where it doesn't. More than 3 levels of nested tables is almost always unnecessary.

#Tables Aren't Slow Have you looked at the timings in the developer console of a browser to find out what is causing it to be slow? If you don't identify the cause of the slowness, you aren't going to be able to fix it. I think I've seen layout issues slow down a web site's display 1% of the time. The other 99% of the time it is waiting for the server or the network - most often to download images.

#Technology Doesn't Matter This is not a customer-facing site. If the site displays well-enough on everyone's browser, the only person who will care about the technology behind it is you. Your boss's goal, I'm sure, is that you keep it functional and spend as little time on it as possible.

Clean up each page you have to change for a business reason to meet the most basic standards you can stomach and leave the rest. For me, that means making pages validate cross-browser Xhtml 4.0 transitional with Quirks-mode properly disabled (using the special doctype/html-tag combination) for IE. Why do I tilt at that particular windmill? Because I don't like surprises. When a new version of a browser comes out I don't want to have to run and fix the site. The HTML Validator plug-in for Firefox is great for this.

If you can do a little something to make yourself more productive in the future and/or make the html valid over time, do it. Otherwise, start a manifesto of what changes the site needs and plan to make those changes another time. As your manifesto grows, it will help you remember all the issues, identify your most serious pain points, and keep you focused on the low-hanging fruit that will actually make a difference to the people who use the site. And what will make a difference to your boss is how quickly you can say, "OK, next project."

If this were customer facing, if it were production code, I would give you very different advice - care is critical there. But not here.

Nested Tables Aren't Necessarily Bad

There are things you can do with nested tables that you can't with CSS and <div>s, especially with regard to re-sizable width layouts. Tables may be old fashioned, but they are more versatile and work equally well on every browser. I personally prefer CSS where it works equally well on every browser and use tables where it doesn't. More than 3 levels of nested tables is almost always unnecessary.

Tables Aren't Slow

Have you looked at the timings in the developer console of a browser to find out what is causing it to be slow? If you don't identify the cause of the slowness, you aren't going to be able to fix it. I think I've seen layout issues slow down a web site's display 1% of the time. The other 99% of the time it is waiting for the server or the network - most often to download images.

Technology Doesn't Matter

This is not a customer-facing site. If the site displays well-enough on everyone's browser, the only person who will care about the technology behind it is you. Your boss's goal, I'm sure, is that you keep it functional and spend as little time on it as possible.

Clean up each page you have to change for a business reason to meet the most basic standards you can stomach and leave the rest. For me, that means making pages validate cross-browser Xhtml 4.0 transitional with Quirks-mode properly disabled (using the special doctype/html-tag combination) for IE. Why do I tilt at that particular windmill? Because I don't like surprises. When a new version of a browser comes out I don't want to have to run and fix the site. The HTML Validator plug-in for Firefox is great for this.

If you can do a little something to make yourself more productive in the future and/or make the html valid over time, do it. Otherwise, start a manifesto of what changes the site needs and plan to make those changes another time. As your manifesto grows, it will help you remember all the issues, identify your most serious pain points, and keep you focused on the low-hanging fruit that will actually make a difference to the people who use the site. And what will make a difference to your boss is how quickly you can say, "OK, next project."

If this were customer facing, if it were production code, I would give you very different advice - care is critical there. But not here.

#Nested Tables Aren't Necessarily Bad There are things you can do with nested tables that you can't with CSS and <div>s, especially with regard to re-sizable width layouts. Tables may be old fashioned, but they are more versatile and work equally well on every browser. I personally prefer CSS where it works equally well on every browser and use tables where it doesn't. More than 3 levels of nested tables is almost always unnecessary.

#Tables Aren't Slow Have you looked at the timings in the developer console of a browser to find out what is causing it to be slow? If you don't identify the cause of the slowness, you aren't going to be able to fix it. I think I've seen layout issues slow down a web site's display 1% of the time. The other 99% of the time it is waiting for the server or the network - most often to download images.

#Technology Doesn't Matter This is not a customer-facing site. If the site displays well-enough on everyone's browser, the only person who will care about the technology behind it is you. Your boss's goal, I'm sure, is that you keep it functional and spend as little time on it as possible.

Clean up each page you have to change for a business reason to meet the most basic standards you can stomach and leave the rest. For me, that means making pages validate cross-browser Xhtml 4.0 transitional with Quirks-mode for IE. Why do I tilt at that particular windmill? Because I don't like surprises. When a new version of a browser comes out I don't want to have to run and fix the site. The HTML Validator plug-in for Firefox is great for this.

If you can do a little something to make yourself more productive in the future and/or make the html valid over time, do it. Otherwise, start a manifesto of what changes the site needs and plan to make those changes another time. As your manifesto grows, it will help you remember all the issues, identify your most serious pain points, and keep you focused on the low-hanging fruit that will actually make a difference to the people who use the site. And what will make a difference to your boss is how quickly you can say, "OK, next project."

If this were customer facing, if it were production code, I would give you very different advice - care is critical there. But not here.

#Nested Tables Aren't Necessarily Bad There are things you can do with nested tables that you can't with CSS and <div>s, especially with regard to re-sizable width layouts. Tables may be old fashioned, but they are more versatile and work equally well on every browser. I personally prefer CSS where it works equally well on every browser and use tables where it doesn't. More than 3 levels of nested tables is almost always unnecessary.

#Tables Aren't Slow Have you looked at the timings in the developer console of a browser to find out what is causing it to be slow? If you don't identify the cause of the slowness, you aren't going to be able to fix it. I think I've seen layout issues slow down a web site's display 1% of the time. The other 99% of the time it is waiting for the server or the network - most often to download images.

#Technology Doesn't Matter This is not a customer-facing site. If the site displays well-enough on everyone's browser, the only person who will care about the technology behind it is you. Your boss's goal, I'm sure, is that you keep it functional and spend as little time on it as possible.

Clean up each page you have to change for a business reason to meet the most basic standards you can stomach and leave the rest. For me, that means making pages validate cross-browser Xhtml 4.0 transitional with Quirks-mode properly disabled (using the special doctype/html-tag combination) for IE. Why do I tilt at that particular windmill? Because I don't like surprises. When a new version of a browser comes out I don't want to have to run and fix the site. The HTML Validator plug-in for Firefox is great for this.

If you can do a little something to make yourself more productive in the future and/or make the html valid over time, do it. Otherwise, start a manifesto of what changes the site needs and plan to make those changes another time. As your manifesto grows, it will help you remember all the issues, identify your most serious pain points, and keep you focused on the low-hanging fruit that will actually make a difference to the people who use the site. And what will make a difference to your boss is how quickly you can say, "OK, next project."

If this were customer facing, if it were production code, I would give you very different advice - care is critical there. But not here.

#Nested Tables Aren't Necessarily Bad There are things you can do with nested tables that you can't with CSS and <div>s, especially with regard to re-sizable width layouts. Tables may be old fashioned, but they are more versatile and work equally well on every browser. I personally prefer CSS where it works equally well on every browser and use tables where it doesn't. More than 3 levels of nested tables is almost always unnecessary.

#Tables Aren't Slow Have you looked at the timings in the developer console of a browser to find out what is causing it to be slow? If you don't identify the cause of the slowness, you aren't going to be able to fix it. I think I've seen layout issues slow down a web site's display 1% of the time. The other 99% of the time it is waiting for the server or the network - most often to download images.

#Technology Doesn't Matter This is not a customer-facing site. If the site displays well-enough on everyone's browser, the only person who will care about the technology behind it is you. Your boss's goal, I'm sure, is that you keep it functional and spend as little time on it as possible.

Clean up each page you have to change for a business reason to meet the most basic standards you can stomach and leave the rest. For me, that means making pages validate cross-browser Xhtml 4.0 transitional with Quirks-mode for IE. Why do I tilt at that particular windmill? Because I don't like surprises and when a new version of a browser comes out I don't have to run and fix the site. The HTML Validator plug-in for Firefox is great for this.

If you can do a little something to make yourself more productive in the future and/or make the html valid over time, do it. Otherwise, start a manifesto of what changes the site needs and plan to make those changes another time. As your manifesto grows, it will help you remember all the issues and identify your most serious pain points and keep you focused on the low-hanging fruit that will actually make a difference to the people who use the site. And what will make a difference to your boss is how quickly you can say, "OK, next project."

If this were customer facing, if it were production code, I would give you very different advice - care is critical there. But not here.

#Nested Tables Aren't Necessarily Bad There are things you can do with nested tables that you can't with CSS and <div>s, especially with regard to re-sizable width layouts. Tables may be old fashioned, but they are more versatile and work equally well on every browser. I personally prefer CSS where it works equally well on every browser and use tables where it doesn't. More than 3 levels of nested tables is almost always unnecessary.

#Tables Aren't Slow Have you looked at the timings in the developer console of a browser to find out what is causing it to be slow? If you don't identify the cause of the slowness, you aren't going to be able to fix it. I think I've seen layout issues slow down a web site's display 1% of the time. The other 99% of the time it is waiting for the server or the network - most often to download images.

#Technology Doesn't Matter This is not a customer-facing site. If the site displays well-enough on everyone's browser, the only person who will care about the technology behind it is you. Your boss's goal, I'm sure, is that you keep it functional and spend as little time on it as possible.

Clean up each page you have to change for a business reason to meet the most basic standards you can stomach and leave the rest. For me, that means making pages validate cross-browser Xhtml 4.0 transitional with Quirks-mode for IE. Why do I tilt at that particular windmill? Because I don't like surprises. When a new version of a browser comes out I don't want to have to run and fix the site. The HTML Validator plug-in for Firefox is great for this.

If you can do a little something to make yourself more productive in the future and/or make the html valid over time, do it. Otherwise, start a manifesto of what changes the site needs and plan to make those changes another time. As your manifesto grows, it will help you remember all the issues, identify your most serious pain points, and keep you focused on the low-hanging fruit that will actually make a difference to the people who use the site. And what will make a difference to your boss is how quickly you can say, "OK, next project."

If this were customer facing, if it were production code, I would give you very different advice - care is critical there. But not here.