<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: CSS for Layout. Another Rant</title>
	<atom:link href="http://ajaxian.com/archives/css-for-layout-another-rant/feed" rel="self" type="application/rss+xml" />
	<link>http://ajaxian.com/archives/css-for-layout-another-rant</link>
	<description>Cleaning up the web with Ajax</description>
	<lastBuildDate>Thu, 09 Feb 2012 06:55:33 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2</generator>
	<item>
		<title>By: BenGerrissen</title>
		<link>http://ajaxian.com/archives/css-for-layout-another-rant/comment-page-2#comment-271192</link>
		<dc:creator>BenGerrissen</dc:creator>
		<pubDate>Sat, 07 Feb 2009 12:36:46 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=5876#comment-271192</guid>
		<description>&lt;cite&gt;CSS… tables… WHO CARES? &lt;/cite&gt;
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.

&lt;cite&gt;Aren’t we all doing our layouts in Javascript these days anyway?!? :)&lt;/cite&gt;
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...</description>
		<content:encoded><![CDATA[<p><cite>CSS… tables… WHO CARES? </cite><br />
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.</p>
<p><cite>Aren’t we all doing our layouts in Javascript these days anyway?!? :)</cite><br />
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.</p>
<p>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.</p>
<p>I really need to look into XUL&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: fzammetti</title>
		<link>http://ajaxian.com/archives/css-for-layout-another-rant/comment-page-2#comment-271186</link>
		<dc:creator>fzammetti</dc:creator>
		<pubDate>Fri, 06 Feb 2009 20:41:51 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=5876#comment-271186</guid>
		<description>CSS... tables... WHO CARES?  Aren&#039;t we all doing our layouts in Javascript these days anyway?!? :)
-
I&#039;m currently working on a massive project using Ext JS as the foundation and it&#039;s amazing just how little HTML and CSS I&#039;m actually doing now versus what I was doing previously.  Oh, there&#039;s of course bits of CSS sprinkled in, but it&#039;s largely to do true styling, i.e., colors and fonts and that stuff.  Hell, I&#039;d go so far as to say that the way we&#039;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&#039;t this the future that makes the CSS vs. tables discussion kind of superfluous?  I say that only half-jokingly... obviously there&#039;s plenty of need for web development where Javascript isn&#039;t prevalent, but let&#039;s face it, devices of *ANY* sort that don&#039;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 :)</description>
		<content:encoded><![CDATA[<p>CSS&#8230; tables&#8230; WHO CARES?  Aren&#8217;t we all doing our layouts in Javascript these days anyway?!? :)<br />
-<br />
I&#8217;m currently working on a massive project using Ext JS as the foundation and it&#8217;s amazing just how little HTML and CSS I&#8217;m actually doing now versus what I was doing previously.  Oh, there&#8217;s of course bits of CSS sprinkled in, but it&#8217;s largely to do true styling, i.e., colors and fonts and that stuff.  Hell, I&#8217;d go so far as to say that the way we&#8217;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!<br />
-<br />
Isn&#8217;t this the future that makes the CSS vs. tables discussion kind of superfluous?  I say that only half-jokingly&#8230; obviously there&#8217;s plenty of need for web development where Javascript isn&#8217;t prevalent, but let&#8217;s face it, devices of *ANY* sort that don&#8217;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.<br />
-<br />
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 :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: NatalieMac</title>
		<link>http://ajaxian.com/archives/css-for-layout-another-rant/comment-page-2#comment-271185</link>
		<dc:creator>NatalieMac</dc:creator>
		<pubDate>Fri, 06 Feb 2009 20:20:52 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=5876#comment-271185</guid>
		<description>It&#039;s true that when you haven&#039;t dealt with CSS much, it can be nearly impossible to accomplish what you want. However, tables aren&#039;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.</description>
		<content:encoded><![CDATA[<p>It&#8217;s true that when you haven&#8217;t dealt with CSS much, it can be nearly impossible to accomplish what you want. However, tables aren&#8217;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.</p>
<p>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.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ExtAnimal</title>
		<link>http://ajaxian.com/archives/css-for-layout-another-rant/comment-page-2#comment-271168</link>
		<dc:creator>ExtAnimal</dc:creator>
		<pubDate>Fri, 06 Feb 2009 14:26:04 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=5876#comment-271168</guid>
		<description>If a layout basically IS tabular, then a layout who&#039;s elements stretch to accommodate content, and to match their neighbours (two big capabilities of tables) is needed.

That&#039;s why CSS is getting display:table display:table-row and display:table-cell.</description>
		<content:encoded><![CDATA[<p>If a layout basically IS tabular, then a layout who&#8217;s elements stretch to accommodate content, and to match their neighbours (two big capabilities of tables) is needed.</p>
<p>That&#8217;s why CSS is getting display:table display:table-row and display:table-cell.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: BenGerrissen</title>
		<link>http://ajaxian.com/archives/css-for-layout-another-rant/comment-page-2#comment-271156</link>
		<dc:creator>BenGerrissen</dc:creator>
		<pubDate>Fri, 06 Feb 2009 01:05:22 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=5876#comment-271156</guid>
		<description>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&#039;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&#039;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&#039;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&#039;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&#039;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&#039;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...</description>
		<content:encoded><![CDATA[<p>Document looks like this (visual order):<br />
1.) Portal navigation<br />
2.) Banner (with page title)<br />
3.) Site Navigation<br />
4.) Content<br />
5.) Banner adds.<br />
6.) Footer (disclaimer/privacy etc)</p>
<p>More solid to do this with tables.</p>
<p>However, for better SEO rankings (of your entire sites content and not just the frontpage!) it&#8217;s appearantly better to have the following structure (SEO Specialists hired by clients frequently demand this):<br />
1.) Page title<br />
2.) content<br />
3.) Site Navigation<br />
4.) Portal Navigation<br />
5.) Footer<br />
6.) Adds</p>
<p>SEO is not just about getting your website up high in search results on the obvious topics, but to push all your site&#8217;s content pages up high on the search listings. The visual presentation and interface, is not the logical order.</p>
<p>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&#8230;</p>
<p>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&#8217;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&#8217;re really bad at CSS/HTML).</p>
<p>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&#8217;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&#8230;</p>
<p>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&#8217;s like chess, it takes dedication to master it.</p>
<p>Tbh&#8230; I want you all to keep using tables&#8230; It makes guys like me make the big bucks&#8230; So&#8230; erm.. proceed and forget what I said&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: samuraixp</title>
		<link>http://ajaxian.com/archives/css-for-layout-another-rant/comment-page-2#comment-271155</link>
		<dc:creator>samuraixp</dc:creator>
		<pubDate>Thu, 05 Feb 2009 23:38:44 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=5876#comment-271155</guid>
		<description>link at the top of the article is broken...

