I have spent 3 days trying to do something that I thought would be simple and straightforward, surely less than an hour's work. I wanted to display a list of icons (small images) with a border of contrasting color around each one. Preferably there would be a small space between each image and border. I finally hit upon a coding using nested tables that ALMOST accomplishes what I wanted, and which displays the same in the 3 browsers that I tried. This is the code
I think it is regrettable that you chose to turn your answer into a broad criticism of my coding style. It took me several hours of examining those 120 lines of code before I discovered the kernel of code that made your solution work. It was the style attribute display:block That allowed the images to have the desired border. Thank you for that key idea.
I thought you might like to see the final result, all cleaned up. It is now down to just 21 lines of code, most of them short and straightforward. It produces the correct format on all 3 browsers that I tried.
First, I want to thank you for a quick and lengthy reply. I know you went to a lot of effort to show me a style of coding that you believed was modern and beneficial. I appreciate that.
I read all of the references that you gave. At first I thought they were making some solid points, and giving some good reasons to avoid tables. But after a while I realized that they were talking only about using tables for the overall layout of a webpage. If you do that, then you get the problems that they mention, slow loading, displaying poorly on small screens, and so forth.
Unfortunately, they then took those valid points and generalized them to all tables. Yet they didn't give any reasons to support that generalization. In truth, tables are a good way, often the best way, to lay out areas of a webpage into rows and columns.
I am reminded of the arguments in the 1970's against GoTo's. There were many programs written in the 1960's where GoTo's were badly overused. In many cases this was the result of poor text editors, which allowed changing lines of code, but not inserting new lines of code into the middle, and of patches made to object code, which, again did not allow for changing the size of the program being patched.
In both cases, programmers were forced to add new code at the end of a program or module, and insert GoTo's to branch to the new code, then back into the middle of the old code. This is not what the programmers wanted to do, but what they were compelled to do, given the inadequate tools they were working with. It made updating that code very difficult.
This type of over-generalization is the same mistake that people are now making about tables. If some uses of tables are bad, they say, let's avoid all tables. It almost sounds logical.
Instead, let's learn from the past and not repeat the same mistakes.
"In truth, tables are a good way, often the best way, to lay out areas of a webpage into rows and columns."
...then far be it from me to try and change your mind.
When replying to forum coding problems, though, I would be failing the
poster if I did not point out that certain methodology had moved on.
Apparently you feel there is a better way than using tables to lay out parts of a webpage in rows and columns. I'd be interested to know what you have in mind. I saw how you reformatted a list to make it horizontal instead of vertical, but I can't see how that could be better than using a table. If there were several rows, how would you get the columns to line up? By hard-coding the width of every element?
Sorry to step into this discussion, but I myself am a "self taught" coder. Most of my learning came from the table based structure of HTML coding, but recently, I am trying to get my head around CSS and a lot of the new tags. I consider myself an old"ish" head, trying to learn new ideas, so I am always open to listening to experienced coders (young and old) ... to achieve the proper results. Typically, there is no real wrong way of doing things, just diffirent approaches.