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?
(Well it would take me three days) ;)
Could you really move a menu bar left to right as simply as changing float: left to float: right? Or even left to top? Without changing any markup?
What difference does it make if you have to change CSS or markup? Aren't they both eaqually important in creating the page?
The problem with using tables for layout is that you're embedding presentation into your content. One of the main benefits of CSS is that you can pull all of the presentation out of the markup, so if you later decide to change your presentation, you only need to modify the CSS.
Example:
<body>
<h1>title</h1>
text
</body>
If you want h1 to be centered (the h1 tag in its container, not its content) with a border and a padding and only using the width necessary for the content (whose size we don't know ; could be 100px or 500px), there no way to do it by applying style to only one tag.
like this
¦ · · · · · · · · · · · · · · · · · · · · ¦
¦ · · · · · · · · --------- · · · · · · · ¦
¦ · · · · · · · · ¦ title ¦ · · · · · · · ¦
¦ · · · · · · · · --------- · · · · · · · ¦
¦ · · · · · · · · · · · · · · · · · · · · ¦
¦text · · · · · · · · · · · · · · · · · · ¦
To achieve this you have to add a div around h1.
Could you really move a menu bar left to right as simply as changing float: left to float: right? Or even left to top? Without changing any markup?
[csszengarden.com...]
Hundreds of different presentations all based on the same markup. Need I say more?
What difference does it make if you have to change CSS or markup? Aren't they both eaqually important in creating the page?
They definately are NOT equally important! Content should always be the most important part of the page. But as far as why it makes a difference...
If you are the only developer and you have resigned yourself to the fact that you will always be maintaining both the content and presentation of the site, and you don't care whether you need to modify the markup and/or the CSS in order to change the presentation, then there's nothing necessarily *wrong* with that. Your CSS skills may not get as strong as they could and you probably won't focus as much on creating semantic markup, but you will have a site that's easy for you to maintain.
However, if you work as part of a team, or you can't be sure that you will always be the sole administrator, then you might have 2 guys delivering pure content and another working on the presentation only. Or perhaps you work on some sort of web application where you might not have control of all the content. In these cases, being able to change the presentation by only tweaking the CSS makes sense.
@Achernar
Yes, there is some pre-planning required to ensure you have enough wrapper elements. The difference being that I can wrap an element with a generic wrapper like a div and do almost anything to it. But if I wrap it in a table column, I'm limited in what I can do.
[edit]<snip>
Misunderstood.
[/edit]
[edited by: Fotiman at 6:59 pm (utc) on April 17, 2007]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset:utf-8">
<title></title>
<style type="text/css">
h1 {
display: table;
margin: 0 auto;
padding: 1em;
border: 1px solid #000;
width: auto;
}
</style>
</head>
<body>
<h1>title</h1>
text
</body>
</html>
[edited by: Fotiman at 7:11 pm (utc) on April 17, 2007]
http://www.csszengarden.comHundreds of different presentations all based on the same markup. Need I say more?
Yes, but buying Jimi Hendrix sheet music does not allow me to play guitar like him. ;)
Anyone?
EVERY time I've ever updated any of my sites, I've altered the markup as well as the CSS.
And ya know what? It was a durn site[sic] easier to tweak the markup than the CSS. I dread having to change the CSS. CSS has a glass jaw, and I need to test my styles against at least ten different browsers.
CSS design is HARD. Very, VERY hard. I'm pretty good with CSS, and I can easily spend more time tweaking my CSS than I would just writing a PHP file to spit out fixed markup with inline styles.
I am also learning to write XSLT. You think CSS is hard? XSLT makes CSS tweaking look like a stroll through Disneyland, and CSS tweaking makes HTML tweaking look like a ride through Magic Mountain.
It ALWAYS comes down to what are you good at doing, how much will it cost to learn a new way, will you be able to fix it, and whether or not the techniques you are studying were provided by real, industrial Web designers who do this in batches of thousands, or if they are being promoted by academics who demonstrate 100-line code snippets and have a book to sell.
Simple dollars-and-cents cost/benefit analysis.
All that being said, I am learning most modern design techniques (and a lot more), but at my own speed; not because some pundit says I'm "less than" for not drinking their Kool-Aid. I do Web sites upon which lives can depend, and won't use my clients as guinea pigs.
Oh yeah, just an aside: Most of the people who are currently preaching the evils of <table> design are also preaching that we mutate <ul>, <ol> and <dl> tags to things like tabbed navigation.
The original intent (so that there is some usable degrading) has long since dissolved into the mists of time, and hitting some of these sites with Lynx is painful as all git-go.
In some amount of time, someone will start preaching the evils of mutated lists, and the industry will abandon them wholesale; just as they are now doing for <table> elements.
Also, one of the arguments for using block elements, as opposed to tables, is that you can "reflow" a page in order to provide radically different content to people, with, say cellphones.
You REALLY don't want to do that, because of download times and costs. I use XSLT to reduce the pages at the server for cellphones. It is a very bad thing to send 100KB of markup and style to someone's phone, then hide 3/4 of it.
In any case, very, very few block-based sites I've seen would survive even a moderate reflow.
[edited by: SuzyUK at 8:37 pm (utc) on April 18, 2007]
[edit reason] chirrups not needed, it's all in thread [/edit]
Oh yeah, just an aside: Most of the people who are currently preaching the evils of <table> design are also preaching that we mutate <ul>, <ol> and <dl> tags to things like tabbed navigation.
Uh... I think you are mistaken. The general argument is probably not that all <ul> elements are "mutated" to things like tabbed navigation, but rather that your navigation links are a "list of links". Thus, it would make sense to wrap them in <ul> containers.
The original intent (so that there is some usable degrading) has long since dissolved into the mists of time, and hitting some of these sites with Lynx is painful as all git-go.
As you said cmarshall, this is coming from a ‘real industrial Web designer’, and for us it was a ‘simple dollars-and-cents cost/benefit analysis’ (well, pounds-and-pennies).
http://www.csszengarden.comHundreds of different presentations all based on the same markup. Need I say more?
Yes, but buying Jimi Hendrix sheet music does not allow me to play guitar like him.
I suppose not but you don't tell him that because you can't do it like him, it can't be done, I presume ;) .. and yes I wish I could play the Clarinet like Aker Bilk too!
Anyone ever update their site using only CSS?
if you ever want to progress with not just CSS but CSS&P (CSS & CSS Postioning) - I'd like to see you using positioning within a table ;) - You know that bit when someone says 'how'd they do that?' it's not quite so easy when you have to say dump the table and learn to walk before running
aside from that I've no objection and certainly nothing approaching 'hate' for tables they are an abused and misunderstood element, you can use them if it suits, if you know php or tables better then good on you, as per Fotiman's post #msg3313735)
and just for the record I completely disagree with what cmarshall says about lists and tabbed menus, turn OFF CSS and tell me the 'tabbed menu' still doesn't make sense if marked up as a list (indented text still matches the 'drops'?) it's ALL in the markup!
a navigation menu is nothing more than a list of choices
Suzy
ooops sorry if cross posting is out of sync here - I started the post half hour ago!
[edited by: SuzyUK at 8:26 pm (utc) on April 17, 2007]
As you said cmarshall, this is coming from a ‘real industrial Web designer’, and for us it was a ‘simple dollars-and-cents cost/benefit analysis’ (well, pounds-and-pennies).
That's what we need more of. There's always way too much abstract and idealistic language used in these threads. Drives me batty (actually, it's not much of a drive. More of a short putt).
I know about shared templates. I use them all the time. But I usually tweak the markup as well. It costs a great deal more to test CSS than markup.
Thanks for the real-world, practical sharing.
most people don't worry about mobiles though. but what about printing pages? how do you get rid of the columns filled with navigation in a table layout?
of course you could make it invisible so it doesn't print out, but with CSS you can remove it completely so they only have to print out the content - looks much better.
table designs tend to break a lot easier when people change the font size too.
CSS is better for SEO because there's less code compared to text, and you can move the content to the top of the document. (i know there are ways you can do that with tables too, but its not as easy as with CSS)
its also better for accessibility as well. screen readers will read the code from top to bottom of the document, whereas table layouts can sometimes take it out of order.
and the best thing of all... you can give your site a major redesign by amending a single document.
you can't do that if you use tables on every page. (...unless you use a templating system of course, but that wouldn't be much good for my argument!)
h1 {
display: table;
...
I have other examples of things that can't be done with CSS, but can be with tables (or other tags). Nevertheless, I like CSS (when it saves time) but I still use tables a lot.
I have other examples of things that can't be done with CSS
Your example explicitly stated that it couldn't be done with CSS affecting only that single element (the h1). The same can be said of regular markup though. You couldn't achieve the same layout with pure markup either unless you added depreciated elements to your page.
Note, your desired layout *could* still be achieved with CSS if you put some proper planning into the design that was flexible enough to be expandable. For example, an additional wrapper element surrounding the h1 or contained within the h1 is not such a bad thing, and with that you could achieve the layout you were looking for using CSS.
Look at this wonderful, impassioned dialogue (I am not being facetious. This is what makes WebmasterWorld so kewl).
Now, I have kicked anthills at the XML [webmasterworld.com] and the Accessibility [webmasterworld.com] forums without so much as a peep.
Accessibility is important. I have a stake in this, as I design sites for disadvantaged people, many of whom are disabled and running sub-par equipment. I'm not trying to sell them anything or rank high in an SRP, but the sites I make can have a significant impact on their lives.
XML is kinda high "geek factor," but that community is nowhere near as interested in helping each other (or arguing with each other) the way we are here.
I wish we could have some of these mile-long threads we see on these forums, on those forums as well.
its also better for accessibility as well. screen readers will read the code from top to bottom of the document, whereas table layouts can sometimes take it out of order
Top to bottom, left to right?
Fotiman I've seen the Zen Garden before, can't even begin to decode it but....the CSS is actually bigger than the markup. Also the DIVs are nested 5x. I feel this demonstrates the fact that DIVs aren't controllable enough without wrappers in wrappers.
That aside, I'm so rubbish with CSS layouts, somebody please tell me why these DIVs aren't next to each other:
/* I believe this is needed to prevent the IE float gap */
#wrapper { width: 100%; height: 100%; overflow: auto; }.left { height: 100%; }
.right { float: right; width: 150px; height: 100%; }DIV { border: 1px solid red; } /* just so you can see them */
<div id='wrapper'>
<div class='right'>Stuff</div>
<div class='left'>Other stuff</div>
</div>
My right is on the right, full height and 150px wide, my left however is full height but only as wide as the content, doesn't expand to the floated right.
Normally I would use a table for the columns but I am trying to update my skills. How would you guys tackle this.
interested in helping each other (or arguing with each other)
cmarshall I started this thread with intent that members share their oppinions on each method. No argument intended!
Fotiman I've seen the Zen Garden before, can't even begin to decode it but....the CSS is actually bigger than the markup.
For some of the layouts, I'm sure this is the case (but not all). Also, it may not seem like it, but that could actually be a good thing. Why? The CSS will get cached in the browser, so it's only (for the most part) a 1 time hit. This keeps your content clean and lean... good for accessiblity... good for SEO.
Also the DIVs are nested 5x.
Not that I could see. I saw at most 4 levels of div, but in most of these cases they were all clearly given some level of pseudo-semantic meaning via id attributes. For example:
intro
... pageHeader
... quickSummary
... preamble
supportingText
... explanation
... participation
... benefits
... requirements
... footer
Those are nice, semantic blocks of information. It's easy to see each block of information, and also quite easy to style it. The markup remains pure, semantic, and accessible. Whereas if these were in a table, the lines between each "block" becomes blurred because you now have to search across columns and rows.
I have other examples of things that can't be done with CSSIt should be noted that "can't be done with CSS" is not entirely accurate.
I have two types of image galeries, one completely in CSS, with float and fixed size divs, and one with table.
The one with table solves a problem for which I haven't found a solution with CSS :
Each image in the galery is contained in a cell with a fixed width (so far, no problem) and a adaptative height (based on the tallest image in the row), each image has a comment beneath it (in fact in a cell in the following row) whose height varies too.
Constraints:
1. I don't want to set a height to either the image cell or the comment cell (It's impossible to I know what will be the tallest value that I will encounter).
2. I want all cells in a row to have the same size.
3. I don't want cell to occupy more space than needed by its content (or the tallest content in the row).
I saw at most 4 levels of div
Sorry, must have miscounted. But 4 levels of markup? I thought your whol argument earler was about reducing markup to the bare minimum. You have missed the outer container div out of your brief summary, so I put this to you:
<tr intro>
...<td> pageHeader </td>
...<td> quickSummary </td>
...<td> preamble </td>
<tr supportingText>
...<td> explanation </td>
...<td> participation </td>
...<td> benefits </td>
...<td> requirements </td>
...<td> footer </td>
ok this doesn't account for positioning, but some creative col/row spans could mimic floated left and rights. As for the markup being hard to read, no harder than <div something><p something><span something> and that's before you even have any text!
Also this page has been designed specifically to show off CSS layout, and hence would be difficult to recreate with a table. But I could do a site that would be eaqually as difficult to recreate with pure CSS. Sorry Suzy but I'm going to make the point about remaining heights here.
The thread I started about a border with rounded edges, on an unknown size. Archenar's example is also good. It would take far more markup to achieve this with CSS than a table.
I've seen the Zen Garden before, can't even begin to decode it but....the CSS is actually bigger than the markup. Also the DIVs are nested 5x. I feel this demonstrates the fact that DIVs aren't controllable enough without wrappers in wrappers.
I ;) 'feel this demonstrates the fact that' you might not understand that a table is nothing more than a series of nested wrapper elements - A <div> is an HTML element as is a <table>, <tr>, <thead>, <th>, <tbody> and <td>, <tfoot> and <caption> - and that the elements set within a table structure are even less "controllable" than a div
here ya go - and yes I'm taking a little liberty (until an admin comes along probably :o) - take at look at
this graphical representation [stuffandnonsense.co.uk] of the Zen Garden's HTML mark-up to see if that's any easier to visualise a page structure - and then tell me it could marked up with less code (elements not bytes, the class names could be shortened if it were worth it ;)) than a table if it were to be done properly and with enough foresight to make hundreds of different layouts
and let me give you a start.. (body doesn't count as it's there for both)
that first bit
<div id="container">
<div id="intro">
<div id="pageHeader">
<h1><span>
<h2><span>
4th nest is h1, and 4th nest is h2, at this point you can display them above/below each other or you can display them beside each other, with no more markup, the span is optional and will allow you to apply background images, rounded corners or "shrink wrapped" borders as Achernar reffered to earlier
now same code with a table
<table>
<thead>
<tr>
<th><h1><span>
..<tr> or <th>?
5th nest is h1 a span might still be desired to provide shrink wrapped effect on headers, however at this point you now have to *know* whether you want the h1 and the h2 above/below or side by side with each other - in order to continue with the table markup, col spans new <tr>'s etc.. and this is where unless you are a one man band responsible only for your own code, the 'split thinking' occurs - it is so not about Tables v CSS but instead about future flexibility. AND this is from a PHP/Perl/ASP coders point of view - not just the end template designer!
a <div> is a generic element for a page DIVision a <tr> is a row of table and a <td> is a data cell within a table (tabular data)
The CSS garden markup was never meant to be perfect it was about being as flexible as possible for its purpose, I think it demonstrates that and more! and to it's credit those extra spans (even clearing divs which are nearly redundant!) - or CSS hooks as we call them now appear and more in most major CMS's MarkUp these days, and because of them the donated template designs keep growing!
enough from me already :)
Suzy
sorry edited for sp and grammar, it's late
[edited by: SuzyUK at 11:38 pm (utc) on April 17, 2007]
Myself: Also this page has been designed specifically to show off CSS layout
I think DIVs are great for width/horizontal stuff, but I like the way a TABLE acts as a group. You can set the height on a TABLE and know the TR's will fill it.
What I would like to see in CSS3 is some sort of grouping tag, so you could have
<divgroup height='100%'>
<div>Stuff</div>
<div>Nonsense</div>
<div>Foo Yung</div>
</divgroup>
Something like that so you know all 3 divs would take up the space. I find it difficult working with unknown sizes. ok left, right, top and bottom are easy enough, but how big is the bit in the middle?
I have yet to run into a case where CSS is better than standard rock solid tables. There are just too many incompatability issues to deal with yet to consider tabless[sic]. Unless you don't care about your visitors..... 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 ;-)
An endless argument, Ford vs. Chevy, Losi vs. Associated, you probably have bigger battles to fight - choose your ground and stand on it.
Tableless layout, tableless forms, tableless tables maybe?
No, tables should always be tabled, not tableless.
There seems to be a real battle going on with tables, what have people got against them? Why do we hate them so?
Some people irrationally and unconditionally hate tables, just as they might irrationally and unconditionally hate Microsoft, but that doesn’t mean they’re right in doing so. Often learners get told “Tables are bad. Don’t ever use them!” and they would be incorrect in listening to that. Tables aren’t bad, it’s only people’s misuse of them that is bad. It’s when tables get used for things other than tabular data (such as making a three-column layout,) that’s when it’s wrong.
I believe SuzyUK has already mentioned something to this effect, and I suppose it’s only after a while one comes to understand that a table is for easily presenting a logical structure of tabulated data.
The problem is tabled layouts, that is to say when people abuse its purpose to achieve something it’s not meant to do.
This runs into problems when trying to “port” the content to a different medium, where CSS-Presentation gives you a much greater amount of flexibility: can your tabled layout print just fine without cutting off that third column? Can it be viewed as plain text for those Blackberrys (Blackberries? :D) or what about how deep a search engine crawley has to get before it hits the rich vein of content?
This discussion pops up every once in a while, and it never ends in a clear-cut answer, never is finalised, because unfortunately a small part of the decision regarding “Should I use tables for layout? Or use CSS?” factors in opinion. My opinion is that CSS is superior in customisability of viewing the same content over different mediums (does anybody remember the days of old where we used to have to create a whole different table layout for “printer friendly” buttons? I had a field day when I realised I could just go…
media="print"I also am of the opinion that if you want to learn how to do this, cool, ask away and we’ll answer. That if you would rather stick to tabled layouts, sure, that’s your decision, have fun with that :)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset:utf-8">
<title></title>
<style type="text/css">
h1 {
display: inline;
text-align:center;
border: 1px solid #000;
}
body{text-align:center}
p{text-align:left}
</style>
</head>
<body>
<h1>title</h1>
<p>text</p>
</body>
</html>
Whatever the solution is with using tables is, I wouldn't think it'd be as clean as this.
The three main problems I have with tables:
- It's not very acessible. (as somone mentioned already). They don't have good compatibility with screen readers, font resizing, or very high/low resolutions.
-It's more code. All those cell tags add soo much code to the document. It's oftentimes hard for me to keep track of the nesting and theoretical position of elements on the page (okay let me count... this middle-left content section should be 1, 2, 3, 4 ,5 columns down, <td></td><td></td><td></td>... okay where's where I go.). Unless you're using advanced html editors which automatically show code in a properly indented fashion, it's annoying to manually edit the nesting tabs all the time.
-DHTML... good luck moving any content sections dynamically using tables. With divs, it's easy for a user to create their own layout with DHTML. User action is not the only situation for DHTML though, scripts and such for all sorts of content which changes dynamically could be done... photo galleries... smart ads, etc.
These are three serious problems for me, perhaps the second point isn't a problem for some though. Personally I really can't get around tables well unless they contain normal data (the normal use for tables). I was using WYSIWYG editors to work with tables, back when CSS support was lowsy, and of course that wasn't fun either, because I didn't care for those editors much either.
As many of us already know CSS can also be a nightmare. I am just dipping my toe in the water and I find that I can spend an inordinate amount of time trying to do/fix the most simple things with it too.
BTW SuzyUK I am in Scotland if you are offering any classes ;)
Regarding the condemnation of tables, I get concerned that they will deprecate them the way they did with useful stuff like target="blank". I don't need anyone to tell me what is good for my clients. I am doing an XHTML website right now and on one page it requires that instructions are displayed on a separate window or page. If I do this the code will not validate.
I did some searching around for a solution and even the 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?
[edited by: BeeDeeDubbleU at 9:20 am (utc) on April 18, 2007]
Regarding your target="_blank" complaint, popup windows are bad for both accessibility and usability. They're bad for accessibility because the user is suddenly taken to a new window with no warning and no idea what's happened to the original content. It's up to them to figure out what's happened. They're bad for usability because the content is not being associated with the original site, and the popup window can get lost among others.
A better solution is to use hidden divs that show as and when they're useful. Users without stylesheets get contextual information before their options, and users with them don't have to worry about popup blockers and losing the extra windows.
Anyway, this is getting a bit OT.
[edited by: Robin_reala at 10:34 am (utc) on April 18, 2007]
