Somehow in the last couple years, everyone seems to have decided that TABLES are no good. Despite the fact that they’ve been around forever and provide a stable way to implement a layout for all browsers, they have somehow fallen out of favor. The reason? The culture of CSS.

The culture of CSS is strong these days, and it’s composed of a variety of voices from the web community. There are those who praise CSS for its philosophical purity. After all, it is the realization of that promised separation of form and content. Finally, content has been set free to flow to any device, and be seen in dozens of ways the designers never intended.

There are others who just love to set guidelines and see code that validates. I’m glad that there are people like this, but I can squarely say that I’m not one. I’m the sort that will leave a sock right there in the middle of the floor and have no compulsion to pick it up. If I worked for the W3C, I’d leave a sock right in middle of the CSS 3.0 standard. I would. Anyhow, CSS will certainly help your code validate… if for no other reason than the HTML portion gets smaller.

Lastly, there are those who like CSS for practical reasons. It certainly makes font styling easy… and well done symantic markup has all sorts of nice accessibility wins. When it comes to layout, however, I sure do miss tables.

Tables were clunky at times, but they were pretty straightforward to debug. When you saw something wrong on the page, you knew to go to the cell that looked funny and fix it. With CSS, the bug could be *anywhere*. perhaps it is the margins on the style, or the containing div, or the container’s container, or perhaps its just a weird wrinkle in the vast and complex space of how various browsers treat style attributes. If you’ve coded it well, then your visual styling stuff is separate from your layout stuff, and you end up bouncing back and forth within your CSS file or between files to get things under control. Arrg.

It feels sort of like 1997 again. Back then, the rapid chain of browser versions and churn in HTML tags made coding for all browsers into an unfortunate endeavor. Not all tags worked right, and it wasn’t always clear whether the bug was in your code or in how the browser handled it. CSS is like that now.

Stepping back from the fray we see that ultimately, all these frustrations arise because designers want pixel-accurate control over design, while others have insisted that the web is “not about pixel-accurate design”. This is an old debate, and one that in my mind has only recently been settled. Ultimately, both sides were right… just for vastly different situations. RSS has demonstrated the power of pourable content, and is a powerful testament to the idea of web as an all-purpose symantically-coherent content transporter.

On the other side of the coin, most of the websites that people use daily prove just the opposite point. Throughout our design and usability work, we see that pixels really do matter. A box shifted 5 pixels left doesn’t visually parent another object correctly… a min-width layout failure suddenly makes a site unnavigable… a snippet of text blown out of its borders just looks bad.

Given this, it’s time that we got serious about a making accurate layout a priority from the technical side. Then we could stop fussing over decisions like CSS-based vs. table-based layout, and get back to focusing on design.

Problem is, accurate layout should be a *client side* technology. You, as a designer, can state some rules of layout. But the user will always be able to override them and change your expectations.

You can’t control the user environment. Trying your site in all major browsers is not enough, as the variability is so big that presentation conditions are unpredictable (am I reading your page in my PDA, in my car’s GPS system, in my fridge? do I set minimum font size to 30px, have I post-processed it with GreaseMonkey?) Pixel-accurate control may be important, but is not responsability of the content provider.

So if you want to achieve perfect usability, forget attaching presentation&layout to content and make tools that force a common presentation over content collected from arbitrary sources. Center on making good content aggregators, then you can have perfect control layout&behavior (on the client side).

Accessibility: CSS based designs, and designs with a web-standards approach encourage accessibility. Of course, as with tables-based design, you can create inaccessible CSS-based designs, but the underlying markup is usually semantically more accurate, thus improving accessibility dramatically.

Tables-based layouts make life very difficult for assistive technology, which in turn makes on-line life very difficult for those who need assistive technology to interpret and present pages to them in a different way.

Accessibility is becoming a bigger driver due to legal requirements, and thus the CSS-based approach is one that suits it quite well.

