Wednesday, February 4th, 2009
CSS for Layout. Another Rant
Category: CSS
The basic gist is:
While CSS should be used for styling, tables should be used for layout.
The author lays out annoyances such as, CSS floats:
Apparently the order matters. The reason that the order matters is that this layout, like all multi-column CSS layouts, is achieved with floats, and the way that floats get rendered depends on the order in which they appear. So we have not managed to separate content from presentation. How things appear on the screen still depends on the order in which they appear in the content. Worse, in order to be rendered properly, the order in which elements must appear is different from their natural flow in the layout.
And then shows tables and how he prefers them.
CSS purist may poo poo him and say “he is just dumb and doesn’t REALLY know CSS.” The problem though is that most developers run into exactly the pain that he describes. We’ve all been there. It drives you nuts and when frustrated what do you do? You fluster about and change CSS like a mad man until it kinda looks right. And, you never learn what the real problem was, and thus destined to make the same mistake again.
We need something better for layout. And, maybe a touch more than ASCII art layout? ;)
NOTE: There are some amazing things about CSS for layout. The way you can deal with flow is actually quite interesting, so it aint all bad (it isn’t GridBagLayout!)
What do you think?
Related Content:
It seems like a simple attribute on the table tag could clear this all up, and then we wouldn’t have to fight about it anymore. Something like “semantics=’none’” or “layout=’true’” or something. Another benefit to table layout that the OP didn’t mention was that IE6 renders table layout correctly.
I think our long drawn out discussion from last time still applies:
http://ajaxian.com/archives/css-and-tables-the-war-continues#comments
Agree that we need something better.
HOWEVER, the quote
“You fluster about and change CSS like a mad man until it kinda looks right. And, you never learn what the real problem was, and thus destined to make the same mistake again.”
it totally off. Only a crappy programmer will spend a significant amount of time working to find a solution to a problem and then not investigate the real cause. I’ll admit that there can be a learning curve to it, but anyone who’s worth a salt will try to learn the cause so-as not to have to struggle with it again.
You should use the BEST solution for the job, there is nothing wrong with using TABLE’s for layouts but it should be avoided as TABLE’s are there for tabular data. In the same sense using DIV’s for everything can also be wrong at times.
@tno thanks for the link… Looks like someone solved my issue there. Big thanks to @edeverett :) I can now be table on that one website.
Yeah, I must admit I do like the odd table, but I never use them because of the very real pain-in-the-arse factor when looping through data. I don’t want to say “every n, add some more html to create the row” VIVA LA NTH-SELECTOR!!!!
I still use http://giveupandusetables.com/ and it works fine for me. :D
If IE supported CSS table-layout would this even be an issue?
Could someone just propse a tag and let the rest of us get on with our day jobs please?
Oh FFS. An AJAX/HTML blog that doesn’t escape tags in comments. Nice work Ajaxian.
It was supposed to read:
“Could someone just propse a [LAYOUT] tag and let the rest of us get on with our day jobs please?”
P.S. test: < >
WTF? If you can’t understand CSS, you need to go take a course in page layout. Remember: the web originated as — and still remains, for the most part — a way to view pages of information. A few weeks with Quark or PageMaker and you’ll certainly understand why CSS is so complex — and why it works the way it does.
Tables have their place. I use at least a few in a really complex web app UI. But, by and large, CSS does quite fine. And IMHO, floats should be mainly used in text situations, not for page structure. Use box offsets for complex page structures, which, yes, need a hack or two in IE6+7, but work wonderfully in everything else.
If you don’t know how to create a simple layout using CSS, then probably you are not a frontender. This is not a negative thing, it’s resource abuse. To fumble around in frontend is another job then to fumble around in the backed.
That kills his entire argument. The only people who might take this jamoke seriously are non-professionals. Professionals would figure out what the issue was so they know how to work around it next time.
The entire argument about floats not working due to source order is bunk as well. Again, a true pro knows ways around these things.
There are always going to be people who just don’t ‘get’ CSS, but please, for the good of the industry, can we just ignore them? Dion, I’m disappointed that you would even post this article giving this guy ANY attention at all. This is about as stupid as someone saying that DOM scripting and progressive enhancement is too hard, and we should just go back to inline scripts and event handlers…..come on.
No, CSS is not perfect for layout, but that’s no reason to use tables.
Basically the blogger is saying table layouts are easier on his brain. That’s find with me. I think people should use whatever works best for themselves. … For me, CSS layout is easier on my brain. I’ve done a gazillion projects with a CSS layout and have seen it all. So I can solve any weird cross browser CSS bug in 5 minutes without putting much thought into it.
@jlbruno: +1. Markup is for content semantics and document structure. If you’re randomly “flustering with your layout until it kinda looks right”, you’re doing it wrong.
I worked at a magazine back when artists did layout with boards, x-acto knives, and rubber cement.
.
To me, layout with tables makes sense. It’s very physical. Although I’ve learned css float layout and I’m comfortable with it, I think it’s insane. Ridiculous. I bet anything we’ll see a movement back to tables or something like tables.
This is nonsense. The float issue disappears if you wrap your column tags in a div tag with clear both on them.
So the pattern is :[clear both div][floated div1] [/floated div1][floated div2] [/floated div2][/clear both div]
Then make sure all your floated divs are floated the same way(right/left). Set your margins as you need. It will display like the mockup image you are building off of in all major browsers
It’s pretty simple. I honestly don’t know what the fuss is about. Spend about three days laying out a site and you’ll learn quickly.
In fact you could concievably just set a global css declaration of div{clear:both;} and override it with .floatedLeftDiv{float:left;} and .floatedRightDiv{float:right;} and then append the class names to all of the divs you want floated left or right inside your container div.
There nothing new there, and i’m surprise to see this kind of idiocy here.
I’m sorry but layout with table are a clustering hell of problems, Markup become VERY hard to read in big sites, you got weird issues with your cells..etc..
That said, learning css is not hard and alot more powerful than table layout and better for web semantic. I always wondered why back-end dev always take the “easy” turn with table layout, just learn it god damnit.
You wont get something better than this. HTML5 will have better semantic markup but forget anything else.
I agree with Ron. However, for me the argument is much simpler.
If the result is the same, I will always take the path of least resistance. Why should I spend more time tweaking css-based 3-column layout if I can do the same thing with a table quicker and better? And it’s not much less flexible in long term either since at the end of the day you’re dealing with only one table.
CSS should be about simplicity and elegance – not hacks and unintuitive code.
Honestly, the CSS spec is just too complex to ask people to read it and fully comprehend it. Imagine you’re a newbie and you have to understand how positioning works. I would wager that most web professionals don’t fully understand CSS positioning.
.
Tools have to be periodically reviewed and redesigned to fit the needs of the time. CSS needs to be redesigned to fit the needs of modern web app development. If you doubt this in any way, go play around with doing layouts in flex for a bit, and then try to return to CSS and still think kindly of it.
.
Now, it’s true as some people say here that if you invest the effort to learn CSS you can bend it to your will. However, the investment required is a order of magnitude or two too large. If you look at layout systems like flex or swing, you can pick up how to do any sort of layout in 15 minutes. Doing the same with CSS takes days or weeks. That’s a learnability bug in the spec, and it needs to be fixed.
It never ceases to amaze me just how strongly people feel about using or not using tables. Seriously people, I really doubt that end users are looking at your HTML and critiquing your scripting ability based on if you are using pure CSS layouts (with the appropriate browser hacks) or not.
Tables tags are so old (as a feature of HTML) they work almost consistently across all browsers, and so they continue to be used. It is not the fault of the CSS specifications that tableless layouts are not more widely used but rather the inability of the various browser creators to make their browsers conform 100% to published specifications. Until this changes (or we all start using the same one browser) tables will continue to be used. Admittedly, things have been improving, but we are still not quite there yet.
…and just to add fuel to the fire, I’m sure that there are table geeks out there complaining that developers are not implementing tables correctly because they are not making use of the table header and footer tags.
There are a number of very real problems with floats. They won’t stretch to content for one thing. Let’s say I have an RSS feed on the left, and suddenly something with a slightly-longer-than-normal title comes in (maybe it has a really long German word that won’t wrap). Maybe I want my layout to stretch and not have it bleed out. Perhaps not the best example, but a real problem. As a CMS developer I don’t want ever to have to assume the widths of my panels (languages change, data changes, context changes, …); people who just lay out static pages are much more fortunate and I think often don’t understand the problems some of us face.
Another problem is it’s painful if you want different backgrounds on left, middle, and right. The only way I know to do it is with awful CSS hacks, JS, or by creating a background for the wrapper div that assumes the left/right width – which is not good because it means you can’t use em widths for left/right, which is a good idea if you want to support font scaling.
If you use ‘clear’ in the global layout you handicap yourself from using it within the content area. That’s why many dev’s use “overflow” to wrap things up.
I think both sides of the argument here are valid. CSS can be a god awful pain at times, and I think developers should really admit it and look forward to something better. But if IE did support the table model, things would be a lot better. At the same time, we all know it is bad to use tables for accessibility, page weight, seo, and semantic problems for other potential future tools.
A few years ago the CSS layout had a big argument on its own. On mobile devices, the mobile browser could rearange the content-floats so that they will fit on the screen of the mini display.
.
Today, even mobile browsers render the full page and resize it. So there is no need anymore for rearanging of elements.
.
I’m still not a big fan of table layout, but the mobile devices argument falls apart right now.
What CSS/HTML needs is “relational positioning” – something that goes beyond floating and relative/absolute positioning with pixels. CSS code should be able to express how elements are laid-out in a true relative position to one another.
For example, it would be really great to be able to express element B is anchored to element A, and B’s top starts at A’s bottom, and B’s right starts at A’s left. In CSS something like #elementB { anchor-id: “#elementA”; anchor-top: top; anchor-right: left; }
This would allow any element to be positioned anywhere in any order without having to worry about floating, clearing the float, or pixels. It could also be a nightmare to implement and make the spec even more vague.
My other dream is to have resolution independent units in CSS. Most designers would go gaga over the ability to specify a block’s height in inches or centimeters.
@RSarvas – Set overflow: auto on the container of the float and it will auto size to fit the floated content.
Tricks like this are one of the reasons table layouts are still popular, so not intuitive…
lazy and/or incompetent front-end builders use tables for layout. there’s really nothing else to it. if you know what you’re doing, most “issues” are resolved through proper design that comes with real-world experience.
.
sorry, but the “tables work in every browser” argument doesn’t hold much water any more. and if you’re still testing for IE5.5 or some other archaic browser, then you’re doing yourself and the rest of us a disservice.
Calling people “lazy” or “idiots” is a sign that you don’t have a good argument to make. You just want to bully people.
.
This could just be a matter of tools. I haven’t seen a CSS tool I liked. Make a tool that lets a designer lay things out in a sane way, and have it produce css that won’t make a developer vomit.
.
I honestly think we’re hobbled by css. I can think of many conversations where a developer told a designer that what the designer had in mind was too hard, even though it fit into a table layout nicely.
.
It seems clear that the model we’re using is defective if we keep having this same fight. If we had a layout-only table in all browsers, we wouldn’t be having this argument.
@Nosredna:
Maybe something like this? (I hope the comment system doesn’t slaughter it):
<grid>
<column>
<cell></cell>
<cell></cell>
<cell></cell>
</column>
<column>
<cell></cell>
<cell></cell>
<cell>
<row>
<cell></cell>
</row
</cell>
</column>
<row>
<cell></cell>
<cell></cell>
<cell></cell>
</row>
<row>
<cell></cell>
<cell></cell>
<cell>
<column>
<cell></cell>
</column>
</cell>
</row>
</grid>
Jaxon, while your intent was good, your instruction are incorrect. simply adding a “clear:both” to the wrapper div WILL NOT clear all the floats held with in.
What is needed is to add width:100%; so as to to trigger “hasLayout”
div.container {
border: 1px solid #F00;
width:100%;
overflow:auto;
}
the full article on this can be found here.
http://www.quirksmode.org/css/clearing.html
I use floats/positioning over tables, but I don’t think we should get in the habit of making excuses for floats and blinding ourselves to their many flaws just because they’re the more semantic alternative. “Floats are fine once you know how to use them” isn’t the answer. Tables and floats by themselves are both inadequate.
The grid is a fundamental component of graphic design, so when dealing with presentation we of course need a layout technique that’s complementary to the grid system. Tables provide this in ways that floats spectacularly don’t. Deep down I don’t think this guy is really advocating for going back to tables; he’s advocating for CSS that respects the grid. If he had this, he’d use it, but for now he’s stuck in this silly table/float dichotomy we’re all stuck in.
In a perfect world it’d be possible to create a table-like grid in the CSS layer that doesn’t require the rigid markup of a table which interferes with semantic integrity. Rules like “display: table-cell” don’t cut it. We need ways to chain elements together in the CSS so that their positions and dimensions are slaved to each other (similar to the anchoring mentioned by lionsburg).
Something that respects the grid (tables) AND respects semantics and accessibility (floats/positioning) is the only solution we could finally be happy with. I think (hope) we’ll finally have something like this 10 years from now, and we’ll wonder why we ever put up with tables and floats for so long.
No need. Just use existing markup and half an idea from microformats:
<table class="layout">In fact, I’d be willing to bet that for 95+% of cases, you don’t even need that — that there exist heuristics that could be used by semantic readers to automatically and correctly distinguish between a layout table and a semantic table for over 95% of cases.
One of these days when I’m bored I intend to test this hypothesis, but boredom doesn’t come easy these days. :)
Oh ya, further to Jaxon post, you can not just add margin to floated divs, as IE6 will double the margin you set (go figure..)
There is also a good quick fix to this. Just add “display: inline;” to your floated boxes.
http://www.positioniseverything.net/explorer/doubled-margin.html
so the complete cross browser solution is
div.container {
border: 1px solid #F00;
width:100%;
overflow:auto;
}
div.columnleft {
float: left;
width: 120px;
margin-left: 20px;
border: 1px solid #069;
display: inline;
}
This is 1
This is 2
This is 3
@pendensproditor: Thanks. That’s the least insane thing I’ve ever heard on the subject.
I <3 tables. I use them constantly. There’s something nice about valign=”middle” that saves a lot of trouble.
No, unless you’re going to make a law that those people should stop making web pages.
And the idea that the only people who are table-friendly and cranky with CSS just don’t know it? That’s flat-out wrong. I’ve done quite literally hundreds of CSS-only sites, and I even drank the kool-aid for a while. And I’m still ecstatic that CSS gives us far better tools than we had 10 years ago. But sometimes, tables are simpler and work better, and if I have any contempt for CSS, it comes from real experience coming to grips with it.
Sure it is. It’s exactly the reason. For many layouts, pure CSS just makes sense, and it’s what you should use there. Sometimes, though, CSS is not as simple or robust a tool for creating a given layout as tables are, and that’s exactly the situation in which you should use tables.
People act as if CSS layout is the goal. It’s not. You want markup that (in no particular order of importance):
1) Renders a given visual design effectively
2) Doesn’t break when arbitrary content is added.
3) Isn’t difficult for humans to read and edit
4) Conveys semantic information.
All of those things are possible with table layouts — yes, even correct conveyance of semantic information. And in addition, sometimes there are other constraints:
5) The project must be completed inside a limited budget of time or money
#2 and #5 are where I find CSS layout fails me most frequently (especially if I’m still supporting IE6, which, much as many coders would like it to just go away, is still well over 20% for a lot of visitor segments). And ultimately, those five criteria are the bottom line, they’re the real practical goals, not the tools you use to accomplish them.
Am I the only one that thinks ‘style’ and ‘layout’ are two different things? Where something is positioned on a page has nothing to do with it’s style, maybe what’s needed is a Cascading ‘Layout’ Sheet. Something that is *always* relative to itself so that the grid will grow as the content grows, with more robust rules for what to do if the content in a particular cell doesn’t fit.
The comments that people left in that blog post are very explicit:
“Yeah, YEAH! And you know what?! I shouldn’t have to use Javascript for fancy blinking text! I just want the BLINK tag back! In fact, do away with Javascript completely, it’s too complicated.”
or
“I think you’re a person that writes his letters in Excel. There’s no difference …”
The *easiest* thing to do would probably be to just start flipping burgers at McDonalds … ;)
Tables came out in Netscape 2.0 in 1996? Is there some reason that this feature was never improved upon? Fixing headers, dragging and dropping rows, selecting rows, striping? What haven’t tables received any love?
@Nosredna:
The fact that you are using some sort of “tool” to create CSS exemplifies my point exactly. I type out my styles manually through Aptana, and the auto-complete makes it very fast and easy. I don’t need a tool to visualize the styles, I do that in my head, then tweak them as necessary. If you don’t know what styles are available for elements, or the necessary tweaks you need to accomplish certain things (i.e. height:1%; to give layout) in a browser like IE6, you’re slacking at your job.
I’m not trying to bully anyone, I’m simply stating what I’ve learned through my own work and that of others. I’ve had to pickup projects where others left off, and sorting through poorly written or generated styles is a PITA.
As far as table layouts go, you will never see one on a Fortune 500 website that has to adhere to accessibility standards. They do have a purpose, but not for mainstream websites.
Are we back in the early 90′s again? Tables should never be used for layout, period. They were never designed to, the give fits to screen readers and make it very difficult to maintain a site.
If you can’t figure out CSS you shouldn’t be doing frontend development, just like if you can’t figure out the difference between and assignment operator and a comparison operator you shouldn’t be doing backend development.
“Apparently the order matters. The reason that the order matters is that this layout, like all multi-column CSS layouts, is achieved with floats, and the way that floats get rendered depends on the order in which they appear.” — And it doesn’t matter with a table? The fact is that if you code your HTML properly even the order of the elements wouldn’t matter that much. Take a look a CSS Zen Garden for proof.
@ajaxery
.
A bit presumptuous to assume I use a tool for layout. I don’t use a tool. Like you, I work in Aptana. I do CSS layouts. But a good grid or table layout system would make the web as a whole better overall.
.
I’m glad there are superior beings like you around, but there aren’t enough of you, and it doesn’t excuse the sorry-ass state of the art. Layout should be done by artists. And they should need to learn the ins and outs of a crazy system to do their work.
.
I don’t believe the future is like this.
.
P.S. Checked out your Fortune 500 claim. Isn’t McDonalds in the Fortune 500 any more? Tables FOR LAYOUT all over their corporate home site. Use Web Developer Toolbar’s Outline/Outline Tables/Outline Table Cells and you’ll see tables all over the Fortune 500–enough to keep you awake at screaming all night.
.
There are reasons, and it’s simplistic to assume laziness. See how easy it was to assume I use a tool? That’s what comes of zealotry.
Nod, page layout does not equal tabular data.
.
Tables have symantic meaning, not only for screenreaders, but also for webcrawler technologies. Imagine: Google Search for all Mortgage tables.
[table summary="mortgage rates"] Hello, anyone?
.
Web standards will NEVER EVER EVER go back to table layouts and any designer/developer that goes back to table layouts actually harms the client and visitors looking to use nifty tools to scan the web for the data they want/need.
.
I can’t believe this is even being discussed…
IBM and GE are clean. But not Wal*Mart, or Home Depot. Sears and KMart use tables in some layout. eBay and Amazon use tables for layout. Those were the first ones I checked.
.
The world is not as you believe it to be, apparently.
I don’t understand the argument here, tabular data aside, does anybody have a valid compliant against using CSS? Because I’ve never heard one, What could possibly be simpler than creating a container, setting style to clear both, and float your inner divs all the same direction (left, right)?
Just checked out the top 10 Fortune 500 companies (2008). 5 do and 5 don’t. I think that dispels the idea that you won’t find tables for layout in the Fortune 500. I’m done looking.
.
WalMart tables
Exxon tables
Chevron none
GM none
Conoco Phillips tables
GE none
Ford none
Citi (tons, but not on front page)
Bank of America (holy cow–full of tables)
AT&T none
I don’t find that accusation particularly true, and I’m speaking as a person who knows the stuff you’re talking about, quite possibly as well as you do. Part of this is, like I said above, the goal isn’t to use CSS for layout — the actual goals are something else entirely, and if you can use tables to fit the bill, then you’re doing your job as well as anybody else.
But the other part of this is that the kind of knowledge you’re talking can come pretty dear in terms of time. This is especially true if you started doing it, say, six years ago instead of three, back when IE5.5 (and IE 5 Mac!) was something you still HAD to support, and everybody was still trying to figure out where all the bodies were buried in IE 6. But it’s still fairly true now. And that’s fine if being a first-rate front-end dev is one of your goals. It’s one of the reasons why I personally chose to do it. But don’t discount the cost of that time. Time spending that is time not spent learning a dozen other technologies, it’s time not spent exercising, it’s time not spent on an outside hobby or your family or friends. And given that in particular a lot of web developers have to wear more than one hat, I think there’s something to be said for choosing not to sink your time into CSS Positioning. It may have nothing to do with laziness and everything to do with priorities.
Here’s another misconception: accessibility == CSS Layout.
It’s not only true that accessibility goes beyond this, it’s true that it’s not necessary. Lynx could generally render thoughtfully created pages that used tables for layout 10 years ago, and it’s not a particularly sophisticated piece of software. A screen reader that hasn’t exceeded that level of capability can neither lay blame on front-end devs nor is it likely to be part of a brilliant accessible/semantic web future.
CSS sucks. A lot. But tables suck more, especially if you’re hand coding anything. The markup for tables is bulky, and confusing. If you’ve ever had to swim through a pool of tag soup, you know what I’m talking about. Once you’ve seen what you can do with CSS it’s very difficult to go back to drowning in tags.
But, CSS is indeed confusing, and it needs to be way way better. I think us, and the web, we kind of got off on the wrong foot. It’s wrong that we should have to hand code anything to do with layout. Artists aren’t programmers, and programmer’s arent’ artists. But at some point we need to come together, and make tools that artists are actually able to use to make art. It’s just a shame, that to a certain extent, this goal runs counter to having “semantic” html.
This is not a programming problem. This is an interface problem. The basic idea of CSS is sound, but we haven’t yet seen a visual interface that 1> doesn’t expose the source code to the user, 2> doesn’t produce garbage code out the back end, that programmers have to swim through.
I think it’s possible to meet both goals, but the problem is that there’s very few, if any, capable people that are motivated to solve both problems simultaneously. All the tools available satisfy only one or the other.
Let’s not forget the sites with 500 pages that have the design layout baked into static html pages. And then, you are asked to redesign the site. Are we really so eager to rush back into that world?
Using XHTML/CSS properly and maintainable while guarding semantics and webstandards requires a skilllevel equal to that of an average backend programmer. Most companies still don’t value a good frontend developer, so they let their backenders or a design company create the HTML or outsource it to the cheapest freelance frontender (html is not rocketscience right?). Backend developers don’t waste their time learning webstandards and semantics (with right) and design companies are too busy making pretty sellable pictures and/or animations, so it’s also very rare to find a good front end developer there.
.
And even if the design company delivers impecable XHTML/CSS, the backenders who implement it always have to tweak and mess it up because their chosen CMS/Portal system doesn’t support it properly or they change the HTML to accomodate their preview mode in their admin side and deploy the same changed html to the front end as well.
.
Or worse, the design company finishes it’s contract, delivered fantastic HTML but does not support it. The maintaining party then messes up the HTML and decides to drastically alter it using tables, ignorant of webstandards and semantics.
.
More then often, frontend, because it’s quite easy to reach an acceptable visual result with table layouts, gets sacrificed a lot as well. Using the budget mainly for overenginered backends or to pay for the developer who took 5 weeks to implement a simple backend form validation system. More then often, project managers and clients alike tend to think; “if it looks ok, it’s probably ok”, untill they want to see their SEO indexing results…
.
People need to realize, SEO is big business and it becomes more unforgiving as technologies expand.
.
This is the environment the web industry finds itself in atm. and through the coverage of websites like A List Apart and Zen Garden, along with countless of articles as to why people should use CSS for layout, it has improved a lot in the last 5 years. But every now and then, a blog, post, article surfaces which question the wisdom and knowledge of the last 5 years with 2 simple arguments:
- Table layout is easier.
- Table layout is faster.
.
Well… uploading a PDF is cheaper then using a CMS system. I’m sure if you put your mind to it we can come up with a lot of cheaper, easier and faster solutions which would make us all unemployed but worse, it would make the web a worse place.
Tables are bulky and sucky and pollute the document, yes.
But to get your layouts right in CSS requires not just a lot of tricks (like knowing about “overflow: auto” and such), but a lot of lame hacks — nested divs, divs with no content, background images, javascript to detect OffsetHeight, etc.
When you’re done with all the hacks (and these hacks are necessary when having to match professional designers’ work), your document is bulky, sucky, and polluted. It’s a big PITA.
@jamienk
No, it really doesn’t… With 5 to 6 divs and a few css lines, you can basically have your layout grid (with margins and all!)… It takes more work to create a dropdown menu in javascript or to even grab 1 from the shelf and implement it (properly)…
.
Standard 3 column layout with header and footer:
http://www.alistapart.com/articles/holygrail
.
If your layout is more complex, still use basics, build a layout block within a layout and so on.
Any code has precisely the semantics a reader can pull out of it. Google is actually a prime example of this. The semantics of the anchor tag were not engineered or specified to be a vote of confidence in a given page, but it roughly turns out that way, especially if you do some contextual data mining. Tables weren’t originally intended as a layout tool, but some smart designers realized they could be used that way, and if you’re willing to do a little contextual analysis, it’s not hard to figure out which tables are for layout and which are tabular data.
Yes.
Of the top of my head, things that don’t require a second thought using tables that may be difficult (and are generally more involved) in CSS include:
* Vertical centering on elements with arbitrary heights. Doable if you know the right (and recent) hacks and the containing element’s height, but certainly not as easy as vertical-align.
* columns that need to be the same height. Especially if the defining visual elements of the column aren’t composable into a single background image (say, equal height rounded corner columns — particularly liquid width equal height rounded corner columns).
* certain situations in which you need an element that’s both height/width liquid which will also strictly contain arbitrary content without hiding, clipping, or letting any of it appear outside the border of the element.
* “gap” columns that may have no other width dependencies other than an inversion of other widths (in fact, CSS is sortof a pain for any dimension that’s not either fixed or proportional to a container).
* precisely proportional columns, with fixed-width padding, no extra markup (OK, OK, easy enough with an additional div for each column, but it would have been simplicity itself in CSS if only we’d gone with the MS box model instead of the W3C’s…)
And please don’t respond with the latest clever hacks. I’m aware that you can find workarounds for just about anything, and when it matters to me, I usually do. And if all else fails, you can fix almost anything with Javascript. The point is that everything I’ve mentioned above rarely requires more than a moment’s thought to work out with tables, even if your experience is minimal.
None of this takes away from the real power CSS positioning puts in your hands. But ignoring its limitations and casting aspersions on people who choose other tools is wrong.
Add to that: table layouts can be used without the any of the implied tradeoffs. Which is why the question persists.
@Nosredna
Hey dude, I’m sorry if I offended you. You said, “This could just be a matter of tools. I haven’t seen a CSS tool I liked. Make a tool that lets a designer lay things out in a sane way, and have it produce css that won’t make a developer vomit.” I thought you meant that you were using GoLive or Dreamweaver or some other abomination. I didn’t mean to vent on you. I just recently had to clean up some other developers code and it was really nasty. I’m just really tired of people who claim to know (X)HTML/CSS but really know nothing of the sort.
Those Fortune 500 companies that still use tables are probably in the process of upgrading their websites (hopefully). Remember how Target got sued and lost because their website wasn’t accessible? I think most companies are following suit. Tables (for layout) and screen readers don’t mix very well.
I’ve done work on some of those GE and IBM sites, mainly online annual reports. If I would’ve used tables, I would’ve gotten fired and probably never hired in the first place. IBM and GE both have rigorous standards and all pages must be semantic and accessible. Tables are used for tabular data only.
@BenGerrissen:
I’m with you. There’s definitely not a lot of front-end builders who are aware of accessibility, semantics and SEO as it relates to page structure.
Table layouts may be easier. They serve a purpose to those just learning HTML layouts. But, using tables for layout is simply the wrong way to do it.
@ajaxery,
.
No problem. I don’t want to go back to the bad old days of tables. But I’m not happy with css either. I just get the feeling that the css guys are so zealous they’re not even listening anymore.
.
I think it’s really instructive to look where the smart guys use tables and try to figure out why. Here’s what I’ve come up with. I just went back and looked at the “good” Fortune 500 sites, and I looked at some other sites that use just a sprinkling of tables.
.
1) A lot of the pure css sites are fixed, not fluid. They are very brittle. They either don’t let you increase the size of the font, or they fall apart badly when you increase it. Sites with tables are less brittle, since the table adjusts so well to content.
.
2) Even sites that are almost all CSS have certain common uses of tables. The classic is, say, 5 or 6 equal-sized images in a row. Or Twitter’s left/right division, or the small bits on stackoverflow.com.
.
In my ideal world, there’d be a way to split divs into proportional parts, EITHER left or right (not both). That would get rid of almost every “useful” table I see around. Honestly, I think that’s all we need. Should I write it up in a blog entry? Would I get anyone thinking, or would we just get more yelling?
On the IBM site, two increases in text size (Chrome) is enough on some pages to obscure words behind pictures. Probably wouldn’t happen with a table layout.
.
GE doesn’t let most text scale, but some does an overlaps other text, make both sentences unreadable.
.
Not impressed.
This is a catechism, not an argument.
Yourself included, apparently.
@Nosredna:
I’m curious where you see this (url?). Text-size increases work just fine for me in Firefox for IBM and GE sites. In IE8, I see some issues on the IBM site using ‘Largest’ text size. And GE doesn’t budge at all. I know there’s IE6 limitations on text-size increases when you use ‘px’ instead of ‘em,’ but for the other browsers, it should be fine up to a point. But if you zoom the entire page, everything should be fine. IE8, Firefox, Safari and I’m sure other do this by default (ctrl +). I’m sure someone with poor eyesight would opt for a full page zoom over just text, but I don’t know that for a fact.
I didn’t work on these pages at all.
@westonc:
“Yourself included, apparently.”
I’m sorry, what are you referring to?
I’m referring to the misconception that using tables for layout necessarily has a negative effect on SEO, accessibility, and semantics. You implied that anyone who’d use table for layout is unaware of these effects. I haven’t seen any evidence or argument that supports the idea these effects are a central issue.
Particularly SEO. No reliable source of information I’ve encountered has gone beyond suggesting that specific semantics (title, headings, links, in some situations alt text and title attributes, a few other very specific tags) and well-formed markup have real impact on the searchability or ranking of the site.
Semantics I’ve addressed in a number of comments above, and I get mixed reports about screenreaders (including second-hand remarks from actual blind people stating that *frames based* sites of all things are actually an advantage), and as I said earlier, even something as simple as Lynx has been able to work with the dichotomy between different types of tabular markup as far back as 10 years ago. (see http://lynx.isc.org/current/README.TRST )
The bottom line seems to be that despite a lot of handwringing over the repurposing of tabular markup, it doesn’t seem present a real obstacle in practice.
@ajaxery. I was using Chrome. Firefox’s scaling is very nice indeed. Still, table based layouts are usually more robust with magnification of text. And we often end up with fixed, rather than fluid, designs with css. And we often get fonts that won’t size.
.
I’m hearing that devs love css, but I’m seeing limited designs as a result.
Sometimes, while trying not to use tables, we end up using unsemantic wrapper divs or get a pseudo-table out of a series of ul elements or divs, etc, which is also unsemantic.
I think tables are great.
Hmmm… I think that CSS is great at styling documents, thats what it was invented for. However a PAGE is the union of the DOCUMENT (the content) and the LAYOUT (the navigation and overall page layout). The most semantic solution would be to separate the layout elements from the content. I am currently experimenting with a system that applies the layout (table layouts for simplicity, reliability and lack of gotchas) in javascript before the page is rendered. So, the HTML sent over the wire is clean and table free, but the layout (using tables if you want) is applied client side. Thus search spiders and screen readers still see the nice semantic document, but browsers see the nice layout… Interesting idea?
The false dichotomy between CSS and tables is not the issue here. The issue is that you’re asked to build a house, and you get to choose between a crooked hammer and a bent chisel. Both tools are sub-par compared to other development platforms.
Here are a couple of blog posts I wrote on this.
1) Why neither CSS and tables are the right job for layout: http://onewheeledbicycle.com/2009/02/05/page-document-layout/
2) My ideal solution (that will never happen):
http://onewheeledbicycle.com/2009/02/05/html-layouts-ideal-solution-idea-1/
And while the crowd that stands for all things goods cheers, “crooked hammer” and shuns “bent chisel”, the crowd that stands for all things logical asks, “what benefit is there of using top-grade concrete when your building a house on shallow foundation.”
aljames, great idea. But do you serve something else for people without JavaScript?
Just one word: XUL
‹hbox› and ‹vbox›, along with the ‘flex’ parameter, beat your puny tables or CSS hacks.
@westonc:
I agree for the most part. I guess I was trying to say that tables are generally bad for accessibility. Although from what I understand, most screen readers are highly customized based on user preference. There may be a tables-based algorithm that deals with them just fine. If you look at it logically, the screen reader would read the site from the top down. It would expect there to be header tags for each major section. Starting from the top, that would be page title, then page navigation, then page content, then a sub-nav (if present), then the footer. Usually people would tab through these sections very fast to find what they are looking for. I personally don’t think tables work well with this approach.
Maybe when I’m 80+ years old and blind, I’ll finally understand.
link at the top of the article is broken…
:)
Document looks like this (visual order):
1.) Portal navigation
2.) Banner (with page title)
3.) Site Navigation
4.) Content
5.) Banner adds.
6.) Footer (disclaimer/privacy etc)
More solid to do this with tables.
However, for better SEO rankings (of your entire sites content and not just the frontpage!) it’s appearantly better to have the following structure (SEO Specialists hired by clients frequently demand this):
1.) Page title
2.) content
3.) Site Navigation
4.) Portal Navigation
5.) Footer
6.) Adds
SEO is not just about getting your website up high in search results on the obvious topics, but to push all your site’s content pages up high on the search listings. The visual presentation and interface, is not the logical order.
This is moderatly easy with floats whilst still keeping your layout grid and content components decoupled. This is also doable with tables, but the means of achieving this makes the use of tables redundant to begin with…
Also when you work with portal or complex cms systems, you get several layers of HTML, your layouts gets cut up into pieces and each piece will be seperatly maintained and changed over a period of time according to the customers whishes. I’ve seen it all too often in my career, that table layouts actually cause so much maintenance issues in these kind of environments, it actually doubled or even trippled the workload. Whereas with CSS, all your content components are portable and exchangeable by default (unless you’re really bad at CSS/HTML).
Another reason not to use table layouts and designers will most likely agree with me, is that it makes it very hard to theme your pages. If you use CSS layouts, you can just make a new stylesheet without touching your templates and basically reorder the visual presentation. If you use tables, you’re pretty much stuck to the dictated table order and can only theme your pages by creating new templates and restart the whole frontend process all over again. This was the whole point of Zen Garden…
The number 1 reason imo. not to use tables, is that it prevents you from actually learning CSS well. Everyone can write HTML and CSS, but it’s like chess, it takes dedication to master it.
Tbh… I want you all to keep using tables… It makes guys like me make the big bucks… So… erm.. proceed and forget what I said…
If a layout basically IS tabular, then a layout who’s elements stretch to accommodate content, and to match their neighbours (two big capabilities of tables) is needed.
That’s why CSS is getting display:table display:table-row and display:table-cell.
It’s true that when you haven’t dealt with CSS much, it can be nearly impossible to accomplish what you want. However, tables aren’t nearly as flexible as CSS. With CSS, I can make a three column layout with a header and footer and let the content order be logo and site info, center column, left column, right column, navigation (displays in the header), and footer. You could never do that with tables.
Maybe more projects should hire capable front-end developers who know the ins and outs of browser support and CSS quirks like the back of their hands.
CSS… tables… WHO CARES? Aren’t we all doing our layouts in Javascript these days anyway?!? :)
-
I’m currently working on a massive project using Ext JS as the foundation and it’s amazing just how little HTML and CSS I’m actually doing now versus what I was doing previously. Oh, there’s of course bits of CSS sprinkled in, but it’s largely to do true styling, i.e., colors and fonts and that stuff. Hell, I’d go so far as to say that the way we’re using CSS now is *MORE* correct in terms of what CSS is supposed to be used for than what we were previously doing when we were doing layout with it too!
-
Isn’t this the future that makes the CSS vs. tables discussion kind of superfluous? I say that only half-jokingly… obviously there’s plenty of need for web development where Javascript isn’t prevalent, but let’s face it, devices of *ANY* sort that don’t fairly fully support Javascript and associated Ajax techniques are shrinking in number by the day. Hell, the otherwise piece of crap PocketIE I carry around with me on my phone is more powerful and feature-rich than any browser that was available to me just a few years ago on my PC! That situation is only likely to improve as time marches forward.
-
I say we all adopt a good, solid RIA framework, Ext JS being by preference but you can choose as you see fit, and stop having this CSS vs. tables debate every few weeks :)
CSS… tables… WHO CARES?
Goverment institutions, Knowledge centers, Enterprise and multi-national companies, basically any client with huge ammounts of data which needs to be accessible by their target audience.
Aren’t we all doing our layouts in Javascript these days anyway?!? :)
Would love to, but javascript layouts to the extend of Ext JS and even ajax driven websites turn out to be very bad for SEO and accessibility unless you make an alternative, in which CSS becomes a major factor.
Tbh. client sided XML and XSLT can easily provide the solution if developed and supported more with search engines jumping on the bandwagon. And even ajax can be accessible in an XML/XSLT driven website as long as you use the links in the XML and not embed data providers in your javascript.
I really need to look into XUL…