tags:

views:

1238

answers:

14

looking at the soure code for stackoverflow, i noticed they have used tables and inline CSS quite a bit. also something i found odd was use of inline table attribute formatting.

<table width="100%">

I'm just curious if there was any specific reason(s) to why they used tables to structure their template instead of the popular (or used to be popular) DIVs.

as well...the purpose of using CSS includes and using inline CSS on the same page ( i know there is probably a great answer/solution(s) for this...i'm just curious to what they are)

i understand there is nothing wrong with using tables for tabular data...but in this case stackoverflows tables are used for structure

+22  A: 

Having not been involved in SO development, I only speak generally:

I've found that tables are often easier and more consistent across browsers than CSS-based layouts.

Also, emitting random CSS here and there often happens when trying to get things done. It can be refactored later, I suppose.

With respect to why they chose to set a table's width in HTML instead of CSS, I couldn't say.

I know that SO used a real, honest to goodness designer when they started. I don't know, though, if that designer gave them an image of what the site should look like or actual markup.

Please don't flame me for saying so. We're not all CSS ninjas.

Michael Haren
Yes but why the width attribute on tables rather than a CSS class with width: 100%?
cletus
Because, sadly, they do different things.
Sparr
exactly?....i would be interested to see what Atwood or Spolsky would have to say on this....i'm sure there is a good reason
dezwald
Call in and leave it as a question for their podcast.
EBGreen
Hopefully, but I wouldn't be surprised if it's as simple as "it works." They seem to be practical people.
Michael Haren
good idea!...will do.
dezwald
It's not hard to built tableless layouts after you've done a few.
dylanfm
Yeah, but unless you add an obscene amount of extra markup, they don't behave consistently across a wide enough spectrum of browsers. Keep in mind that some of us are still stuck using IE6 at work for various reasons - legit (upgrading breaks commercial apps that the vendor won't upgrade)/otherwise.
AnonJr
Steve Perks
A recent check of the source code shows that SO actually does use DIVs instead of tables in a lot of places--this might be new since this question was asked.
Michael Haren
+7  A: 

Tables are not evil, but certain uses of them (which used to be everywhere) are evil. Namely, using spacers, nested cells, etc, to control margin and padding.

Even though everyone now a days talk about layout with css and divs, the truth of the matter is css is awful when it comes to layout. You can only do so much. Look at some suggested solutions to get 2 or 3 column layouts using css, they all suck. Throwing a <table><tr><td id="left-column"><td id="right-column"></tr></table> is a lot easier.

css is just not suitable for non-trivial layout (and by that, I mean pure div/css)

The table solution I just threw above needs to use css to control width and padding and borders and background images, etc.

hasen j
"they all suck" — Not so… the "Holy Grail" layout: http://www.alistapart.com/articles/holygrail
Ben Blank
I think you can do some pretty complicated layouts with CSS. You just may not have any hair at the end (ask my wife).
Craig
thanks for link to holygrail, awesome read.
Tom Anderson
I can't imagine why anyone would think this answer is offensive, if you don't agree vote down but there is nothing offensive in the answer.
AnthonyWJones
I'm assuming it was due to the original post language. Check the edits.
EBGreen
Rubbish. You can do more with CSS than with Tables.
EnderMB
Sure, tables can't do alot of things, just like css can't do alot of things. You can't change the font (color,size,type) using tables. You can't control layout (without pulling your hair anyway) using css.
hasen j
CSS is far superior to tables. Admittedly supporting IE can be a pain, but once you learn how to make cross browser friendly html/css, its not really that difficult.
Andrew Bullock
I hate to be rude but it is not hard to change a layout using CSS. Once you get your head around floats you can make many different types of layout. A visit to CSS Zen Garden will demonstrate that.
EnderMB
floats are evil .. much more evil than tables could ever be. css garden is a good example of something theoretical that doesn't apply to real life.
hasen j
Floats are only evil if you can't use them. Check out CSS Vault for real examples of great design and CSS work and you'll see that tables for structure is an absolute no-go area. http://cssvault.com/
EnderMB
SO is so not a complicated layout. To say that this site needed tables to counter css's downfalls is weak.
Steve Perks
anything beyond 2-columns is complicated without tables.
hasen j
+19  A: 

SO was probably written by programmers, not web developers.