You can use tables for layout and accessibility if the tables are ridiculously simple, and one or two layouts are hard to do in CSS, but for a vast majority of requirements, web technology is now at a state where, while not perfect (and even while having to cater for IE!), you can ditch non-accessible table-based layout, and “clean out those socks”

CSS is not the answer for accessibility. First of all, what kind of accessibilty are we talking about here? I know of an online library for blind and low-vision users. Shockingly, it uses tables. The development team did actual user tests, and the users like the site. There’s been a lot of discussion on Mike Davidson’s Accessibility Chronicles.

I built a large-scale site using CSS last year, and I’m not entirely convinced of the advantages. The site is valid. But, I don’t think that’s saying much. A lot of sites with code-from-hell can validate. Valid code isn’t automatically well-written, efficient code.

For me, the one thing that keeps me up at night is whether or not a CSS-based layout is making any difference to my users. I doubt they care or notice. I’d rather spend my time awake at night thinking about design that they would notice.

RSS might actually be the death blow to the separation of content and layout dogma for HTML. For years the standards aficionados have been telling us that our HTML should only hold the contents, and that anything presentational should be relegated to CSS files (neverminding that, in the real 21st-century world, making a complex CSS-only layout work across browsers and OSs is much harder than with tables) so that our contents could be read and interpreted by computers in a million different ways we can’t even imagine yet.
And what happens now? Any site that’s serious about publishing any contents has to provide it in two formats, HTML and RSS/Atom. Maybe some will blame it on web developers being too slow to adopt CSS-only design, but that’s not the point (plus, they’d be wrong: RSS adresses many issues — the ones that are actually relevant in the real world — that HTML and the W3C never cared to). It’s a fact, and it’s not going to change any time soon, that HTML files will now only be used for presentation, and computation is done on RSS files — the ones that were indeed designed from the start to be read and interpreted by computers. And that’s the way it should be.
Seperation of content and form is now achieved, compulsorily, on the CMS level. So who cares if the HTML template I use to display content is full of tables and other presentational markup, because it’s actually more efficient for me?

(You might object that RSS only offer the latest changes to contents, and sometimes even partial summaries — but that’s because it’s still a rather young format, and I’m pretty sure that full-content RSS archives will soon be the way to go for everyone.)

Stop trying to come up with universal rules. They universally fail. Different “sites” have different purposes, audiences, and goals. So to say you should design this way or that simply doesn’t make any sense. What HTML and CSS need to do, and have done a decent job of, is giving you options (tables, CSS, etc.) and tools to do what you want and need for your particular project and make decisions on the fly for the medium (computer, phone, etc.).

Of course, it still is not perfect, but a lot of that has to do with the adoption of standards. There is still a lot missing too (like allowing one block of text to automatically span multiple columns).

Is there a problem with debugging CSS? If so, does that mean CSS is bad or the debugging tools? Or is it the browser support? There is no silver bullet to design on the web currently, nor do I think there ever will be because the web is just a connection service, what people connect to can vary infinitely.

I’ve never found debugging CSS hard, but I only use very simple CSS1. You can always give everything a border; in Firefox use the Web Developer extension and outline block elements (Tools -> Web Developer -> Outline -> …) which is awesome.

First of all RSS doesn’t bring a “final blow” to semantic code, cause it serves a completely different purpose. To bring information with more data to a subscriber’s RSS reader, which a site visitor wouldn’t much care to know (time of a post for example).

Second, where tables would serve a great purpose in rigid structures, they bring too much clutter to the code with all their tags, too many attributes have to be defined in tds and generally don’t cut it in a complex design with elements of varying widths, unless you use a million nested ones.

Just think of a forum and what used to happen in the old phpBB when someone’s avatar was 400 pixels wide. All other avatar cells became needlessly wide. The problem was solved with a simple div. Sure it could’ve been solved with a but just *looks* so much prettier, doesn’t it.

I, myself fancy hybrid designs, cause css-only layouts are a pain in the arse, but for specific purposes even a css-only design is more than adequate.

