HTML Tables
April 30, 2004 7:37 AM Subscribe
Basic HTML question re. using tables for no frills layout: if I have a centred table with just one or two TR rows with say 3 TD cells in them, and keep sporadically adding stuff to the cells in the bottom row so that they become humungously long, will something eventually break? Anyway, are tables cool for layout? Or should I be thinking about learning something else?
I'd like a wide central column that is centred on the page, aligned to the same size as the page banner (in this case 680 px), in which bloggish text would be accumulated; and then to have the options of narrower columns on the left and right sides for internal/external nav. I could do this with a simple, centred, three column table, but are there any good reasons why I should not? At the moment I do not want to do anything fancier than this. It seems like the three column format is a fairly standard one but when I check out other people's markup there's quite often a whole bunch of fancy-pants looking stuff in there to achieve it. ;) Anyway, any help greatly appreciated.
I'd like a wide central column that is centred on the page, aligned to the same size as the page banner (in this case 680 px), in which bloggish text would be accumulated; and then to have the options of narrower columns on the left and right sides for internal/external nav. I could do this with a simple, centred, three column table, but are there any good reasons why I should not? At the moment I do not want to do anything fancier than this. It seems like the three column format is a fairly standard one but when I check out other people's markup there's quite often a whole bunch of fancy-pants looking stuff in there to achieve it. ;) Anyway, any help greatly appreciated.
I agree. Using tables for simple layout is fine. Moving to CSS only pays off, in my opinion, when you have to gin up crazy complicated table structures to achieve what you want. I have seen so much CSS that not only doesn't do what the author intended on X platform, it doesn't display/work at ALL.
posted by RustyBrooks at 8:34 AM on April 30, 2004
posted by RustyBrooks at 8:34 AM on April 30, 2004
Tables have been the mainstay of html layout for many years. You have to have some seriously complex table to break even the most flakey of browsers.
A lot of people will tell you to learn CSS. It's something to keep in mind, and will eventually replace table based layout, but at the moment it cannot cope with much. Making a layout look even remotely the same on different browsers requires hacking. The 'holy grail' link posted above always makes me laugh. You could knock that up with a table in about 30 seconds, and it would work on practically every browser known to man
posted by derbs at 8:38 AM on April 30, 2004
A lot of people will tell you to learn CSS. It's something to keep in mind, and will eventually replace table based layout, but at the moment it cannot cope with much. Making a layout look even remotely the same on different browsers requires hacking. The 'holy grail' link posted above always makes me laugh. You could knock that up with a table in about 30 seconds, and it would work on practically every browser known to man
posted by derbs at 8:38 AM on April 30, 2004
Probably, nothing will break. Learn CSS, but don't drink the kool-aid. Tables have their advantages and disadvantages, and are just another tool in the box.
posted by weston at 9:00 AM on April 30, 2004
posted by weston at 9:00 AM on April 30, 2004
i don't see how learning css could be anything but good. might as well, unless you think that using tables for layouts is going to make a big comeback into standardization.
Anyhow, i see a lot more job postings for "must know CSS" then not.
posted by bob sarabia at 9:05 AM on April 30, 2004
Anyhow, i see a lot more job postings for "must know CSS" then not.
posted by bob sarabia at 9:05 AM on April 30, 2004
Unfortanetley centering a box in css is a little tricky because explorer is a little buggy. You might want to stick with tables for the reasons mentioned above. The glish.com page uses a different trick to do this.
The advantage of css would be that the resulting page should be smaller size, since you should have fewer tags everywhere. And it can render a bit faster because the browser can place the cells while the page is loading, rather than wait for the whole table to be loaded.
posted by bobo123 at 9:07 AM on April 30, 2004
The advantage of css would be that the resulting page should be smaller size, since you should have fewer tags everywhere. And it can render a bit faster because the browser can place the cells while the page is loading, rather than wait for the whole table to be loaded.
posted by bobo123 at 9:07 AM on April 30, 2004
Tables are here to stay bob. Especially if you work where I do. The designers want complex designs implemented pixel-perfectly, and the clients want sites that work on every browser going back to version3. Using CSS doesn't cut it, and never will IMO. For every person who can't view their site because they run netscape 4 and the CSS breaks, is a lost customer.
posted by derbs at 9:19 AM on April 30, 2004
posted by derbs at 9:19 AM on April 30, 2004
Use tables for basic layout and columns. CSS for al the more subtle effects, borders, margins, padding, linespacing, [a] rollover behaviour, etc.
posted by signal at 9:35 AM on April 30, 2004
posted by signal at 9:35 AM on April 30, 2004
where is the presidencial candidate that will focus on web standards and a campaign of nationwide browser updating? you know, the things that are important to me.
posted by bob sarabia at 10:06 AM on April 30, 2004
posted by bob sarabia at 10:06 AM on April 30, 2004
or "presidential". whichever.
posted by bob sarabia at 10:07 AM on April 30, 2004
posted by bob sarabia at 10:07 AM on April 30, 2004
(you will find the link adamrice gives much more impressive once you've learnt css. which probably says something...)
posted by andrew cooke at 10:26 AM on April 30, 2004
posted by andrew cooke at 10:26 AM on April 30, 2004
CSS Zen Garden (adamrice's link) is an excellent resource and proof of concept. However, it works in part because each design was created by a CSS-aware designer, and likely without pressure from a client who just didn't care about webstandards. It's a lot of good things, but a decisive argument for abandonment of tables as layout tools it is not.
designers want complex designs implemented pixel-perfectly, and the clients want sites that work on every browser going back to version3.
I think it's also worth mentioning that tables as layout tools persist not just because CSS support is somewhat buggy across browsers. In many cases, they're simply the easier metaphor to use, and the only markup sin involved in using them is that they lose their semanticity. But ceasing to use table markup for layout is not the only solution to that problem (see my link above for other hints at solutions).
posted by weston at 10:31 AM on April 30, 2004
designers want complex designs implemented pixel-perfectly, and the clients want sites that work on every browser going back to version3.
I think it's also worth mentioning that tables as layout tools persist not just because CSS support is somewhat buggy across browsers. In many cases, they're simply the easier metaphor to use, and the only markup sin involved in using them is that they lose their semanticity. But ceasing to use table markup for layout is not the only solution to that problem (see my link above for other hints at solutions).
posted by weston at 10:31 AM on April 30, 2004
It's something to keep in mind, and will eventually replace table based layout, but at the moment it cannot cope with much.
Can I get that in writing so I can take the rest of the day off? I'm dead in the middle of building a user interface with a top row of semi-transparent navigation, 3 pallettes on the right and two information areas in the middle with a calendar built into it. Oh yeah: and I created faux select dropdowns from a simple UL element that operate just like real ones from an HTML form perspective but look nicer. Don't think tables will let you do that. Admittedly the client only wants it to work in IE6, but they're going to get IE5+, Mozilla, Safari, etc. If you need to support IE3 and Netscape 3, that's your fault for not pointing out no one uses them anymore. Who's running Windows 3.11 so they can use IE3? Why would anyone still use NS3 when NS4 is awful enough?
All of which is way off target: stick with tables. It'll be way easier. Unless you have an interest in learning a difficult and arcane art, tables will see you through and it'll work well most everywhere.
posted by yerfatma at 10:37 AM on April 30, 2004
Can I get that in writing so I can take the rest of the day off? I'm dead in the middle of building a user interface with a top row of semi-transparent navigation, 3 pallettes on the right and two information areas in the middle with a calendar built into it. Oh yeah: and I created faux select dropdowns from a simple UL element that operate just like real ones from an HTML form perspective but look nicer. Don't think tables will let you do that. Admittedly the client only wants it to work in IE6, but they're going to get IE5+, Mozilla, Safari, etc. If you need to support IE3 and Netscape 3, that's your fault for not pointing out no one uses them anymore. Who's running Windows 3.11 so they can use IE3? Why would anyone still use NS3 when NS4 is awful enough?
All of which is way off target: stick with tables. It'll be way easier. Unless you have an interest in learning a difficult and arcane art, tables will see you through and it'll work well most everywhere.
posted by yerfatma at 10:37 AM on April 30, 2004
Tables are good and serve their purpose well. Just don't get carried away and nest them 5 deep - there's always a more elegant way to precise positioning.
MiniAsk:- Tell me, someone who knows CSS better than I do (which is not hard): how do you make layers "flexible" in the way percentage widths do with tables?
posted by SpaceCadet at 10:50 AM on April 30, 2004
MiniAsk:- Tell me, someone who knows CSS better than I do (which is not hard): how do you make layers "flexible" in the way percentage widths do with tables?
posted by SpaceCadet at 10:50 AM on April 30, 2004
Getting tables right is the whole reason I use DreamWeaver. It's not a terribly bright program, but it does make laying out 3-deep nested tables, and aligning/attributing them all correctly, easier. It's got a halfway decent stylesheet editor, too. I'd recommend pretty much ignoring all its other features though.
posted by scarabic at 11:12 AM on April 30, 2004
posted by scarabic at 11:12 AM on April 30, 2004
how do you make layers "flexible" in the way percentage widths do with tables?
It's a bit difficult given the proper implementation of the box model means things like width=100% and padding on the left or right will make the page too wide all the time (MS's implementation of the box model is wrong, but you can see where someone would make the mistake).
Thankfully fixed-width designs (centered on the page) are all the rage right now, but the few times I've had to do it, I cheat: I don't set a width on the scaling boxes and then either use padding or nest another box inside to get the layout correct.
posted by yerfatma at 11:36 AM on April 30, 2004
It's a bit difficult given the proper implementation of the box model means things like width=100% and padding on the left or right will make the page too wide all the time (MS's implementation of the box model is wrong, but you can see where someone would make the mistake).
Thankfully fixed-width designs (centered on the page) are all the rage right now, but the few times I've had to do it, I cheat: I don't set a width on the scaling boxes and then either use padding or nest another box inside to get the layout correct.
posted by yerfatma at 11:36 AM on April 30, 2004
I build a lot of corporate sites, including stores. The compromises I tend to stick with are:
1) Basic table(s) for layout -usually 1 row, 3 columns
2) No weird colspans or rowspans. Use stacked tables instead - one for header, one for main body and one for footer.
3) No nested tables unless there is no other way. Use a nested table to draw a border or get extra padding/margins and I will make you do it over in style.
I then use CSS to style and position everything else. This has been the most reasonable arrangement in terms of learning curve and production time. However, when the project is for strictly for modern browsers and I'm the only one doing the markup, I'll indulge in making the most use of CSS as I can.
posted by Sangre Azul at 12:46 PM on April 30, 2004
1) Basic table(s) for layout -usually 1 row, 3 columns
2) No weird colspans or rowspans. Use stacked tables instead - one for header, one for main body and one for footer.
3) No nested tables unless there is no other way. Use a nested table to draw a border or get extra padding/margins and I will make you do it over in style.
I then use CSS to style and position everything else. This has been the most reasonable arrangement in terms of learning curve and production time. However, when the project is for strictly for modern browsers and I'm the only one doing the markup, I'll indulge in making the most use of CSS as I can.
posted by Sangre Azul at 12:46 PM on April 30, 2004
Response by poster: Thanks, everyone, this is very useful. Tables it is, then; and I will avoid nesting, which should not be too hard, as basically it is just going to be a long list of stuff.
posted by carter at 1:29 PM on April 30, 2004
posted by carter at 1:29 PM on April 30, 2004
I told you....... Can of worms......
But, I think most here are missing the best thing about CSS - A more complete separation between content and layout. Which is why I use CSS.
For example, if you have your content drawn from a database, and you want to change the way that content is presented, you need to recode the table structure on several pages. But with CSS you can just change your CSS file and be done. Ditto for showing content differently based on context.
Yes, a similar thing can be done around tables using header and footer files, but that's extremely limiting.
Tables = easier
CSS = better
Both have their place. But when it comes to separating content from presentation, CSS is golden. And bob sarabia's point is good. Knowing CSS will make you a better person.
posted by y6y6y6 at 1:46 PM on April 30, 2004
But, I think most here are missing the best thing about CSS - A more complete separation between content and layout. Which is why I use CSS.
For example, if you have your content drawn from a database, and you want to change the way that content is presented, you need to recode the table structure on several pages. But with CSS you can just change your CSS file and be done. Ditto for showing content differently based on context.
Yes, a similar thing can be done around tables using header and footer files, but that's extremely limiting.
Tables = easier
CSS = better
Both have their place. But when it comes to separating content from presentation, CSS is golden. And bob sarabia's point is good. Knowing CSS will make you a better person.
posted by y6y6y6 at 1:46 PM on April 30, 2004
For example, if you have your content drawn from a database, and you want to change the way that content is presented, you need to recode the table structure on several pages.
Hmm, not sure what you mean y6. I have been developing dynamic websites for years and have found tables to be the best method in delivering dynamic content. I normally hear arguments against tables and dynamic content that are superficial and can easily be cured while still using tables (for example, many people think tables can only be rendered to view in a browser ONLY when the {/table} tag has been downloaded - wrong! - e.g. in ASP Response.Flush will deliver even half-rendered-so-far tables to the browser view). In fact, concentrating on tables, you start to really get a more thoroughbred view of design and I find methodology and useability comes more to the fore when using tables. With layers, designers become more indulgent because less discipline is needed. Just my take on things.....I am a programmer that develops commericial sites (e-commerce, content management, groupware - maybe this gives away the direction in which I'm coming from).
posted by SpaceCadet at 3:24 PM on April 30, 2004
Hmm, not sure what you mean y6. I have been developing dynamic websites for years and have found tables to be the best method in delivering dynamic content. I normally hear arguments against tables and dynamic content that are superficial and can easily be cured while still using tables (for example, many people think tables can only be rendered to view in a browser ONLY when the {/table} tag has been downloaded - wrong! - e.g. in ASP Response.Flush will deliver even half-rendered-so-far tables to the browser view). In fact, concentrating on tables, you start to really get a more thoroughbred view of design and I find methodology and useability comes more to the fore when using tables. With layers, designers become more indulgent because less discipline is needed. Just my take on things.....I am a programmer that develops commericial sites (e-commerce, content management, groupware - maybe this gives away the direction in which I'm coming from).
posted by SpaceCadet at 3:24 PM on April 30, 2004
Yeah, tables are great for dynamic data, if it's tabular (a list of results with multiple pieces); otherwise, CSS is cleaner (I do both sides, HTML and apps, so I've got no bias either way).
posted by yerfatma at 3:29 PM on April 30, 2004
posted by yerfatma at 3:29 PM on April 30, 2004
Ditto on preview, ditto the two comments above mine :)
Tables are fine. Personally I wouldn't use them for layout unless someone said to me "this has to look the same in all browsers and greater than 1% of our visitors are using version 4 browsers."
The first time I learned HTML it was 1995. I was still more or less a kid. The second time I learned it was in 2001, at that time CSS seemed really cool, so I learned it simultaneously. Here's what I've learned. What to use depends entirely on the size and complexity of the project, who will be working with it when you're gone, and most importantly, the target audience.
As far as it is possible to love something that describes the visual appearance of data, I love CSS. For my own projects I find myself writing xhtml transitional with css. I drank the cool aid, but not all of it. Accessibility doesn't matter if your target audience doesn't need it. Web standards don't matter if they'll cost you customers. But if your audience is broad and your aim is to provide information rather than to drum up business, accessibility and web standards are essential. And if you're after long term viability, standards make updates easier, and the separation of style and content makes massive visual changes simple.
You say you're making a long list of stuff. If I were doing that I'd be using a list, not a table, and making it look however I want with stylesheets. But it isn't necessary, nor necessarily preferable.
Short answer, do what you're most comfortable with, if you plan on doing a lot of stuff in the future get a basic understanding of CSS, and don't stress to much.
posted by Grod at 3:41 PM on April 30, 2004
Tables are fine. Personally I wouldn't use them for layout unless someone said to me "this has to look the same in all browsers and greater than 1% of our visitors are using version 4 browsers."
The first time I learned HTML it was 1995. I was still more or less a kid. The second time I learned it was in 2001, at that time CSS seemed really cool, so I learned it simultaneously. Here's what I've learned. What to use depends entirely on the size and complexity of the project, who will be working with it when you're gone, and most importantly, the target audience.
As far as it is possible to love something that describes the visual appearance of data, I love CSS. For my own projects I find myself writing xhtml transitional with css. I drank the cool aid, but not all of it. Accessibility doesn't matter if your target audience doesn't need it. Web standards don't matter if they'll cost you customers. But if your audience is broad and your aim is to provide information rather than to drum up business, accessibility and web standards are essential. And if you're after long term viability, standards make updates easier, and the separation of style and content makes massive visual changes simple.
You say you're making a long list of stuff. If I were doing that I'd be using a list, not a table, and making it look however I want with stylesheets. But it isn't necessary, nor necessarily preferable.
Short answer, do what you're most comfortable with, if you plan on doing a lot of stuff in the future get a basic understanding of CSS, and don't stress to much.
posted by Grod at 3:41 PM on April 30, 2004
I think the real problem that few people seem to recognize is that CSS is simple insufficient for the tasks it is purported to accomplish. Namely, that we can separate semantics from presentation and put all of that missing presentation into CSS. It is immediately apparent that CSS falls down spectactularly in attempting to accomplish even some very simple types of presentation--most prominently, multi-column pages.
The problem is that if we change a table-based page to a semantically-marked-up page, we lose the information about how to arrange the page, and CSS isn't powerful enough to reproduce that missing information. As far as layout is concerned, CSS lacks the capability to describe tabular layouts--you might even say table-based designs present more semantic meaning, design-wise, than CSS-based designs do.
Tables let you say what elements should always have their borders touching, or have their borders line up. Only to a limited extent is this possible with CSS. The best you can do with CSS is to set the sizes of two elements such that their borders line up, but then it's no longer explicitly represented that those elements are touching, and it's only possible to align elements like this in limited cases.
What is needed is a stronger language than CSS, something that can do more powerful transformations on a document. So we could write a document with semantic markup only, then transform it into a table-based document by saying "these elements should be arranged in a grid like so," and only then apply CSS (if still needed).
In fact, to get to my long-winded point, we already have such a language: XML stylesheets (XSLT). It's too bad that client-side support for XSLT is limited. IE6 and Mozilla have excellent implementations of XSLT. IE5 tried, but has some glaring bugs/deviations-from-the-standard in its XSLT engine.
I think this is why the debate between tables and CSS is still ongoing. Tables are presentational, but CSS isn't powerful enough to replace them.
From a practical standpoint, the advantages of tables vastly outweigh the theoretical advantages of CSS. It's good to separate content and presentation, but not if it cripples your design. And accessibility issues are a non-starter--because of the prevalance of table-based layout, non-visual user agents have to be able to deal with tables in a reasonable manner, purity be damned.
posted by Khalad at 4:14 PM on April 30, 2004
The problem is that if we change a table-based page to a semantically-marked-up page, we lose the information about how to arrange the page, and CSS isn't powerful enough to reproduce that missing information. As far as layout is concerned, CSS lacks the capability to describe tabular layouts--you might even say table-based designs present more semantic meaning, design-wise, than CSS-based designs do.
Tables let you say what elements should always have their borders touching, or have their borders line up. Only to a limited extent is this possible with CSS. The best you can do with CSS is to set the sizes of two elements such that their borders line up, but then it's no longer explicitly represented that those elements are touching, and it's only possible to align elements like this in limited cases.
What is needed is a stronger language than CSS, something that can do more powerful transformations on a document. So we could write a document with semantic markup only, then transform it into a table-based document by saying "these elements should be arranged in a grid like so," and only then apply CSS (if still needed).
In fact, to get to my long-winded point, we already have such a language: XML stylesheets (XSLT). It's too bad that client-side support for XSLT is limited. IE6 and Mozilla have excellent implementations of XSLT. IE5 tried, but has some glaring bugs/deviations-from-the-standard in its XSLT engine.
I think this is why the debate between tables and CSS is still ongoing. Tables are presentational, but CSS isn't powerful enough to replace them.
From a practical standpoint, the advantages of tables vastly outweigh the theoretical advantages of CSS. It's good to separate content and presentation, but not if it cripples your design. And accessibility issues are a non-starter--because of the prevalance of table-based layout, non-visual user agents have to be able to deal with tables in a reasonable manner, purity be damned.
posted by Khalad at 4:14 PM on April 30, 2004
stating the obvious here, i think, but there are two ways in which css may be useful:
in my opinion/experience, the arguments for delaying everything until the client are usually weak, so i tend to use the second approach. however, there are two exceptions: first, cool dynamic tricks, which are sometimes nice (bad example - the zen link above. good example - international herald tribune's wonderful site); second you may not have dynamic html generation on the server (maybe you're hand-writing personal home page content in html).
but i'm not a designer, so maybe you should listen to someone else. :o)
posted by andrew cooke at 4:23 PM on April 30, 2004
- client-side control of presentation
- css lets you separate content from structure (to a limited extent) until the data are presented on the client.
- it's basic engineering to separate the two on the server in any moderately large application (content is in a database and structure comes from some kind of template engine), so adding css into the mix makes sense only if there is an advantage in delaying the final presentation until the client.
- separating decoration from structure
- even if you're fixing structure on the server, specifying all the details of the appearance (colours, fonts etc) inside the template is messy. placing that information in css helps keep things tidy and makes tamplate changes easier
in my opinion/experience, the arguments for delaying everything until the client are usually weak, so i tend to use the second approach. however, there are two exceptions: first, cool dynamic tricks, which are sometimes nice (bad example - the zen link above. good example - international herald tribune's wonderful site); second you may not have dynamic html generation on the server (maybe you're hand-writing personal home page content in html).
but i'm not a designer, so maybe you should listen to someone else. :o)
posted by andrew cooke at 4:23 PM on April 30, 2004
i should have added that also css sometimes lets you do things you can do no other way - see yerfatma's small type
posted by andrew cooke at 4:31 PM on April 30, 2004
posted by andrew cooke at 4:31 PM on April 30, 2004
Response by poster: This is great; Khalad's response is one that really got closest to how I personally am not understanding the issue. Basically, I wanted a centred middle column with two undefined colums to the left and the right which would be the width of their content, in both the latter cases basically one or two word links for the navigation. I'm not bothered about large white margins on the left and right hand sides outside these columns which will vary depending on browser window size.
So I wanted a centre and floating elements on either side, with undefined distances to the edge of the page; and I couldn't figure it out to my own satisfaction. As far as I could tell this is the inverse of the trondant's example above, which has fixed left and right columns and a free-flowing centre column that expands to page width. So as far as Khalad's response goes, I can see how you can define absolute elements and have other spaces defined in relation to them by default, but not how to define two or three things just in relationship to each other. Although apologies if I'm mangling this ;)
I certainly have no objection to CSS and *can* see the benefit of separating content from structure for revising and updating (and I have have used CSS before to define the basic styles of fonts and so on across existing home page projects). But my existing HTML books are 3 years old and don't really deal with CSS and tabular layout, and when I googled around for CSS templates for tabular layouts, they just seemed obscure to me :-/ And I wasn't willing to just cut and paste something that I might inadvertantly break at some point in the future and then not know how to fix it. (And yes andrew it is just writing personal home page content in HTML ...)
Anyway this has been great, once again thank you all for taking the time to deal with this!
posted by carter at 5:15 PM on April 30, 2004
So I wanted a centre and floating elements on either side, with undefined distances to the edge of the page; and I couldn't figure it out to my own satisfaction. As far as I could tell this is the inverse of the trondant's example above, which has fixed left and right columns and a free-flowing centre column that expands to page width. So as far as Khalad's response goes, I can see how you can define absolute elements and have other spaces defined in relation to them by default, but not how to define two or three things just in relationship to each other. Although apologies if I'm mangling this ;)
I certainly have no objection to CSS and *can* see the benefit of separating content from structure for revising and updating (and I have have used CSS before to define the basic styles of fonts and so on across existing home page projects). But my existing HTML books are 3 years old and don't really deal with CSS and tabular layout, and when I googled around for CSS templates for tabular layouts, they just seemed obscure to me :-/ And I wasn't willing to just cut and paste something that I might inadvertantly break at some point in the future and then not know how to fix it. (And yes andrew it is just writing personal home page content in HTML ...)
Anyway this has been great, once again thank you all for taking the time to deal with this!
posted by carter at 5:15 PM on April 30, 2004
If you think CSS isn't powerful enough or doesn't work well enough, keep investigating. Someday you'll Jim Jones it up with the rest of us.
The problem is that if we change a table-based page to a semantically-marked-up page, we lose the information about how to arrange the page, and CSS isn't powerful enough to reproduce that missing information.
I think that's a false dichotomy. "I think" because I'm not even sure what that means. "How to arrange the page" is meaningless, the important part is the information on the page. Arrangement is up to the consumer, not the presenter. Make it look nice, but don't mark it up in such a way I can't do what I want with it. Properly used, CSS frees a page. Who cares about how you designed the page? Well, you do, but the point of putting it up is to get information to me. If I want to get that info through a modern web browser, Lynx or a bot I have pulling down raw text, that's up to me and you should be happy I'm interested.
accessibility issues are a non-starter--because of the prevalance of table-based layout, non-visual user agents have to be able to deal with tables in a reasonable manner, purity be damned
Let's you and me start tearing up wheelchair ramps, cuz the prevalance of tables means wheelchairs should have to be able to deal with them. People trying to push CSS purely for "accessiblity" are often full of it, but that doesn't mean CSS isn't a better approach. Show me the tables equivalent of an audio stylesheet.
posted by yerfatma at 7:59 PM on April 30, 2004
The problem is that if we change a table-based page to a semantically-marked-up page, we lose the information about how to arrange the page, and CSS isn't powerful enough to reproduce that missing information.
I think that's a false dichotomy. "I think" because I'm not even sure what that means. "How to arrange the page" is meaningless, the important part is the information on the page. Arrangement is up to the consumer, not the presenter. Make it look nice, but don't mark it up in such a way I can't do what I want with it. Properly used, CSS frees a page. Who cares about how you designed the page? Well, you do, but the point of putting it up is to get information to me. If I want to get that info through a modern web browser, Lynx or a bot I have pulling down raw text, that's up to me and you should be happy I'm interested.
accessibility issues are a non-starter--because of the prevalance of table-based layout, non-visual user agents have to be able to deal with tables in a reasonable manner, purity be damned
Let's you and me start tearing up wheelchair ramps, cuz the prevalance of tables means wheelchairs should have to be able to deal with them. People trying to push CSS purely for "accessiblity" are often full of it, but that doesn't mean CSS isn't a better approach. Show me the tables equivalent of an audio stylesheet.
posted by yerfatma at 7:59 PM on April 30, 2004
Tables = easier
CSS = better
Um, no. CSS positioned layouts and table layouts have different advantages. CSS allows less cluttered markup, more positional flexibility, and clarity about the semantics of the markup. Tables allow better visual cross-browser compatibility and a layout concept that's easier to grasp. And there are tricks you can do with both that you can't do with the other right now, at least without resorting to the kind of gyrations that would pretty much negate the advantage.
The easier vs better dichotomy doesn't mean much on the surface. What does "better" mean? Sometimes easier is better. Sometimes there are goals that override "easier." It just depends on the competing demands and requirements of those working on the site.
posted by weston at 12:10 AM on May 1, 2004
CSS = better
Um, no. CSS positioned layouts and table layouts have different advantages. CSS allows less cluttered markup, more positional flexibility, and clarity about the semantics of the markup. Tables allow better visual cross-browser compatibility and a layout concept that's easier to grasp. And there are tricks you can do with both that you can't do with the other right now, at least without resorting to the kind of gyrations that would pretty much negate the advantage.
The easier vs better dichotomy doesn't mean much on the surface. What does "better" mean? Sometimes easier is better. Sometimes there are goals that override "easier." It just depends on the competing demands and requirements of those working on the site.
posted by weston at 12:10 AM on May 1, 2004
I didn't make it clear, but I am as strong an advocate for CSS as anybody out there. I just wanted to address a generally underappreciated perspective, namely that it's okay to use a table or two if the alternative is some really messed up CSS. A lot of CSS purists tend to throw the baby out with the bathwater and forbid the use of tables, even when CSS isn't a satisfactory substitute.
So to answer the question here, try CSS, but if it's too difficult, don't be shy about switching to a table. A little pragmatism can save you hours of stylesheet hacking.
posted by Khalad at 2:04 AM on May 1, 2004
So to answer the question here, try CSS, but if it's too difficult, don't be shy about switching to a table. A little pragmatism can save you hours of stylesheet hacking.
posted by Khalad at 2:04 AM on May 1, 2004
Khalad's 'long winded' response was spot on.
Admittedly the client only wants it to work in IE6, but they're going to get IE5+, Mozilla, Safari, etc. If you need to support IE3 and Netscape 3, that's your fault for not pointing out no one uses them anymore. Who's running Windows 3.11 so they can use IE3? Why would anyone still use NS3 when NS4 is awful enough?
That's ironic, I thought CSS was all about "accessibility"!? People still use old browsers you know!
posted by derbs at 4:24 AM on May 1, 2004
Admittedly the client only wants it to work in IE6, but they're going to get IE5+, Mozilla, Safari, etc. If you need to support IE3 and Netscape 3, that's your fault for not pointing out no one uses them anymore. Who's running Windows 3.11 so they can use IE3? Why would anyone still use NS3 when NS4 is awful enough?
That's ironic, I thought CSS was all about "accessibility"!? People still use old browsers you know!
posted by derbs at 4:24 AM on May 1, 2004
whole bunch of fancy-pants looking stuff
just sell the computer. :-)
but seriously, many well known, highly trafficked sites are table based. on the other hand i have a three column layout and converted it to css last year, and now i can actually edit the source far more easily (and the source has gotten waaaaay smaller) since it was a complex mess of nested tables before and now it's a straightforward, easy to read bunch of fancy-pants looking stuff like <div class="sidebar"> and <div class="content">.
posted by quonsar at 6:33 AM on May 1, 2004
just sell the computer. :-)
but seriously, many well known, highly trafficked sites are table based. on the other hand i have a three column layout and converted it to css last year, and now i can actually edit the source far more easily (and the source has gotten waaaaay smaller) since it was a complex mess of nested tables before and now it's a straightforward, easy to read bunch of fancy-pants looking stuff like <div class="sidebar"> and <div class="content">.
posted by quonsar at 6:33 AM on May 1, 2004
That's ironic, I thought CSS was all about "accessibility"!? People still use old browsers you know!
Que? CSS has nothing to do with accessibility. That's a side benefit. Assuming of course, we're talking about "accessibility" the way it's meant, i.e., people who aren't using a traditional browser. In the end, it has to be up to the client to determine if the trade-offs are worth it. It's their site and their audiences. And it's only fair to present both sides of the story accurately, even if I am a zealot.
I would say this: in a few years (between 1-10, let's say 3 for fun), this discussion is going to look silly. Not because 99% of browsers will fully support CSS1, but because you're going to need to present information in a semantic way to be heard on the web. (In case you weren't sure about my Kool-Aid consumption, I just wanted to make it clear it's a high number)
posted by yerfatma at 9:16 AM on May 1, 2004
Que? CSS has nothing to do with accessibility. That's a side benefit. Assuming of course, we're talking about "accessibility" the way it's meant, i.e., people who aren't using a traditional browser. In the end, it has to be up to the client to determine if the trade-offs are worth it. It's their site and their audiences. And it's only fair to present both sides of the story accurately, even if I am a zealot.
I would say this: in a few years (between 1-10, let's say 3 for fun), this discussion is going to look silly. Not because 99% of browsers will fully support CSS1, but because you're going to need to present information in a semantic way to be heard on the web. (In case you weren't sure about my Kool-Aid consumption, I just wanted to make it clear it's a high number)
posted by yerfatma at 9:16 AM on May 1, 2004
This thread is closed to new comments.
If you really want to move to something other than tables you can jump into CSS. CSS is more powerful, but very frustrating and problematic.
From your tone I suspect tables are the way to go.
posted by y6y6y6 at 7:54 AM on April 30, 2004