Related
Looking at the CSS Zen Garden, I can see how powerful and convenient it is to separate design and content. The possibilities seem nearly endless. One can change the style sheet and the appearance of the whole site can be drastically altered.
Let's say I'm putting together the HTML part of a website. How do I know where to put divs, where to nest them, etc?
For example, let's say I want to centre something on the screen: I would generally nest 3 divs together: one display:table, one display:table-cell, and one margin-left:auto;margin-right;auto which would have the content.
Let's say I'm just doing the HTML content, but am not thinking about the design at this stage. How would I know that I need to nest together 3 divs if I don't necessarily know I will centre it on the screen?
Or if I have one design now with HTML/CSS and I have my divs and spans all set out, what happens in 18 months if I decide to change the CSS for a completely new layout? Sometimes I will have extra divs and sometimes I won't have enough.
Presumably it would always be better to have more levels than not enough. That way, the worst thing that can happen is that you have a few superfluous divs which aren't styled and have no visible effect.
Is this generally a problem others have? I know CSS Zen Garden is a special case, but would you generally change the HTML code considerably when you change the corresponding CSS?
I've worked in web development for many years, and over here in Reality things are a bit different from Theory: There is no such thing as separation of content and presentation. You'll always end up sliding in additional divs.
You better follow the YAGNI principle. Don't worry about your CSS as you're writing your HTML. Come back later and do the neccessary adjustments.
As for Zen Garden, you'll find a comment in the source code:
This xhtml document is marked up to provide the designer with the maximum possible flexibility. There are more classes and extraneous tags than needed, and in a real world situation, it's more likely that it would be much leaner.
Theoretically, in order to change the style, you wouldn't have to touch the data (HTML). In practice, there are those problems you mentioned.
What I would do is a more-or-less sensible usage of divs (so for example, anything I think that I might want to move around, or any bunch of HTML that I would want to refer to together - would go in a div of its own). Otherwise, don't use too many divs, for reasons such as readability, maintainability, and size of HTML.
Then, whenever you want to change the style, make the minimal addition of divs so that you'll be able to do what you want.
This is a genuine problem with CSS and it was recognised by the authors of CSS3. The most recent published draft (2003) of the CSS Generated and Replaced Content module discusses a pseudo element called ::outside which would have solved the problem you describe. It would, when implemented, for
<div class="mycontent">Some text</div>
have allowed you to write:
div.mycontent { margin-left:auto;margin-right:auto; }
div.mycontent::outside { display:table-cell; }
div.mycontent::outside(2) { display:table; }
Unfortunately, the ::outside pseudo-element never made it into the CSS3 selectors spec, and the next draft (2011) of the CSS Generated and Replaced Content module will not mention the ::outside pseudo-element.
So we're stuck with putting wrapper divs everywhere just in case which as you note, does not allow proper separation of presentation and content, and remains a deeply unsatisfactory situation.
It all depends on how your website is driven. If you are using template files, the amount of updates will be minimal.
You do not want to overload your code with superfluous Divs because a) load time (althought it will be minimal difference in theory) and b) because it will create a lot of confusion when others edit your files.
From your example, it looks like you may be used to table style layouts. Using Divs to contain your layout will make flexibility very easy.
I am creating a web GUI for an application I am working on. This particular section will sit within a larger page that is of a good semantic makeup. However, I am unsure what the best option to markup the below screen semantically.
My initial thought is to separate the top half from the bottom half via divs. Therefore, markup for the top is pretty easy. Leaving the bottom which is where I feel stumped. The easiest answer is a table but this content doesn't easily fit the only use tables for tabular data rule. Especially considering that headers would look conspicuous in this layout. Suggestions?
Need Semantic Markup for this Image http://img183.imageshack.us/img183/2261/semanticmarkup.png
I would use a table for the lower portion because in my opinion this is tabular data. I see 4 columns (icon, project name, project description, and action buttons). I don't see any reason to not use a table for this layout (not to mention that any other approach that would make this layout scale properly would require JavaScript and a lot of headaches to work right).
I don't think it would be the most egregious violation of semantic markup if you put that stuff in tables. Except for the buttons, it looks pretty tabular to me. I think the CSS gods would absolve you :)
I agree with Andrew. This is tabular data so you should use a <table> but keep in mind that you should define table headers, columns, and footers properly.
Your other option is to go with a headerless table where you would use a <div>for the header and footer and a <table> as the body. However, I don't recommend doing this. One reason would be you would want headers for things like client-side sorting if you're using JavaScript.
You're not violating anything putting that in a table form. Sure, some people will whine about it, but it's close enough to tabular data that you may as well.
This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
Why not use tables for layout in HTML?
I know everyone is all about DIV's and css and against tables now days, I have always used tables because they are so easy for me to visually see what I am doing while building, I am just now ventruing into the DIV world.
So my question are tables completely replaced by div's generally? I notice on the source of stackoverflow it is mostly DIV's but still uses tables as well, so I am guessing that tables must be used sometimes?
Below is an image of something I am trying to accomplish, most of it is coded but some of it is added in on photoshop, so far I have it all done in div's however what I have is only the background cells which are a list item and the photos, what I am missing from my code is all the text areas and it would be super easy for me to position the text areas within a table cell but since like 80% of the object is done with just css and divs I am not sure if I should just try to finsih it with just div's or if a table inside the comment div's would be the way to go.
I noticed on this page that the ansers are a table inside of a DIV
alt text http://img2.pict.com/e0/4e/de/1486585/0/screenshot2b15.png
To be semantically correct, tables should only used for tabular data and not for laying out a page.
David Dorward brought something to my attention in a comment. According to the HTML 4.01 Specification's section on Tables in HTML Documents:
Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables.
Theres a lot of fervent zealotry regarding this notion of semantic content, which is fine and all but the only problem is that it's hopelessly naive.
Fact: there are some things that can be done trivially with tables that either can't be done in "pure" CSS, are extremely difficult in "pure" CSS, have some nasty side effects in "pure" CSS or have serious cross-browser issues.
I did my CSS3 Wish List and in compiling that list I realized some things I've been able to do with tables since HTML 3.2 a decade ago I still can't do with divs.
I'm all for having a semantic layout. Nice ideal. But until it can do everything it's trying to replace then the thing it's trying to replace will have valid use cases.
divs are used instead of tables in most of the sites. But you can use tables in some situations where design using div will be complicated in a cross browser way.
For eg vetical aligning contents inside div will be a big problem as compared to that in table cells.
In this page also you can find table tags being used.
Tables will only be rendered to the screen after all the cells are finished processing.
Take a look at the following questions also.
Why not use tables for layout in HTML?
DIV’s vs Tables or CSS vs. Being Stupid
Yet Another Divs vs Tables Question: Forms
I think a lot of people will argue that "tabular" data, or data that can best be expressed in rows and columns, should be kept in a table, but that divs were invented to replace tables as large layout elements. In my personal opinion, tables were always used as layout elements in a way that went beyond their intended purpose. That's not to say that people don't still misuse divs, for example
<div align="center">To replace a <center> tag</div>
I'd say check out A List Apart, specifically Their section on layout for tips on how to use modern compliant css-based design.
edit : My point was that this is the INCORRECT use of a div tag. In this example, you would use a style such as "text-align:center" or apply that style to the tag itself, but in this case there is no reason to wrap your text in a block-level element, because text by default is inline, so you would be better off with something more like this...
<p class="center">This is a centered paragraph</p>
and then in your stylesheet
.center { text-align:center; }
Thus, the following:
<div>Monday | Tuesday | Wednesday | Thursday | Friday</div>
<div>Work | Work | Work | Work | Play</div>
May be compliant but it looks terrible, and you'd be better off doing :
<table>
<th>
<td>Monday</td><td>Tuesday</td><td>Wednesday</td><td>Thursday</td><td>Friday</td>
</th>
<tr>
<td>Work</td><td>Work</td><td>Work</td><td>Work</td><td>Play</td>
</tr>
</table>
Tables are appropriate for tabular data, but divs + CSS is preferred for general page layout.
http://css-discuss.incutio.com/?page=TablesVsDivs has many good reasons why, as well as some counter arguments.
Like Korey and Thomas said, it's better to use table to represent tabular data.
If you want to make website layout in pure CSS, you can take a look on these CSS frameworks, which ease the task :
http://elements.projectdesigns.org/
http://960.gs/
http://www.blueprintcss.org/
http://elasticss.com/
http://www.yaml.de/en/
http://bluetrip.org/
http://devkick.com/lab/tripoli/
There are a lot of css frameworks out these, just find the one which fit your needs..
Update : Here is a more complete list of css frameworks.
Tables should only be used for tabular data. To figure out if what I am dealing with is tabular I ask myself "would I put this in Excel or Word if it?"
Bill Merikallio & Adam Pratt wrote a funny and informative article Why tables for layout is stupid. They also detail where tables should be used and when.
Tables as means of describing the structure of tabular data have not been replaced.
Tables as means for describing presentation have been replaced, but not with divs. They have been replaced with stylesheets in associate with whatever element best describes the semantics of the content. A div has no semantics associated with it, so it is used if there is nothing better.
It certainly depends. The Golden Rule you must remember is that the XHTML/HTML document file it's meant to describe content and flow.
Everything that is design should be (whenever it's possible, there are some certainly some case scenarios where we can't control it, like when CMS appear on the game) controlled using a CSS file.
Now, how can we reach the most semantically and pragmatical result? As with everything, it depends. Using XHTML/HTML tag elements instead on just relying on for correct content display it's the recommended way.
Notice that I've said tag elements. DIV is just one of them, but just replacing with whenever a or / tags exists is not enough. In fact, that will push you over "divitis" (the useless employ of divs for everything!) and WILL make your job hard. Try checking most tags and use them whenever seems correct.
Sometimes it's a pretty subjective matter as to what qualifies as a content or another tag. Just in this question someone asked if this content would be considered tabulated data (the one that tables are supposed to be used for), but I think that whatever content you must order and filter (and you can copy and paste on Excel without worries) it's worthy material.
Everythin else, it's mostly always just some interesting layout display that should be worked on with CSS and other tags.
Some people will say it's too much work and not worth it. I disagree. Though learning how to work with CSS/divs nuances it's somewhat different at first, you'll soon learn the twist of it.
Good luck and remember that we are always learning new stuff, so don't worry on question everything.
My recommendation would be to really learn HTML. Use the element that actually relates to the content. If it is a list of items, use one of the list tags. If it is data entry, use a fieldset tag. There aren't that many tags to chose from yet so many are neglected. If you simply replace all your table layout formatting with DIVs, your tag soup might be a little less chunky but you can still choke on it.
In terms of performance side, table(s) will only get rendered once the end tag () is reached, so if it is a table contains 100s of rows, you will see that table appears in the browser little later. This is not true for DIVs.
I posted on meta-SO about their tables: https://meta.stackexchange.com/questions/3110/when-did-so-start-using-tables-for-layout/3547#3547
In short, I think it's fine since it is tabular data.
You should check Elastic CSS Framework you can layout an unlimited combination of columns very easily and position them with its helpers, check out the documentation.
cheers
CSS is great and all, but I mainly use it for styling, not layout. I and countless other developers still use tables every day for building web pages, and will for the foreseeable future.
If you want to use absolute and relative positioning for layouts, go for it. If not, you are not evil or stupid for not doing so. The main thing to look out for when using tables is preventing table nesting hell IMO.
This question already has answers here:
Closed 13 years ago.
I am developing a "modern" website, and I'm having a lot of trouble getting the CSS to make everything line up properly. I feel like they layout would be a lot easier if I just used a table, but I've been avoiding <table> tags, because I've been told that they are "old-fashioned" and not the right way to do things.
Is it okay to use tables? How do I decide when a table is appropriate, and when I should use CSS instead? Do I just do whatever is easier?
The answer is yes, it's fine to use tables. The general rule of thumb is that if you are displaying tabular data, a table is probably a good way to go. You should generally try to style your table with css as much as you can though.
Also, this pie graph might help you:
alt text http://www.ratemyeverything.net/image/7292/0/Time_Breakdown_of_Modern_Web_Design.ashx
EDIT: Tables are fine. For displaying data. Just like my second sentence stated. The question was "is it ok to use tables". The answer is - yes, it is ok to use tables. It is not illegal.
Since even though it's implied to use tables for data in my general rule of thumb, apparently I must also state that the corollary is that it's not ok to use tables for anything else, even though the poster already seemed to grasp this concept. So, for the record, the general rule of thumb is to not use tables for laying out your site.
Tables should be used to represent tabular data. CSS should be used for presentation and layout.
This question has also been exhaustively answered here:
Why not use tables for layout in HTML?
Essentially - if you have tabular data, then use a table. There's really no need now to use tables for layout - sure, they were often considered 'easier' but semantically the page is horrid, they were often considered inaccessible.
See some discussion:
css-discuss
and a particularly comical URL - shouldiusetablesforlayout.com
In the 'modern' approach of tables it is not about using table tags or div tags, but about using the right tag for the right purpose.
The table tag is used for tabular data. There is nothing wrong with using it for that!
For using CSS, there are a lot of tutorials and guides (good and bad) around. Indicators of a bad tutorial are: lot of use of blocks (divs) that only make sense for the layout and not for the content. Good signs are the ones that advise to use the right tags for the right content and teach you how to make up that tags.
Tables are only appropriate for tabular data. Imagine you have to add some spreadsheet like data, where you have clear row/column headers, and some data inside those rows.
A product comparison, for example, is also a valid table item.
I believe that tables are OK for display of rectilinear data of arbitrary rows and/or columns. That's about it. Tables should not be used for layout purposes anymore.
In general, HTML markup should describe the structure and content of a web page—it should not be used to control presentational aspects such as layout and styling (that's what CSS is for). A <table> tag, like most have already said, should represent tabular data—something that would appear as a table of information.
The reason why people rag on tables so much is that in the old days, there was no such thing as CSS—all page layout was done directly in HTML. Tags were not thought of as describing content—all anyone really cared about was how a tag would make things look in a web browser. As a result of this, people figured that, since they could organize things into rows and columns, tables must be good for laying out elements of a web page. This became a really popular technique—in fact, I'd wager that using tables was considered the preferred method of laying out web pages for quite some time.
So when people tell you that tables are "old-fashioned," they are specifically referring to this abuse of the <table> tag that was so popular back in the old days. Like I said, there's nothing wrong with HTML tables themselves, but using them for web page layout just doesn't make sense nowadays.
(Plus, from a purely pragmatic standpoint, layouts done with HTML tables are very inflexible and hard to maintain.)
its ok to use tables when you are showing data in a grid / tabular format. however, for general structure of the site, its highly recommended that you use css driven div, ul, li elements to give you more lucid website.
If you anyways decide to work with tables, you must consider the following cons :
they are not SEO friendly
they are quite rigid in terms of their structure and at times difficult to maintain as well
you may be spending little extra time on div based website, but its worth every minute spent.
The whole "anti-Table" movement is a reaction to a time when deeply nested tables were the only method to layout pages, leading to HTML that was very hard to understand.
Tables are a valid method for tabular (data) layout, and if a table is the easiest way to implement a layout, then by any means use a table.
Table is always the right choice when you have the need to present data in a grid.
Quoting Sitepoints's book HTML Utopia: Designing Without Tables using CSS
If you have tabular data and the appearance of that data is less important than its appropriate display in connection with other portions of the same data set, then a table is in order. If you have information that would best be displayed in a spreadsheet such as Excel, you have tabular data.
I would say no for using tables to construct your layout. Tables make sense only for actual tabular data you need to represent. If you spend enough time figuring the CSS out you will find its easier then using tables for a layout. Just remember: Tables for displaying data. CSS for page layouts.
Tables are just that: Tables.
They are frowned upon because they should not be used for layout, as has been the fashionable thing to do before browsers could position stuff properly.
If what you want to markup is, in fact, a table, then use a table. Other than that, try to stay away.
One small thing: Aligning two parts of text to the exact same line that won't move apart (think, username and post date). There using a table is IMHO an option.
First get it working. Then get it perfect.
Get the layout done in some way before making it perfect or better.
How many people per day will go to the page you are working on? A million? or 20 ?
How much time are you going to spend on CSS issues instead of other issues? Does your boss want you to spend this much time on the issue? Does he/she know what you are doing?
Absolutely. I don't know where CSS zealots invented the idea that tables are not naturally used for "layout". Tables have been used for laying things out since their invention, whether those things be numbers, words, or pretty pictures. That's what they do. Moreover, table is part of all versions of (X)HTML so there are no deprecation concerns.
Absolutely.
All that HTML offers was originally intended for you to define the markup of your page. In my book, absolute and relative positions of elements on a page belong to markup. So both divs and tables are very much suited for this task. Pick up what works best for your particular need.
CSS adds many styling possibilities and also layout tricks but it complements HTML options not replaces them.
There is actually a very fine line between seeing something as a markup or styling issue. CSS proponents would say that with CSS you can relocate and reshuffle completely all big and little pieces of a page. I cannot however imagine putting header below, footer above and making things appear in reverse order.
Take an example. You design a notebook. You know where to place major components, mainboard, cooling system, keyboard, display and ports. You may certainly wish to rearrange a little bit port connectors, on whic side and in which sequence they appear, but you don't really expect to put display where the keyboard is, put keyboard on the lid, make fans blow to your face and have all connectors on the botom to be reached through holes on your desk.
Using tables can make it slightly difficult to rearrange elements on a page. This might be true. However, in most cases you know in advance how approximately your page should look like and you would not want to change everything drastically. if you can't say it before your begin your work you probably have no clear idea what you are doing and what for.
Moreover, only tables possess elastic properties, which allows the to stretch to the width/height of their content. Nothing else of HTML/CSS can be used to do that.
CSS design on one side allows you to create quite adjustable designs. On the other hand, it locks you out from designing a page adjustable to its content. Both wins and losses.
Table is also the only tool to make very complex and precise interfaces. For example, the page SO is very simple. It probably can be done with pure CSS. In the meantime, have you seen any enterprise-class software like CRMs, SRMs etc? That multitude of buttons, text field, check boxes, dropdownlists all precisely located on a screen? Good luck achieving that kind of complexity with just CSS. And these layouts migrate from desktop applications into web each day (keyword: software-as-a-service).
So choose what suits best your current need and don't trust those CSS lovers. Actually don't trust any fanatics at all.
Looking at the source code for Stack Overflow, 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 Stack Overflows tables are used for structure.
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.
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.
SO was probably written by programmers, not web developers.
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.
Give up and use tables
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.
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.
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.
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
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).
"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.
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.
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....
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...