I wrestled with this issue for a long time and came to a few conclusions. First, information designed to be sent to one device will not look good on another device. The idea that you can seperate content from display is assnine. You design the content to fit the display. An article written for the web should not be the same as an article written for a magazine. Designed for a phone, an application may have very differnt navigation then designed for a browser. Not only styled differently.

Additionally HTML was never meant to be a meta language to describe content. Using it for such a purpose is not really practical. What does a Div or a span tell me about its conent, nothing!

Good design on different devices requires much deeper logic than CSS can provide. It can be done programmatically, however, css is not the place to do it, XSLT might be a better option. XML is a meta langage that can actually describe content, addiontally XSLT and xPath provide the necessary logical operators to have really robost transformations between different mediums.

Finally, beware of people who base thier technical desicions on ideology. Abstract principles are great but in the real world we need to support real people, and practical concerns like compatiblity, and time to market, should trump ideological purity.

Me, I have rules for my layout based on what works across most browsers with the least need for managing special cases, and mazimum readability. Use divs to manage vertical space, use tables to manage horizontal space. (floats are too buggy in IE)

“The idea that you can seperate[sic] content from display is assnine[sic]. You design the content to fit the display.”

This is an example of totally missing the impetus for separating content from styling. You don’t design content to fit a display, you design content to communicate ideas. The display is merely a by-product of the communication method.

Just as in a print design, the content isn’t conceived in Quark or InDesign. It’s usually written in a plain old word processor document, and then injected into the layout application later, where the synthesis of the content and the layout converge in a magazine article.

What is true though is that the layout/styling of of the content, will influence the effectiveness of the communication, which is why good print layout people can still make money, and there isn’t a single ‘perfect’ magazine template.

In the same way, even though style can be separated from content, it’s the job of the communication medium (browser, rss feed reader, cell phone, etc) to make sure that the two get brought back together to complete the user experience or else we’re just left with a piece of the puzzle. In the case of plain RSS, we’re left with that initial content, which is nice, but would so often be better if a reasonable amount of layout and styling were applied on top.

Also, for architectural reasons, XSLT isn’t where that presentation logic should reside, because it would force the server’s XSLT-engine to have knowledge of the client display, so it could then serve the right kind of HTML to be displayed based on the client id. This is inefficient, since that styling would then have to be recalculated for each subsequent page, and it’s silly when there’s already a method for setting styling rules on a per-display-platform basis using CSS files which can be cached on the client to optimize performance.

Ok, this post is getting too long, but I did want to finish with more on that last point, which is that using CSS for its own sake is silly, but when it helps to achieve goals such as performance increases via caching, better SEO results, and better accessibility through semantic markup, then I’m all for it. And tables have their place in semantic markup, because their useful for displaying tabular data. Now we can all sit around trying to define what constitutes tabular data.

You make some very good points unfortunately you seemed to have missed mine entirely. This is probably my fault tho for not being clear. Forget about layout for a moment. You are assigned to write an article that is intended for print publication, say the verbose New Yorker. Your writing style will be differemt than if you were assigned to write that same article for news feed to cell phones.

In my personal practice I find its rare that the content I am presenting to users would make sense outside of its limited context.

The idea of using semantic markup is that you should be able to view the same content on any device/platform without limitations. The problem is that its the same content, and that content may not be appropriate for viewing in a different context. You actually want different content for different devices, not just different layouts.

This is why I dont think semantic markup and CSS are very good solutions to the problem of making a website work on a PDA. This model may work fine for blogs but lets take another more complex and contrete example. Hopefully here I can show why XSLT is a good way to make some of this stuff happen.

Yesterday my girlfriend sent me a link to a page on amazon. I clicked on the link from my cell phone, which loaded the entire page and rendered it the best it can. Those who shop amazon know how much crap they load the page with. It works fine on a 1024X768 screen, but it makes me do a ton of scrolling on my phone. Most of the extra things like wish lists and advertisments are of little use on a phone, they take too much space and aren’t likely to be used. All I need on a phone is a product description, a price, a pic, a link to add to cart, a link to check out, and a search field for navigation. With XSLT my backend doesn’t need to differentiate between the two devices, I can use XSLT to strip out the extraneous info and avoid sending it to the client, giving them a faster load time and better user experience. Also I can create the appropriate samantically correct mark=up for each type of device. This can’t be done on the client side.