Jough
Careful...them's fightin' words. ;)
Lieutenant Frost
I have nothing against web developers. Both Programming and Web Development have their place, but they are completely seperate worlds.It's like saying web developers shouldn't be designers. Perhaps SO just hasn't hired a designer?
Jough
I should also say that I have nothing against programmers either, as I am one ;)
Jough
They DID hire a designer.
Michael Haren
Just not a web developer.
Steve Perks
A: 

CSS is great and can really simplify your markup, however, sometimes aligning content with tables is just easier and more reliable. Also for code generated dynamically some of the pain points for non-CSS based styling are less bad. Specifically, since you are dynamically, creating the markup you can re-factor the styling elements in the functional code.

As for the in-line styles, I often use these when I'm building a page and then try to re-factor them into an external sheet later. This makes it a little easier for my testing (no need to do a hard refresh) and changes are in one file instead of two.

Brian Fisher
+2  A: 

Jeff and his team were getting it done quick and dirty. This was a very quick development cycle, without the time to refactor out much of the clutter.

And face it - unless you are an expert, CSS is time consuming for table structures.

Inline styles and included css are just a sign they were trying to get it done, not worrying (at least for the first iteration) about the "right" way of doing it. The right way was whatever worked and got it done fast.

Carlton Jenke
CSS is time consuming if you don't know what you are doing. If you do, it is just as quick because you often end typing less and spending less time on maintenance. Quick and dirty development (because you dont have the skills to do it properly) is fine, just dont blame it on CSS.
CJM
+27  A: 

Tables vs. Divs is a pointless holy war.

There are specific issues with using tables in particular ways for layout that can cause problems. One of these is building an entire site layout in a single table in order to handle margins and placement -- because of the way tables are rendered this frequently means a website will not render progressively by the browser engine as the content downloads, and can only be rendered after the entire thing has been received. For a large page or slow modem user, they may be staring at a blank page for quite a while, which is a "Bad Thing". Never mind a lot of the inconsistencies in table rendering in the mozilla/ie5 generation of browsers that made consistent cross-browser table layouts somewhat painful, especially with images in the cells.

Supporters of the pure div path like to talk about content vs. presentation, because in theory HTML 4.01 is pure content, all of it meaningful. The divs provide meaningful organizational structure in an abstract sense, which is then given presentation exclusively by CSS. In these arguments, tables are valid only if being used to contain actual tabular data. Of course, this ignores the fact that for any sufficiently complex layout, there are almost always quite a few empty divs floating around simply to support the necessary hooks for presentation CSS, breaking the first level of this abstraction. Once this abstraction is broken, there's no law stating that, when your layout simply requires a presentation hook in the HTML that has no meaningful content, a div is somehow more appropriate than a table. If you are stuck with the choice of a meaningless div or a meaningless table in order to make your layout work, choose whichever is easier.

In the end, it's about being aware of the limitations in all methods and using the one that is most appropriate. There are many cases where using a table is simply easier than setting up a pointless (i.e. not-content-meaningful) array of divs, and the table rendering limitations don't apply. If the table is small and represents a minor chunk of the interior content, the rendering delay is not relevant.

nezroy
I stopped using tables for structural layout about 2 years ago, and I have NEVER added an empty element to help with structure. It is perfectly fine to add divs and spans for help with structure, but they should still contain content.
Steve Perks
correction, since I stopped using tables for structural layout, I have NEVER added and empty element...
Steve Perks
I really agree with you're pragmatic approach to this problem. To really take advantage of CSS does require using div's and spans in the ways you describe... Take a look at CSS Zen Garden for a wicked example of leaving CSS hooks in HTML....
dicroce
You may not have added an empty element, but you have added plenty of browser specific hacks or javascript correction code --both of which are awful. Or you create only simple pages.
foljs
That would be partly correct. I have gone through the learning process by adding hacks, but once you get used to it, the cleaner you make your HTML/css the easier it is to get it to look and behave the way you need it. My premise is that if it's not working, you probably need to remove something rather than add something.
Steve Perks
+1  A: 

Tables and layout

SO's layout is not based on tables.

At a quick glance, I'd say SO layout is 80% div-based and 20% table-based. Tables are used in the header and on the "badges" box. Table use is appropriate for badges IMHO (it's a list of items, after all), not so good for the header.
Anywhere else, divs are used.

Inline CSS

