Forum Moderators: not2easy
Tableless layout, tableless forms, tableless tables maybe?
There seems to be a real battle going on with tables, what have people got against them? Why do we hate them so?
I personally find them easier to use for column layouts for example, no faux columns, no float jog, no parent's not containing floated children, why don't we use them anymore?
Oppinions?
irrationally and unconditionally hate Microsoft
No hate of MS is irrational. They have monopoly and yet still charge 200 quid for XP off the shelf? Sorry, off topic I know, had to be said though.
The problem is tabled layouts, that is to say when people abuse its purpose to achieve something it’s not meant to do
ok, seems fair enough, but proper support for DIVs still seems so buggy. Every browser seems to treat things differently (take the IE float jog for e.g.), I realise the buggyness is probably the fault of the browser developers not CSS. Were the original deigners intending us to use wrappers wrapped in wrappers? Is this the right way?
stick to tabled layouts, sure, that’s your decision
I am trying to change, hence the hundreds of posts from me about css layout! Thanks for all the help!
You'll really hate me when I tell you I'm still IFRAMEing stuff too. Hehe, that one's going out the window too.
struggled with trying to fix tabulated page layouts
It was never difficult, height=this, width=that? Doesn't work now of course as height has been depreciated although FF still honours it.
inordinate amount of time trying to do/fix the most simple things with it too
Glad I'm not alone, and fyi Suzy, Birmingham. ;)
deprecate them the way they did with useful stuff like target="blank"
Didn't know about that one either, but have used the hidden DIVs method to get around the popup blocker problem. I also found that popups designed to be a smaller window so the user didn't lose focus didn't work as of the advent of tabs.
advocates of the deprecation suggest that it can be got round with JS. What's the point of that? Why not just leave it in place?
Completely agree, if the people deciding how we should write code disagree with their own rules, what hope have we got?
So then, if TABLE layouts are the wrong way then oppinion shouldn't come into it. There is a right/wrong answer and that would appear to be it.
The problem is tabled layouts, that is to say when people abuse its purpose to achieve something it’s not meant to do.
Have to agree with that one, one of the simplest ways in which it's abused is the addition of a one celled table around the outside of another and then adding some cellpadding to the outer one just to create a border, [view source] ;)
Why spend that free time out laying around on the beach when you could be at the office managing all those divs and classes. Why skip that back 9 when you could be slaving away at home trying to manage the chaos between your multiple files and css sheets to get them to perfectly sync
Seeing as how that quote originally came from a counterpoint, I'll add my one.. ;)
"Why spend that free time out laying around on the beach when you could be at the office managing all those tables, td's and trs along with all the deprecated attributes. Why skip that back 9 when you could be slaving away at home trying to manage the chaos between your multiple scripts and markup to get the tables to perfectly sync"
I know I wouldn't be fretting over my stylesheets, even if I used tables! - because if I were to use them then my table (note not every single tr and td!) would already have a method of being uniquely identified via an ID, summary or class - so cells or indeed nested tables within that table could also be instantly identified
Of course this is said with the same confidence that I have my opinion as Mr Tabke has his :)
However I do feel sorry for the site scripter come table coder who might be having to go through multiple pages of scripts (which perhaps he didn't write?) to add opening, closing tags and attributes, and figure out the logic of the existing code's colspans - at least with CSS if the elements, tables or otherwise are uniquely identified right at the start they can be targeted by anyone no matter if they wrote the MarkUp or not!
I guess though that this again comes back to choice, going with what you know, and knowing your own code.
BDW while tables may not be deprecated some of their "previous traits", that's the abused ones then.. like auto calculating the missing row height to fill (take note Dabrowski, I didn't miss the reference ;)) are disappearing, and I feel that manipulation of tables via JS will increase in an effort to retain back compatibility that IMHO should not have existed in the first place. That, to me anyway, is worse than those that are using some JS to bridge to ever dwindling gap towards *future* compatibility with CSS. There comes a time when you have to move forward with the times..
also OT, re the target=_blank, can't you use the XHTML Transitional Doctype I thought that still validated blank.
Suzy
auto calculating the missing row height to fill (take note Dabrowski, I didn't miss the reference ;)) are disappearing
Noted. ;)
manipulation of tables via JS will increase in an effort to retain back compatibility
Agree.
have to move forward with the times
I am learning. I wrote a little 1 page thing today that has 2 divs in a wrapper, that by changing the CSS alone I can get them top to bottom or left to right either way around. Impressed?
I am still using a table for forms though, don't see a reason not to for that.
there are times when target="blank" is a real requirement. If I want to dispolay a PDF for example or a multimap or something
Yes I totally agree.
There are better ways to do it than with the deprecated "target" attribute (like using unobtrusive JavaScript).
In what way is that better? It's more difficult, more code, isn't JS disabled proof?
But that really is getting an OT discussion. Start a new thread if you really want to argue it.
I'm sticking to my guns about CSS's poor height control though. In fact, any area of unknown size I'm finding really difficult to style. If you use width/height 100% fine no problem. But add a border or some padding and it all goes to pot. We need 100% -10px!
latter part split to new thread [edited by: SuzyUK at 4:49 pm (utc) on April 19, 2007]
[webmasterworld.com...]
there are times when target="blank" is a real requirement. If I want to dispolay a PDF for example or a multimap or somethingYes I totally agree.
There are better ways to do it than with the deprecated "target" attribute (like using unobtrusive JavaScript).
In what way is that better? It's more difficult, more code, isn't JS disabled proof?
But that really is getting an OT discussion. Start a new thread if you really want to argue it.
There is so much good info here, and quite a balanced view from both sides, unlike the 'battle' that was referred to - all the opinions and extraneous links for further reading might help you decide for yourself which is best, or which is the best tool for the job at hand perhaps?
- We cannot answer all your other questions in this one thread heh..
- I too also suggest you take time to read some of the longer threads that were referred to, trust me it will be worthwhile. I think I spent my first 6 months here at WebmasterWorld simply reading.
For any question you might ask - first try a site search [webmasterworld.com] .. Yes some of the topics may be too old to reply to or even be out of date info by now - if so then feel free to refer to topics when you ask more questions
e.g. on the target=_blank question you might get more than a few results [google.com] to keep busy.
[edited by: SuzyUK at 7:09 am (utc) on April 19, 2007]
As we know, there is a strong body of opinion that says you shouldn't use tables for layout. The W3C guidelines reflect this on the grounds that using tables is poor practice for accessibility reasons.
However, we have found that using tables is vitually unavoidable if you want forms that surpass a very basic level of presentation. For example, here is an example of a form page produced by our e-forms application:
<snip>
Our experience is that screen readers cope very well with properly constructed table-based layout. (By "properly constructed" I mean that, for example, care is taken to ensure that prompts are associated with fields using the label attribute).
So what, are the real arguments against doing so?
[edited by: Robin_reala at 8:22 pm (utc) on April 19, 2007]
[edit reason] Removing URL as per TOS #13 [webmasterworld.com] [/edit]
However, we have found that using tables is vitually unavoidable if you want forms that surpass a very basic level of presentation.
Oh, that's definately not the case.
For example, here is an example of a form page produced by our e-forms application:
<snip>URLs not permitted</snip>
Your picture looks like 3 columns. But how many rows are there? If your example is a single row containing 3 columns, with each cell in the column containing all of the information for a single Referee, then yes, that will be accessible (though this layout is certainly achievable without tables). If, however, you have several rows, with each row containing a little bit of information, well, that will be a nightmare for screen readers. For example, if your code looks like this:
<tr>
<th>Referee 1</th>
<th>Referee 2</th>
<th>Referee 3</th>
</tr>
<tr>
<td><label>Name</label><input></td>
<td><label>Name</label><input></td>
<td><label>Name</label><input></td>
</tr>
<tr>
<td><label>Address</label><input></td>
<td><label>Address</label><input></td>
<td><label>Address</label><input></td>
</tr>
etc.
In that example, the order that gets presented to the screen reader will be each row at a time, which will be far less usable than if each Referee was contained within a single cell.
Our experience is that screen readers cope very well with properly constructed table-based layout. (By "properly constructed" I mean that, for example, care is taken to ensure that prompts are associated with fields using the label attribute).
Here are some resources you might find useful:
[w3.org...]
[w3.org...]
[w3.org...]
I am still using a table for forms though, don't see a reason not to for that
The way I use tables is:
#form TD { padding-right: 20px; }
#form TR:first-child { text-align: right; } /* Sometimes */<table id='form'>
<tr><td>Name</td><td><input></td></tr>
<tr><td>Phone</td><td><input></td></tr>
<tr><td>Mobile</td><td><input></td></tr>
<tr><td>Email</td><td><input></td></tr>
</table>
That way all the text boxes and labels line up nicely. I'm not sure what a 'screen reader' is but from the way you were talking I guess it shows content by stepping a line at a time through the content?
In that case this method should still work?
They are often referred to as "blind readers," but the techniques they use are close to what spiders use.
This means that a screen-reader accessible page is often very SEO friendly as well.
A blind reader scans the page, and actually uses a synthesized voice to read of the contents in sequential fashion.
<table> elements can actually be very blind reader-friendly, if you use the summary attributes, as well as things like <th> elements.
Just as an aside: I seldom use <table> elements any more for forms. However, I often use <table> elements as a central part of layout when I need to accommodate oversize content or have very strict control over page appearance. I have yet to find a non-table way to do robust borders as demonstrated in my home page.
By "robust," I mean ones that completely scale to unpredictable content.
See my thread about borders:
[webmasterworld.com...]
Nobody seemed to be able to find a decent solution to that one.
Nobody seemed to be able to find a decent solution to that one.
Mine works. I consider it a decent solution.
It's a page background with border. Width/height are 100% but unknown. Corner images are 20x20 but transparent outer edges.
Yours was top row, content, bottom row, easily achievable with divs I expect.
BTW I liked the way the links lit up coloured, might pinch that one if you don't mind. ;)
The part that requires <table> tags is the behavior of the tabs when the content stretches the template.
I wanted them to distribute evenly over the page. Open the Image Gallery to see what I mean. I picked the top and bottom because my first attempts were with <div> elements.
I tried a dozen different ways to achieve the behavior without using a table. Honestly, I really did. I would get it with FF, then hit it with Opera or IE, and it would go pear-shaped.
This is one of the frustrating things about table-less design: You may be able to achieve the same effect, but you will spend HOURS trying to get it, and even then, you might have to settle for something that doesn't work quite as well.
And the next time you try it, it won't work because there's some minor difference that just sends the CSS into a tizzy; so you have to go through it all again. CSS has a glass jaw. I've learned to keep it as simple and as generic as possible. I avoid browser-specific markup like the plague and consider !important a badge of shame and failure.
BTW: Did you take a peek at the comments in the source code?
Could you use 'float: left; width 25%;'? Would that work?
Well, since my initial answer to this post got "disappeared" almost as soon as I posted it (probably because I made a rather snide reference to the way I was treated when I was trying to solve the issue META: Aren't you guys supposed to send us an email when you scrag our postings?), I'll re-answer the question:
It was a long time ago. I can't remember exactly, but I'll bet I tried that. I remember trying everything I could, and asking for a lot of help. Nothing I tried worked, and I got sick of continually banging my head on the wall. After several days of trying to do it table-less, I gave up, and had a <table> version working within an hour.
Author Unknown -I got this off of UseNet in the Eighties or Nineties
The ToasterOnce upon a time, in a kingdom not far from here, a king summoned two of his advisors for a test. He showed them both a shiny metal box with two slots in the top, a control knob, and a lever. "What do you think this is?"
One advisor, an engineer, answered first. "It is a toaster," he said. The king asked, "How would you design an embedded computer for it?" The engineer replied, "Using a four-bit microcontroller, I would write a simple program that reads the darkness knob and quantizes its position to one of 16 shades of darkness, from snow white to coal black. The program would use that darkness level as the index to a 16-element table of initial timer values. Then it would turn on the heating elements and start the timer with the initial value selected from the table. At the end of the time delay, it would turn off the heat and pop up the toast. Come back next week, and I'll show you a working prototype."
The second advisor, a computer scientist, immediately recognized the danger of such short-sighted thinking. He said, "Toasters don't just turn bread into toast, they are also used to warm frozen waffles. What you see before you is really a breakfast food cooker. As the subjects of your kingdom become more sophisticated, they will demand more capabilities. They will need a breakfast food cooker that can also cook sausage, fry bacon, and make scrambled eggs. A toaster that only makes toast will soon be obsolete. If we don't look to the future, we will have to completely redesign the toaster in just a few years."
"With this in mind, we can formulate a more intelligent solution to the problem. First, create a class of breakfast foods. Specialize this class into subclasses: grains, pork, and poultry. The specialization process should be repeated with grains divided into toast, muffins, pancakes, and waffles; pork divided into sausage, links, and bacon; and poultry divided into scrambled eggs, hard-boiled eggs, poached eggs, fried eggs, and various omelet classes."
"The ham and cheese omelet class is worth special attention because it must inherit characteristics from the pork, dairy, and poultry classes. Thus, we see that the problem cannot be properly solved without multiple inheritance. At run time, the program must create the proper object and send a message to the object that says, 'Cook yourself.' The semantics of this message depend, of course, on the kind of object, so they have a different meaning to a piece of toast than to scrambled eggs."
"Reviewing the process so far, we see that the analysis phase has revealed that the primary requirement is to cook any kind of breakfast food. In the design phase, we have discovered some derived requirements. Specifically, we need an object-oriented language with multiple inheritance. Of course, users don't want the eggs to get cold while the bacon is frying, so concurrent processing is required, too."
"We must not forget the user interface. The lever that lowers the food lacks versatility, and the darkness knob is confusing. Users won't buy the product unless it has a user-friendly, graphical interface. When the breakfast cooker is plugged in, users should see a cowboy boot on the screen. Users click on it, and the message 'Booting UNIX v. 8.3' appears on the screen. (UNIX 8.3 should be out by the time the product gets to the market.) Users can pull down a menu and click on the foods they want to cook."
"Having made the wise decision of specifying the software first in the design phase, all that remains is to pick an adequate hardware platform for the implementation phase. An Intel 80386 with 8MB of memory, a 30MB hard disk, and a VGA monitor should be sufficient. If you select a multitasking, object oriented language that supports multiple inheritance and has a built-in GUI, writing the program will be a snap. (Imagine the difficulty we would have had if we had foolishly allowed a hardware-first design strategy to lock us into a four-bit microcontroller!)."
The king had the computer scientist thrown in the moat, and they all lived happily ever after.
The king had the computer scientist thrown in the moat, and they all lived happily ever after
Man that's funny, LMAO! It's almost as good as this one I heard the other day.....
Why are pirates called pirates?
...
...
...
...
They just "Arrrrrrrr!".
After several days of trying to do it table-less, I gave up, and had a <table> version working within an hour
Yes I have ended up doing that many times. But I really am trying to get away from it. My unobtrusive JS to fix table heights has reached 17k and still grow(n)ing.
I am getting better though, today I wrote a huge form, 22 input's in all. It used 4 nested DIVs to separate sections that only appear when some box is ticked.
Used LABEL as float left, width ..px to line the headings up nicely, and INPUT margin-right ..px to separate the following INPUT and it's side note.
Biggest CSS layout I've done I think without a table. Now I have done it, the markup does seem better, easier to read etc....
There is a really strange problem with it, but I need to strip the code and maybe start another thread.