Again my point is that content and style are related (should be related)on an additional axis and thier seperation is a deeper problem that semantic mark-up and CSS do not really solve.

Mathew:
Amazon is a horrid example, just as most other corporate. To stick with amazon, they use nested tables (found 3 levels deep before I got bored), area tags, and other horrid semantics. The amount of stuff they cram on their site makes it hard to navigate for small screen users, as you just pointed out, and also for screenreaders, braile devices, and pretty much anything other than a regular browser on a computer with a high-ish resolution. Most of the stuff on their site should be classified as advertisement, either for themselves or others. I personally think Amazon is a great example of horrible and cluttered design.

I think what you mean with ‘different content on different media’ is more of a ‘different content for different target audiences’. That’s not the issue here though. When I read an article online on my phone or PDA, I want the whole thing. Sure, large commercial websites should serve you simpler pages than they already are, but they should do that regardless of the medium they’re using. Visually disabled people, for one, could have serious issues finding what they want on Amazon. An ex-collegue of mine had gone almost blind from diabetes, he could see an area on screen of about half a square inch, through a magnifying glass.

I’ll agree that HTML isn’t the solution, but that’s why we’re trying to phase in XHTML. eXtensible is what we need here. Content really should just be content. Another big selling point of this is that it becomes painfully simple to change your design on the fly.

XSLT to convert things would be overkill, most of the time, btw, because most content is stored in a database and is processed by some form of server-side programming language to output your data, a lot of the time even with templates, which can easily be adjusted to output any form of (pseudo)xml (like html, xhtml, rss, atom).

The philosophy of XHTML is to separate the structure from its design. Correct me if I am wrong but aren’t tables structures? If you like to design tables, use CSS but it’s unrealistic to eventually eradicate tables and replace them with CSS. The question you might ask: did the authors of CSS had the intention to replace tables with CSS?

The “separate design and content” is so much easier said than done. You will always run in to a limit eventually. All you really can do is make it simple, and as robust as you can (which also means compromising on some details of a graphic design). And test.

The one aspect of the separation idea though, is that you should be able to change the design, look, feel, whatever of a site while keeping content stable (including stable URLs and paths).

I agree with Tom. Tables work better than CSS for layout. CSS really is buggy as all get out and plain jane CSS renders differently in every browser. I use CSS styles, but I use FONT SIZE and TABLE as well since they work better than CSS.

Firstly, the “problems” with CSS described here are not actually problems with CSS, but problems with the browsers. “Browser X doesn’t render directive Y properly” is a problem with browser X, not the standard containing directive Y.

Don’t get me wrong, there are some inflexibilities and problems with the CSS standard that make the goal of separating content and presentation impossible (how many div-in-a-div hacks have been made in the name of getting some layout to look right), but those are the problems with the standard.

I get your point, and I think the “happy medium” probably lives somewhere in between our two points. You attest that the content itself should change based on the display medium. I’m not sure I buy that completely, but then I’d be hard pressed to call all the “crap” that Amazon loads on their pages to be actual “content” in the first place. But our definitions of content aside, the point about XSLT being able to distinguish the client and serve the content appropriately has some merit, if you suppose the content should vary by medium. If however your content won’t vary (I’m thinking textual content such as blogs, reviews, etc.), then the pendulum swings more toward the CSS end of the spectrum, where you can avoid loading the styling data repeatedly.

That being said, there’s no reason that each technology (XSLT and CSS) can’t live in harmony, and better yet augment each other in a best-of-breed situation. Use XSLT to customize the output as necessary to add/remove content pieces, but use media-specific CSS to provide the styling and layout of the transformed content, and you should/could be golden.