Again, many inline definitions are used (probably to quickly mockup site's structure), but SO correctly uses also css (to style the divs and to provide print formatting).

friol
Ahem. If it's a _list_ of items, there's a _list_ element that's much more appropriate than a table. But what do I know?
Adriano Varoli Piazza
I think a table with only one <td> per row is acceptable too, in this case. Anyway, we're not in front of a "div vs. table" dilemma here.
friol
+7  A: 

Give up and use tables

Marius
This is a typo right? Should this not have been written "Gave up..."
Steve Perks
http://shouldiusetablesforlayout.com/
alex
A: 

My thougths would be they went with table because (apart from the argument table vs css)

  • They needed to get the functionality get out rolled quickly to have an opinion
  • After all this is just the public beta.
  • They were experimenting with ASP.NET MVC more and layout issues less
  • SO is all about programming questions and answers and at the end that what matters.
  • SO is all about recognizing the contributors by rewarding points and badges which it does quite decently (this may also be a controversial topic).
  • and so on....
rajesh pillai
+1  A: 

"css is too hard" and "tables are quicker and easier" excuses, coupled with some down right misgivings about what's wrong with the use of tables for structural markup.

The question is asking why SO chose to use tables, inline css, etc., to which I think the answer is probably nothing more than that either they aren't familiar with graceful degradation and semantics, or they didn't consider it important enough to devote the time and resources.

There's nothing wrong with not knowing css, but to dismiss semantic markup and the proper use of css just because you don't know it is just WRONG.

To champion that your site looks the same in every browser using tables, while not giving a seconds thought to those that don't use a visual browser smacks of selfishness - that's a strong word, and I apologize for the tone, as I don't intend to insult.

BTW - I take umbrage at the idea that the use of tables for structural markup is a 'holy war'. While some might think that Semantic markup is overly championed, it is not based upon blind faith.

Steve Perks
It is not *always* based upon blind faith - but I've found an unfortunately high percentage of those for whom it is...
AnonJr
Some people might not be able to articulate what it is that they understand, but I suspect that they do 'get it'. There is a lot of rationale behind semantic markup...
Steve Perks
+3  A: 

Because Internet Explorer does not support the display:table CSS property, which is what provides the grid-like layout model (equivalent to how html tables are rendered). The grid-model is the simplest and most flexible way to model many layouts.

So you have three choices, none of them attractive:

  • sacrifice support for Internet Explorer (all other modern browsers supports display:table property, which have been part of the CSS2 standard for more than a decade)
  • use cumbersome CSS workarounds which are costly and hard to maintain.
  • sacrifice semantic purity and use TABLE-elements.

SO chose the last option, probably because they think support for Internet Explorer users is more important than support for disabled users, and because they wanted something that was quick to develop and simple to maintain.

JacquesB
So you claim that the SO layout cannot be remade in pure, valid CSS without tables for structure? Sounds like a challenge to me.
EnderMB
No, I claim that a pure CSS solution (without display:table) will be more complex and harder to maintain. See the second dot in the list :-)
JacquesB
There is absolutely nothing wrong with HTML tables - for rendering tabular data. If you knew what you were doing, you could build SO with CSS layout just as quickly, working on all major browsers, and probably with a smaller footprint (and without needing display:table or it's workarounds)
CJM
IE6 does however support display:inline-block, which could easily replace half the tables here with no sloppy workarounds.
Ant P.
+1  A: 

I have no idea, but the only explanation I can come up with is that Jeff isn't as supportive of web standards as he'd like us to think and none of the team are that hot on CSS. Programmers often use cross-browser-ness, ease-of-use and numerous other supposed time benefits to excuse their lack of CSS skills. And I don't mean that as a criticism, they're probably really good at programming C#/Java/Ruby/SQL/whatever, they just can't seem to admit that they don't really know something as well us a bunch of polo-neck wearing, Mac Book wielding designers...

roryf
+2  A: 

IE8 will be the last major browser to finally add support for the CSS display: table-* values, so the distinction will go away. Hopefully this will end the whining about how hard CSS is, and people can stop polluting markup with presentation.

brianary
Except it will take another 5 years for IE6 to fully die out, and 10 years for IE7, so maybee in 2019 this will apply:-)
JoshBerke
I think you'll find that the uptake for IE is pretty fast, since they push the upgrades out automatically. Right now Microsoft is pushing a utility to *block* IE8 in corp. environments.
brianary
+1: less whining is always a good reason.
Charles Stewart
+1  A: 

I'm a reasonably smart person, not too far below average at least, but I find css layout totally unintuitive. Tables are extremely intuitive. I think one measure of a good technology is how often you have to refer to the manual while reading it. Tables blow CSS out of the water in this way compared to css. Again and again, when using css, I have to dig to figure out how to do something like this

morgancodes