:)</description>
		<content:encoded><![CDATA[<p>link at the top of the article is broken&#8230;</p>
<p>:)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ajaxery</title>
		<link>http://ajaxian.com/archives/css-for-layout-another-rant/comment-page-2#comment-271147</link>
		<dc:creator>ajaxery</dc:creator>
		<pubDate>Thu, 05 Feb 2009 18:13:10 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=5876#comment-271147</guid>
		<description>@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&#039;t think tables work well with this approach.

Maybe when I&#039;m 80+ years old and blind, I&#039;ll finally understand.</description>
		<content:encoded><![CDATA[<p>@westonc:</p>
<p>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&#8217;t think tables work well with this approach.</p>
<p>Maybe when I&#8217;m 80+ years old and blind, I&#8217;ll finally understand.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: nixar</title>
		<link>http://ajaxian.com/archives/css-for-layout-another-rant/comment-page-2#comment-271145</link>
		<dc:creator>nixar</dc:creator>
		<pubDate>Thu, 05 Feb 2009 16:46:36 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=5876#comment-271145</guid>
		<description>Just one word: XUL

‹hbox› and ‹vbox›, along with the &#039;flex&#039; parameter, beat your puny tables or CSS hacks.</description>
		<content:encoded><![CDATA[<p>Just one word: XUL</p>
<p>‹hbox› and ‹vbox›, along with the &#8216;flex&#8217; parameter, beat your puny tables or CSS hacks.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nosredna</title>
		<link>http://ajaxian.com/archives/css-for-layout-another-rant/comment-page-2#comment-271143</link>
		<dc:creator>Nosredna</dc:creator>
		<pubDate>Thu, 05 Feb 2009 14:13:11 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=5876#comment-271143</guid>
		<description>aljames, great idea. But do you serve something else for people without JavaScript?</description>
		<content:encoded><![CDATA[<p>aljames, great idea. But do you serve something else for people without JavaScript?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jordan1</title>
		<link>http://ajaxian.com/archives/css-for-layout-another-rant/comment-page-2#comment-271139</link>
		<dc:creator>Jordan1</dc:creator>
		<pubDate>Thu, 05 Feb 2009 11:35:02 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=5876#comment-271139</guid>
		<description>&lt;blockquote&gt;Joeri said:
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.&lt;/blockquote&gt;
And while the crowd that stands for all things goods cheers, &quot;crooked hammer&quot; and shuns &quot;bent chisel&quot;, the crowd that stands for all things logical asks, &quot;what benefit is there of using top-grade concrete when your building a house on shallow foundation.&quot;</description>
		<content:encoded><![CDATA[<blockquote><p>Joeri said:<br />
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.</p></blockquote>
<p>And while the crowd that stands for all things goods cheers, &#8220;crooked hammer&#8221; and shuns &#8220;bent chisel&#8221;, the crowd that stands for all things logical asks, &#8220;what benefit is there of using top-grade concrete when your building a house on shallow foundation.&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: aljames</title>
		<link>http://ajaxian.com/archives/css-for-layout-another-rant/comment-page-2#comment-271136</link>
		<dc:creator>aljames</dc:creator>
		<pubDate>Thu, 05 Feb 2009 10:13:53 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=5876#comment-271136</guid>
		<description>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/</description>
		<content:encoded><![CDATA[<p>Here are a couple of blog posts I wrote on this. </p>
<p>1) Why neither CSS and tables are the right job for layout: <a href="http://onewheeledbicycle.com/2009/02/05/page-document-layout/" rel="nofollow">http://onewheeledbicycle.com/2009/02/05/page-document-layout/</a></p>
<p>2) My ideal solution (that will never happen):<br />
<a href="http://onewheeledbicycle.com/2009/02/05/html-layouts-ideal-solution-idea-1/" rel="nofollow">http://onewheeledbicycle.com/2009/02/05/html-layouts-ideal-solution-idea-1/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joeri</title>
		<link>http://ajaxian.com/archives/css-for-layout-another-rant/comment-page-2#comment-271128</link>
		<dc:creator>Joeri</dc:creator>
		<pubDate>Thu, 05 Feb 2009 08:53:42 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=5876#comment-271128</guid>
		<description>The false dichotomy between CSS and tables is not the issue here. The issue is that you&#039;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.</description>
		<content:encoded><![CDATA[<p>The false dichotomy between CSS and tables is not the issue here. The issue is that you&#8217;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.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: aljames</title>
		<link>http://ajaxian.com/archives/css-for-layout-another-rant/comment-page-2#comment-271127</link>
		<dc:creator>aljames</dc:creator>
		<pubDate>Thu, 05 Feb 2009 08:51:03 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=5876#comment-271127</guid>
		<description>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?</description>
		<content:encoded><![CDATA[<p>Hmmm&#8230; 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&#8230; Interesting idea?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: drewlesueur</title>
		<link>http://ajaxian.com/archives/css-for-layout-another-rant/comment-page-2#comment-271126</link>
		<dc:creator>drewlesueur</dc:creator>
		<pubDate>Thu, 05 Feb 2009 08:50:33 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=5876#comment-271126</guid>
		<description>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.</description>
		<content:encoded><![CDATA[<p>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.</p>
<p>I think tables are great.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nosredna</title>
		<link>http://ajaxian.com/archives/css-for-layout-another-rant/comment-page-2#comment-271125</link>
		<dc:creator>Nosredna</dc:creator>
		<pubDate>Thu, 05 Feb 2009 05:32:07 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=5876#comment-271125</guid>
		<description>@ajaxery. I was using Chrome. Firefox&#039;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&#039;t size.
.
I&#039;m hearing that devs love css, but I&#039;m seeing limited designs as a result.</description>
		<content:encoded><![CDATA[<p>@ajaxery. I was using Chrome. Firefox&#8217;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&#8217;t size.<br />
.<br />
I&#8217;m hearing that devs love css, but I&#8217;m seeing limited designs as a result.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: westonc</title>
		<link>http://ajaxian.com/archives/css-for-layout-another-rant/comment-page-2#comment-271124</link>
		<dc:creator>westonc</dc:creator>
		<pubDate>Thu, 05 Feb 2009 05:28:53 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=5876#comment-271124</guid>
		<description>I&#039;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&#039;d use table for layout is unaware of these effects. I haven&#039;t seen any evidence or argument that supports the idea these effects are a central issue.

Particularly SEO. No reliable source of information I&#039;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&#039;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&#039;t seem present a real obstacle in practice.</description>
		<content:encoded><![CDATA[<p>I&#8217;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&#8217;d use table for layout is unaware of these effects. I haven&#8217;t seen any evidence or argument that supports the idea these effects are a central issue.</p>
<p>Particularly SEO. No reliable source of information I&#8217;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. </p>
<p>Semantics I&#8217;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 <a href="http://lynx.isc.org/current/README.TRST" rel="nofollow">http://lynx.isc.org/current/README.TRST</a> )</p>
<p>The bottom line seems to be that despite a lot of handwringing over the repurposing of tabular markup, it doesn&#8217;t seem present a real obstacle in practice.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ajaxery</title>
		<link>http://ajaxian.com/archives/css-for-layout-another-rant/comment-page-2#comment-271123</link>
		<dc:creator>ajaxery</dc:creator>
		<pubDate>Thu, 05 Feb 2009 04:41:14 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=5876#comment-271123</guid>
		<description>@Nosredna:

I&#039;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 &#039;Largest&#039; text size. And GE doesn&#039;t budge at all. I know there&#039;s IE6 limitations on text-size increases when you use &#039;px&#039; instead of &#039;em,&#039; 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&#039;m sure other do this by default (ctrl +). I&#039;m sure someone with poor eyesight would opt for a full page zoom over just text, but I don&#039;t know that for a fact.

I didn&#039;t work on these pages at all.

@westonc:

&quot;Yourself included, apparently.&quot;

I&#039;m sorry, what are you referring to?</description>
		<content:encoded><![CDATA[<p>@Nosredna:</p>
<p>I&#8217;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 &#8216;Largest&#8217; text size. And GE doesn&#8217;t budge at all. I know there&#8217;s IE6 limitations on text-size increases when you use &#8216;px&#8217; instead of &#8216;em,&#8217; 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&#8217;m sure other do this by default (ctrl +). I&#8217;m sure someone with poor eyesight would opt for a full page zoom over just text, but I don&#8217;t know that for a fact.</p>
<p>I didn&#8217;t work on these pages at all.</p>
<p>@westonc:</p>
<p>&#8220;Yourself included, apparently.&#8221;</p>
<p>I&#8217;m sorry, what are you referring to?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: westonc</title>
		<link>http://ajaxian.com/archives/css-for-layout-another-rant/comment-page-2#comment-271122</link>
		<dc:creator>westonc</dc:creator>
		<pubDate>Thu, 05 Feb 2009 03:10:52 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=5876#comment-271122</guid>
		<description>&lt;blockquote&gt;using tables for layout is simply the wrong way to do it.&lt;/blockquote&gt;

This is a catechism, not an argument.

&lt;blockquote&gt;front-end builders who are aware of accessibility, semantics and SEO as it relates to page structure.&lt;/blockquote&gt;

Yourself included, apparently.</description>
		<content:encoded><![CDATA[<blockquote><p>using tables for layout is simply the wrong way to do it.</p></blockquote>
<p>This is a catechism, not an argument.</p>
<blockquote><p>front-end builders who are aware of accessibility, semantics and SEO as it relates to page structure.</p></blockquote>
<p>Yourself included, apparently.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nosredna</title>
		<link>http://ajaxian.com/archives/css-for-layout-another-rant/comment-page-2#comment-271121</link>
		<dc:creator>Nosredna</dc:creator>
		<pubDate>Thu, 05 Feb 2009 03:08:40 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=5876#comment-271121</guid>
		<description>On the IBM site, two increases in text size (Chrome) is enough on some pages to obscure words behind pictures. Probably wouldn&#039;t happen with a table layout.
.
GE doesn&#039;t let most text scale, but some does an overlaps other text, make both sentences unreadable.
.
Not impressed.</description>
		<content:encoded><![CDATA[<p>On the IBM site, two increases in text size (Chrome) is enough on some pages to obscure words behind pictures. Probably wouldn&#8217;t happen with a table layout.<br />
.<br />
GE doesn&#8217;t let most text scale, but some does an overlaps other text, make both sentences unreadable.<br />
.<br />
Not impressed.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nosredna</title>
		<link>http://ajaxian.com/archives/css-for-layout-another-rant/comment-page-2#comment-271120</link>
		<dc:creator>Nosredna</dc:creator>
		<pubDate>Thu, 05 Feb 2009 03:04:34 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=5876#comment-271120</guid>
		<description>@ajaxery,
.
No problem. I don&#039;t want to go back to the bad old days of tables. But I&#039;m not happy with css either. I just get the feeling that the css guys are so zealous they&#039;re not even listening anymore.
.
I think it&#039;s really instructive to look where the smart guys use tables and try to figure out why. Here&#039;s what I&#039;ve come up with. I just went back and looked at the &quot;good&quot; 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&#039;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&#039;s left/right division, or the small bits on stackoverflow.com.
.
In my ideal world, there&#039;d be a way to split divs into proportional parts, EITHER left or right (not both). That would get rid of almost every &quot;useful&quot; table I see around. Honestly, I think that&#039;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?</description>
		<content:encoded><![CDATA[<p>@ajaxery,<br />
.<br />
No problem. I don&#8217;t want to go back to the bad old days of tables. But I&#8217;m not happy with css either. I just get the feeling that the css guys are so zealous they&#8217;re not even listening anymore.<br />
.<br />
I think it&#8217;s really instructive to look where the smart guys use tables and try to figure out why. Here&#8217;s what I&#8217;ve come up with. I just went back and looked at the &#8220;good&#8221; Fortune 500 sites, and I looked at some other sites that use just a sprinkling of tables.<br />
.<br />
1) A lot of the pure css sites are fixed, not fluid. They are very brittle. They either don&#8217;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.<br />
.<br />
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&#8217;s left/right division, or the small bits on stackoverflow.com.<br />
.<br />
In my ideal world, there&#8217;d be a way to split divs into proportional parts, EITHER left or right (not both). That would get rid of almost every &#8220;useful&#8221; table I see around. Honestly, I think that&#8217;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?</p>
]]></content:encoded>
	</item>
</channel>
</rss>