Also, a lot of people are going on-and-on about how stable table layouts are, which leads me to believe no one’s using varying docTypes out there, which when combined with IE’s terrible box-model flub can cause all kinds of weirdness with table borders and padding when specifying widths in percentages. It’s nothing that can’t be overcome, but I don’t find it to be any more heinous than most CSS anomolies. Use CSS where it makes sense and helps you, but by all means if you can do something simply in a table that would take hours to figure out in CSS, USE A TABLE!

Being a designer and not a coder (though I have a coder background), I have to say, I could care less. What I mean to say is that code should enable the design to meet the overall business and user requirements. In some instances CSS can do that, in others CSS is required. After that, as a user experience professional, it’s all about handing it over the fence to the guys w/ the pyramid of jolt cans.

Now speaking as a designer, I have noticed that maintaining a CSS/xHTML setup to be a lot easier. What I mean to say is that it appears that changes to layout are easier since we don’t have to go back into the JSP code to make presentation level changes, which usually cuts down estimates for those change requests so they happen. Maybe this concern is more relevant for designers who aren’t doing the coding, but from my observation that is the large majority of us.

I understand valid css and xhtml, and I use it. But the more I use it, and the more I understand it, the more I am beginning to question the basic premise that I have heard repeated over and over and over: seperate content, display and functionality. All other benefits aside, why is it a good idea to seperate these three things?

Sure, it makes it easier for development and for maintenance. But if you truly seperate these items, do you not end up with the Thomas Kinkade of user experience? A basic premise of gestalt based art ideology is that the “whole is greater than the sum of the parts”. To me, this implies that the seperation of content, layout and function is setting oneself up for a frankenstein.

If we ever want to consider design a true and necessary aspect of software development, I think we need to begin to understand design outside of software development …

Incidentally, does anyone else think that wearing the little xHTML Valid image like a badge of honor is about as silly as having a Power of Pride bumper sticker?

Jon, it is definitely a good question you are asking. But to me this is the difference between graphic design, and interaction design. Graphic design is time-permanent. it ONLY needs to consider the presentation of content in one moment. Interaction Design while not focused on content presentation, does manage one main issue which is how to present things over time, so that they can be interacted with, or otherwise consumed. Sometimes these flows through time require using the same content across various presentations. In fact I would say, often it does just that.

To me this separation is a requirement for more complex enterprise and x-enterprise uses of data/information and other forms of structured and unstructured content.

I agree that the fourth dimension (ooOOoOO!!) adds quite a bit of complexity to our designs. But your final comment - which rings true with my own experience building enterprise software - is a little bit disconcerting.

If we require this separation for the creation of business-oriented software, and we acknowledge that the separation seems to imply a lack of cohesive aesthetic and experience design, we seem to be mandating that the users of enterprise software receive a sub par product.

Perhaps what I am getting at is that while I’m certainly not an advocate for garish graphic design in complicated software products, I truly believe that strong, content-specific aesthetics matter.

How can we manage content and create a “cohesive aesthetic” at the same time? Maybe I’m jumping the gun - maybe we aren’t ready to build software that is easy to use and is emotionally pleasing at the same time.

>Problem is, accurate layout should be a client
>side technology. You, as a designer, can state
>some rules of layout. But the user will always
>be able to override them and change your >expectations.

This is really new. For the hundreds of years of publishing (and hundreds of years of mass publishing) that preceded CSS, content authors got to decide EXACTLY how content would be presented to the user initially—whether on clay tablets, bumper stickers, or broadsheets. Readers might repeat what they had seen in other mediums or with varying styles (an early take on rip-mix-burn) but fundamentally publishers held the power.

Unfortunately, computer science types like to wax philosophically about the True Nature of Information, hence the creation of content-presentation dualism. But man, what a bad idea that turned out to be. Anybody who has struggled with web technologies has longed for the old days of pencil and paper, where lines actually stayed put!

RSS has the potential to change the situation from bad to worse. Most content is only bearable because of presentation; once it gets stripped of the critical design choices old Tufte insists upon, it will become practically useless. We’re in serious trouble kids, and it’s entirely our fault.

