Okay, we know there are issues with html tables and Ajax. Is there any good reason not to fake tables using CSS and nested lists? Then I could using Ajax on any row or any part of the table right? Is there some best-practice for doing this? Here is a sample of the html and css I am currently using to fake a table... <html> <head> <style type="text/css"> ul#fake_table {margin: 0; padding: 0; border: 1px solid;} ul#fake_table ul.tr {margin: 0; padding:0; position: relative; border:1 px solid black; width: 100%; height:2em;} ul#fake_table ul.tr li {margin:0; padding:0; position:absolute; display:inline; height: 100%;} ul#fake_table ul.header {text-transofrm: uppercase; font- weight:bold;} ul#fake_table ul.tr li.col_a {left:0%;} ul#fake_table ul.tr li.col_b {left:33%;} ul#fake_table ul.tr li.col_c {left:66%;} </style> </head> <body> <h1>Fake Table</h1> <ul id="fake_table"> <ul class="tr header"> <li class="col_a">a</li> <li class="col_b">b</li> <li class="col_c">c</li> </ul> <ul class="tr light"> <li class="col_a">1</li> <li class="col_b">2</li> <li class="col_c">3</li> </ul> <ul class="tr dark"> <li class="col_a">11</li> <li class="col_b">12</li> <li class="col_c">13</li> </ul> </ul> </body> </html>
Just use divs, position & style them as you like with css, like float: left.
I know this is accepted practice for layouts, but I am dealing with tabular data. Do I still want to replace them with divs? Off hand it seems to me that this would be more complex then doing it with nested lists.
We do? What are they?
I would use divs here. Your css to get the li display right is at least as abstract as anything you would have to do with the divs. My rough rule of thumb: If a specialized tag does the job, use it. Otherwise go to divs right away. They're the general template tag. If you have a list, use li but not for anything else. Another point is, the list item will limit you, what other tags you can put into them.
Thorsten Mueller wrote:
I would use divs here. Your css to get the li display right is at least as abstract as anything you would have to do with the divs. My rough rule of thumb: If a specialized tag does the job, use it. Otherwise go to divs right away. They're the general template tag. If you have a list, use li but not for anything else. Another point is, the list item will limit you, what other tags you can put into them.
I use divs for just about everything, even true tabular data. For what I do, it generally works out really well. The only thing that I've struggled with is how to handle users changing the font size in the browser. It could be that I just have a lot to learn about layouts and CSS, but my lists using divs are all pretty much fixed widths (to get the table effect). So when the font size is increased, text winds up getting cut off. I'm exploring ways to generate CSS dynamically and giving the user buttons to change the font size with instead of using browser keystrokes. It's a little more complicated, but it may work. I may be mistaken, but I believe that if I were using tables, I wouldn't have as much difficulty with font resizing.
Peace.
I use divs for just about everything, even true tabular data.
Why deliberately use non-semantic markup?
may be mistaken, but I believe that if I were using tables, I wouldn't have as much difficulty with font resizing.
...and then, worse, have to try to work around the problems created??
Garett,
Table for layout are generally considered bad but for data when data is tabular you SHOULD be using a table.
Using divs, lists or other markup will only cloud the actual meaning of the information you're presenting and depending on the browser the visitor is using you could very well render the information unusable.
Table were meant for tabular data... so if you have tabular data use them.
Btw, there are multiple tags dealing with tables which you will want to look into (I mean part the TABLE, TR and TD). look into the THEAD, TBODY, TFOOT, TH (for headings, to separate titles from data).
Jean-Marc http://m2i3.com/blog/jean-marc
Hassan Schroeder wrote:
Why deliberately use non-semantic markup?
Because I find divs easier to work with, both in the formation and implementation of a particular solution.
...and then, worse, have to try to work around the problems created??
And that is why I'm trying to rethink the path that I usually take to solve a particular problem. It may be that most of what I've done did not involve tabular data and I get into a particular pattern of using divs, then when tabular data comes along, I don't really think about what I'm going to use to display the data. I very well could be suffering from the swinging of the pendulum the other way: So many people say that it's an evil of incredible magnitude to use tables for layouts, it becomes very easy to let it swing too far the other way and not use tables at all. Some developers don't have that problem, but some do. Finding the middle ground is often a considerable struggle.
Peace.
Garett,
Table for layout are generally considered bad but for data when data is tabular you SHOULD be using a table.
Using divs, lists or other markup will only cloud the actual meaning of the information you're presenting and depending on the browser the visitor is using you could very well render the information unusable.
In particular people with screen readers/other accessibility devices.
Fred
So many people say that it's an evil of incredible magnitude to use tables for layouts, it becomes very easy to let it swing too far the other way and not use tables at all.
A bizarre over-reaction I've noticed but never understood...
Finding the middle ground is often a considerable struggle.
Not sure I understand how using appropriate semantic tags for a
given content type is a struggle 
but good luck.
I understand the difference between tables for layout and tables for tabular data, but I am also running headlong into problems with tables and AJAX. Am I just being really dense? I want to have a table where I can I replace certain parts of it (edit a row in place when you click on it, filter rows using a form that is in the first row of the table, add rows to the table through a form that is the last row of the table, etc.) To do this don't I need a bunch of divs and forms scattered through my table, which is not allowed? Garrett
If you're using input fields to filter you don't need to embed them into a form... that way you can put the fields directly into some TD`s (better... intject those directly with Javascript so they are not present on the "non-interactive" version of your page).
No. You can manipulate the DOM of your page pretty much any way you want using Javascript; it's not dependent on particular tags.
Hassan Schroeder wrote:
On Tue, Nov 4, 2008 at 8:11 AM, Phillip Koebbe
A bizarre over-reaction I've noticed but never understood...
There are a lot of bizarre overreactions in the IT world. For those of us who are not leaders but followers, it can sometimes be difficult to filter out the garbage to get down to the valuable information. If lack of time to properly try to digest something is taken into consideration, it becomes that much more difficult to find the right path.
Finding the middle ground is often a considerable struggle.
Not sure I understand how using appropriate semantic tags for a given content type is a struggle
Well, let me put it as simply as I can, though it certainly won't be a compliment to myself. Some of us aren't quite a smart as others are. There is a very long continuum of intelligence, and different people find themselves on different parts of it. While I try to understand something that you understand very easily, I just might not get it. Something you find very easy to grasp, maybe I don't. Sadly, this might be something that is truly fundamental to web development. So be it. I came to the web development party late, just a couple of years ago, after many years of developing desktop applications. Some things I can get a hold of, some things I can't. I've also got a lot going on in my life, which complicates things. Not trying to whine here, just pointing out that one person's mental capacity is not necessarily equal to another's. Plus, I am self-employed (as a contract programmer) and get paid by the hour. I don't have a lot of time to figure out the semantically correct way to do everything. I love it when I can research something while on the clock, but that is a luxury I don't often have. If I have a way that works, I use it and move on. Am I a hack? Maybe. But I've got a family to take care, so I use what works, even if not technically correct or the best way to do it.
Believe me when I say that I'm always looking out for better ways to do things. That's why I follow this forum. There is lots and lots of great information here. I recognize my weaknesses and am not afraid to change the way I do things when I find a better way. If I have time, that is.
Thanks for input, Hassan. Your comments are sometimes a bit on the abrasive side, but when taken in the proper spirit, they can definitely lead someone to give more thought to what they do.
Peace.
There are a lot of bizarre overreactions in the IT world.
So true. And I'm not trying to minimize the difficulty of keeping up with rapidly evolving technologies and best practices. I doubt there's anyone who doesn't feel that to some extent.
Plus, I am self-employed (as a contract programmer) and get paid by the hour. I don't have a lot of time to figure out the semantically correct way to do everything.
I've been an independent consultant more or less full-time since
1996. My wife hates it when I refer to myself as "self-unemployed"
Regardless, maintaining an acceptable work-life balance while also pursuing self-driven (and -financed) professional development is certainly a challenge.
Thanks for input, Hassan. Your comments are sometimes a bit on the abrasive side, but when taken in the proper spirit, they can definitely lead someone to give more thought to what they do.
Sorry, truly -- never intentionally abrasive, and thank you for the frank feedback -- but if my comments are even somewhat helpful I'm glad.
We all achieve mindfulness in our own way and at our own pace, eh?
Best,
H*