If the content is “unbearable” after being separated from the original presentation, why should anyone have to put up with it at all? And certainly you aren’t suggesting we all switch to image files or pdfs or *gasp* flattened dead tree pulp! Sorry, but this is one person who works with web technologies that never wants to have to use paper except in the restroom! I often wish I could click on text in a magazine to find out more.

I have been working with website design as a hobby for a few years, and when I discovered how to separate content from design, I was ecstatic! Its so much easier to maintain consistancy across pages. I have found it more difficult to use CSS, but having the design change everywhere in the site after changing one line in my CSS file makes it all worth it. Nearly any design can be better with divs and CSS. Tables are OK if all you need is one short term page, and they are required for displaying certain types of data, but other than that, just use CSS! Tables have their place: living room, kitchen, displaying the results of a multirow database query; but you don’t see interior designers placing stacks of them on walls just to hold the family portrait up! Why should web designers do it?

(XSLT sounds like a good idea too, but I really haven’t tried it, so I have no legit input.)

Really the seperation of style from it’s content has nothing to do with the end user. The people above mentioning ‘the whole is greater than it’s parts’ are exactly right. In the end everything is re-assembled for the user for that context, ie in a webpage or in a PDA or RSS reader. The only point to seperation is for maintenence and development. Always has been.

Stylsheets as a concept has been around a long time, even in standard desktop publishing. Some of the people are critical of it as though it were something new…it’s not really. No matter what medium or workflow you employ on or off the web, you always want to employ a level of seperation between the content created and delivered, and how it’s presented. It’s just plain good common sense.

In regards to XSLT, XSLT is NOT a presentation language. It’s a document converter. You will not be using XSLT to style XML documents. You will likely be using XSLT to convert the XML document into an XHTML document for a browser to parse.

To me the best solution for the tehcnology to evolve to is simply XML formatted data using any DTD, with an attached stylsheet to format the data according to standardized rules (ala WC3 recomendations). The presentation rules should be robust enough to handle any type of presentation. Bodda bing, bodda boom, your done. If we get there, then there’s not too much else we’ll need.

I’m not talking about seperating content from presentation on the publishing side—of course it’s great as a publisher to be able to cut and paste, format and reformat, rip, mix and burn. The problem is that once content reaches the user, it has always been in a definitive format, like a magazine, a record, or a stone tablet.

The web changed everything. Nowadays, being a content consumer is kind of like owning your own publishing house. Unfortunately, the assistants running your presses (an organizational unit called the Web Browser) don’t follow instructions well—constantly wrecking colors, printing off the margins, and choosing the wackiest of fonts. But mostly, they complain that the instructions are intentionally vague, insisting that the original authors have only provided general suggestions for layout and formatting. This is a mess worthy of a Pulitzer.

Benjamin suggested PDF—it would be *wonderful* if the whole web was PDFs (assuming of course Acrobat Reader was actually fast). Publishers could be assured that content would always render the same way, and users could still cut and paste, follow and share links, and interact through forms.

Unfortunately, the XHTML/CSS/broken browser model is here to stay. I don’t know how we’ll ever claw our way out.

Get back to focusing on the design? Seems a bit far fetched and a little under-thought. In a way it assumes that the design is center of attention.
What about on a handheld when there is no design. I’m mostly impressed if something works.

// Tables were clunky at times, but they were pretty straightforward to debug. When you saw something wrong on the page, you knew to go to the cell that looked funny and fix it. With CSS, the bug could be anywhere.

That sounds more or less like a CSS novice. But I’m sure all those comments above ^^ mine already discussed that.

Design debugging is easy. As all have already mentioned semantics, it should be a no-brainer to go find your parent inheriter, and fix the style issue at hand.

Well, I guess if design is not the center of attention, what is? Technology? I think we can agree that something that “works” is impressive, but design is often what makes something work… so that point is a little unclear to me.

Taking the longer view of things, I think back to applications like Hypercard. Hypercard allowed you to lay things out however you wanted and insert complex interactivity into a deck without any sort of difficult programming. I know it’s certainly possible for design of interactive sites to be this easy, but for the most part people have adapted to the presentation technologies, and have rarely challenged the status quo to push for a presentation technology that makes design truly easy.

You can describe how an expert in CSS has no trouble debugging… but it took nontrivial time to gain that expertise. Ultimately, this extra time amounts to a barrier to entry that will exclude many designers. It doesn’t really need to be like this. A presentation layer tech that respects pixel accurate layout with no hoops to jump through would save a whole lot of design and implementation time.

it would be wonderful if the whole web was PDFs
<speechless with apopleptic rage>wh… m… gn…?</speechless with apopleptic rage>
Aaaaaaaaaah! Be roasted over a slow fire for the very suggestion you should! Thin client demons to pursue your soul into the tenth generation! A curse upon your proprietry file formats!

<deep breaths>Calm, calm, must remain calm</deep breaths>

xHTML, CSS, XML et al all have their failings, but their major advantage which outweighs every problem is that they are general, non-proprietal markup languages that can be used to build more complex things with relative ease. Running the Web entirely off PDF, Word, PowerPoint or CorelDraw would crush it utterly; never mind the commercial and financial implications, what happens when Adobe / Microsoft / Acme Software goes broke / gets bought out etc? The entire web comes to a grinding halt whilst lawyers fight out who can and who can’t use their clients intellectual property. Tim Berners-Lee’s vision of a “free” Web built this magnificent infrastructure which we all take for granted on a daily basis and the guy still works hard now to keep it free and make it better.
Acrobat could lose all of its bloatware crap, load in a tenth of a second and support hypertext properly and it would still be the kiss of death. No-one in their right mind uses PDF to display major parts of their site and loading times has nothing whatsoever to do with it.

I’ve been designing websites since about 1996. Everything was tables, tables, tables, nested within more tables !! I had to maintain an entire intranet site at work, hundreds of pages.. all stuck in tables. Modifying the site was a NIGHTMARE ! That’s all we had for layout, so there was no help for it. The mere thought of a site redesign made me queasy back then.

When I started to learn CSS, it was mostly for displaying type, headings and such. Once CSS support in the browsers came along far enough, I dug deeper into CSS and finally made the switch to designing sites with NO TABLES unless there was a need to display tabular data. There are times when a table IS the better solution to present some types of content, but I style them with CSS. Font tags ?? aaaaaaaagghhhhhhhh !! (as I run screaming from the room at the thought). Again, its too much of a pain to maintain hundreds of thousands of tags, I’m glad to be rid of them ! I can change the typefaces for an entire site by changing just a couple of lines in a single css file.

The beauty of CSS and XHTML for me as a designer and site owner is the ease of maintenance. Marked up semantically, I can change my ENTIRE site’s design simply by changing ONE file - the CSS. I currently maintain a site that contains over 12,000 pages of information. It would cost me far more time and money to maintain this site if it were table-based. A recent site redesign, from start to finish including a new interface, took 4 months. Having to do all of that on a tables-based site would have taken us twice as long, at least.

There is currently no one-size-fits-all solution. Until ALL the browsers out there are standards-compliant and render CSS THE SAME WAY without the need for hacks, we designers are going to have to make compromises and use what works best for our client’s needs. CSS and XHTML, at least for me, is DEFINITELY the way to go. I don’t have time to fuss around maintaining table-based sites. Time is money for me and my clients.

I’ve happily joined the CSS/XHTML standards evangalists.. and I’m not looking back

O-B-V-I-O-U-S-L-Y, the horrific performance of Acrobat Reader and the quasi-propietary nature of the semi-open standard make PDF, as-is, a much worse choice than (X)HTML/CSS for the web. I know it’s difficult to seperate the practical experience of PDF (sucking) from this theoretical construct, but it’s necessary for my argument to work.

You say that that current web technologies “can be used to build more complex things with relative ease”. Have you ever tried to use a desktop publishing package to absolutely position text somewhere on a page? Or move around images, or draw (gasp!) diagonal lines? You don’t have to know ANYTHING about semantic markup, browser history, user agents strings or funny characters to do this. It’s orders of magnitude easier than chasing down CSS-browser-compliance-rabbit-holes, and the GUIs of desktop publishing packages still aren’t even that good yet!

Finally, I will say that the FREEDOM of HTML is not as much of a good thing as the STANDARD of HTML. That standard, however, is not defined by the W3C, as much as they want to believe it. It’s defined by the people who write browsers, and more generally, by the masses who choose to use particular browsers. Hence, the current insanity.

Kudos to Mr. Chi for mentioning Hypercard. There was a late 80’s software application that the web, for all its crazed self-audulation, has yet to beat.

I’m in love with CSS and every successive day of our relationship is better and better. But my love is not blind, and will not be unconditional until CSS learns to just PUT TWO THINGS NEXT TO EACH OTHER in a simple and breakproof way.

However, and this is odd because I’m not even a proper graphic designer, I have to admit I’m skeptical of the Separate Form and Content mantra as well. It seems as though this often leads to simplistic and rigid (or formless) forms that stiffly tolerate content as a regrettable but necessary contamination. It seems to me that users benefit most from forms designed to fit, complement, and enhance their content, not merely accept it. It’s like saying the most important part of a painting is the shape of the canvas, which is clever enough to seem true, but isn’t, really.

You guys (well, many of you) are nuts. Even in dead-tree land, practically all authors (of text) have exactly zilch to say about the layout of their final, published work.

Separating content from style (from data, from software, etc.) is good for semantics, and so on, sure. But its a boon for content maintenance and consistency. I’ve worked on sites with 6,500 individual table-based htmls, and also thousands of cssized pages. How much consistency do you think we got with the many html pages? How easy do you think it is to rebrand, add a new top level section or try a new concept /sitewide/ with a css-based layout?

Even in dead-paper design, separating content from layout is still a boon. Not when printed, sure, but during the design phase its crucial for speedy updates, revisions, fixes… How we did this with wax and bits of paper I’ll never be able to figure out.

Short answer to “css is hard” is that you need to try more, go to class or something. Overlapping elements especially means its a lot more flexible, even from a pure one-off design perspective. And once you get remotely used to it, its a snap to debug. And I’m not even that good a coder.

You guys (well, many of you) are nuts. Even in dead-tree land, practically all authors (of text) have exactly zilch to say about the layout of their final, published work.

Separating content from style (from data, from software, etc.) is good for semantics, and so on, sure. But its a boon for content maintenance and consistency. I’ve worked on sites with 6,500 individual table-based htmls, and also thousands of cssized pages. How much consistency do you think we got with the many html pages? How easy do you think it is to rebrand, add a new top level section or try a new concept /sitewide/ with a css-based layout?

Even in dead-paper design, separating content from layout is still a boon. Not when printed, sure, but during the design phase its crucial for speedy updates, revisions, fixes… How we did this with wax and bits of paper I’ll never be able to figure out.

Short answer to “css is hard” is that you need to try more, go to class or something. Overlapping elements especially means its a lot more flexible, even from a pure one-off design perspective. And once you get remotely used to it, its a snap to debug. And I’m not even that good a coder.

The best arguments against tables seem to boil down to “gee, it’s too bad that we didn’t use ASP/PHP templates at my first job… now I’m too shellshocked to consider it in a positive light”. Adding a header to 6,500 pages would still require touching them all, I’ve never seen anyone claim that CSS content-insertion is terribly usable (doesn’t work on IE, barely works on others).

Whether you do it through CSS, a templating system, a wiki, XML & XSL, AJAX database queries, or a little of each, it doesn’t matter what tool you use, all that matters is that you have a tool that doesn’t lock hundreds or thousands of pages into a single design and simplifies your life.

CSS has proven to be amazingly good for some stylings, at least as good as other options for many things, and really bad for other common uses. I’d think understanding the strengths and weaknesses of your tools would be a basic precept of being a professional, before you become the joke about the guy and the hammer.