<?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: Why CSS</title>
	<atom:link href="http://cafe.elharo.com/web/refactoring-html/why-css/feed/" rel="self" type="application/rss+xml" />
	<link>http://cafe.elharo.com/web/refactoring-html/why-css/</link>
	<description>Longer than a blog; shorter than a book</description>
	<lastBuildDate>Tue, 09 Mar 2010 18:31:23 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: WEB 3.0 &#187; Blog Archive &#187; ¿Así que querías saber de CSS?</title>
		<link>http://cafe.elharo.com/web/refactoring-html/why-css/comment-page-1/#comment-386504</link>
		<dc:creator>WEB 3.0 &#187; Blog Archive &#187; ¿Así que querías saber de CSS?</dc:creator>
		<pubDate>Sat, 18 Apr 2009 01:21:01 +0000</pubDate>
		<guid isPermaLink="false">http://cafe.elharo.com/web/refactoring-html/why-css/#comment-386504</guid>
		<description>[...] Why CSS - Elliotte Rusty Harold [...]</description>
		<content:encoded><![CDATA[<p>[...] Why CSS &#8211; Elliotte Rusty Harold [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Igor Yuriev</title>
		<link>http://cafe.elharo.com/web/refactoring-html/why-css/comment-page-1/#comment-237029</link>
		<dc:creator>Igor Yuriev</dc:creator>
		<pubDate>Tue, 10 Jun 2008 03:49:39 +0000</pubDate>
		<guid isPermaLink="false">http://cafe.elharo.com/web/refactoring-html/why-css/#comment-237029</guid>
		<description>It&#039;s seems to me the CSS makes a remarkable point. If a client does not need super-puper presentation
he has facilities turn the CSS off or use his own CSS. 
Presentation layer shifts on _client_ _side_.</description>
		<content:encoded><![CDATA[<p>It&#8217;s seems to me the CSS makes a remarkable point. If a client does not need super-puper presentation<br />
he has facilities turn the CSS off or use his own CSS.<br />
Presentation layer shifts on _client_ _side_.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Elliotte Rusty Harold</title>
		<link>http://cafe.elharo.com/web/refactoring-html/why-css/comment-page-1/#comment-235941</link>
		<dc:creator>Elliotte Rusty Harold</dc:creator>
		<pubDate>Sat, 07 Jun 2008 13:58:03 +0000</pubDate>
		<guid isPermaLink="false">http://cafe.elharo.com/web/refactoring-html/why-css/#comment-235941</guid>
		<description>The CSS Zen Garden is a little out of date. Some of the techniques used there are no longer state of the art; and in particular the extra divs you note are usually not necessary any more.

Templating systems are important (this site uses one) and do a good job of separating markup from content on the authoring side, even if they use presentational HTML. They&#039;re less useful for anyone who needs to consume the data though since it&#039;s no longer obvious what&#039;s presentation and what&#039;s not. The best of both worlds is a templating system built around CSS, that only uses HTML for semantics rather than presentation.</description>
		<content:encoded><![CDATA[<p>The CSS Zen Garden is a little out of date. Some of the techniques used there are no longer state of the art; and in particular the extra divs you note are usually not necessary any more.</p>
<p>Templating systems are important (this site uses one) and do a good job of separating markup from content on the authoring side, even if they use presentational HTML. They&#8217;re less useful for anyone who needs to consume the data though since it&#8217;s no longer obvious what&#8217;s presentation and what&#8217;s not. The best of both worlds is a templating system built around CSS, that only uses HTML for semantics rather than presentation.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Theo</title>
		<link>http://cafe.elharo.com/web/refactoring-html/why-css/comment-page-1/#comment-235795</link>
		<dc:creator>Theo</dc:creator>
		<pubDate>Fri, 06 Jun 2008 20:20:11 +0000</pubDate>
		<guid isPermaLink="false">http://cafe.elharo.com/web/refactoring-html/why-css/#comment-235795</guid>
		<description>The problem is that for real-world sites you really can&#039;t separate presentation from content with HTML and CSS. The tools just aren&#039;t there.

Look at CSS Zen Garden for example (whose book is one of the book ads above, at least when I write this), you would expect their example page to be as presentation-less as they come, but when you look at it (and read the book) it turns out that the HTML is littered with extra layout-related tags &lt;em&gt;because otherwise it wouldn&#039;t work&lt;/em&gt;. It&#039;s impressive that they can get that many different looks with the same HTML, but the reason is that there is quite a lot of nonsensical code in there, code whose only purpose is to plug the holes where CSS just doesn&#039;t cut it.

Most of what you say in this installment is true, but its not very pragmatic. The Zen website and book has the same problem, there&#039;s this idea of HTML+CSS and separation of presentation and content which is talked about page up and page down, but when it comes to the code it&#039;s all &quot;oh, but we had to stick this div there to make sure that that thing over there could be styled like we wanted&quot;. The idea that HTML is content and CSS is presentation is too simplified, HTML is content, &lt;em&gt;and&lt;/em&gt; HTML is presentation.

In most cases what you have is content stored in a database, as text with simple HTML tags for things like links and emphasis (which is exactly how this comment will be stored). This is where HTML is content. Then you have a template of some kind which sticks that content in a structure defined in HTML. Some things in the structure is content, like &quot;this part is a menu&quot;, but many things most definitely aren&#039;t, they are just about which order the tags need to be in to make CSS layouting possible. Lastly, on top of all this you have a CSS that defines the rest of the layout, things like widths and sizes of things and also does the styling (fonts and colors). It&#039;s not CSS that separates presentation from content (although it helps), it&#039;s using a database and a templating engine that separates the two.</description>
		<content:encoded><![CDATA[<p>The problem is that for real-world sites you really can&#8217;t separate presentation from content with HTML and CSS. The tools just aren&#8217;t there.</p>
<p>Look at CSS Zen Garden for example (whose book is one of the book ads above, at least when I write this), you would expect their example page to be as presentation-less as they come, but when you look at it (and read the book) it turns out that the HTML is littered with extra layout-related tags <em>because otherwise it wouldn&#8217;t work</em>. It&#8217;s impressive that they can get that many different looks with the same HTML, but the reason is that there is quite a lot of nonsensical code in there, code whose only purpose is to plug the holes where CSS just doesn&#8217;t cut it.</p>
<p>Most of what you say in this installment is true, but its not very pragmatic. The Zen website and book has the same problem, there&#8217;s this idea of HTML+CSS and separation of presentation and content which is talked about page up and page down, but when it comes to the code it&#8217;s all &#8220;oh, but we had to stick this div there to make sure that that thing over there could be styled like we wanted&#8221;. The idea that HTML is content and CSS is presentation is too simplified, HTML is content, <em>and</em> HTML is presentation.</p>
<p>In most cases what you have is content stored in a database, as text with simple HTML tags for things like links and emphasis (which is exactly how this comment will be stored). This is where HTML is content. Then you have a template of some kind which sticks that content in a structure defined in HTML. Some things in the structure is content, like &#8220;this part is a menu&#8221;, but many things most definitely aren&#8217;t, they are just about which order the tags need to be in to make CSS layouting possible. Lastly, on top of all this you have a CSS that defines the rest of the layout, things like widths and sizes of things and also does the styling (fonts and colors). It&#8217;s not CSS that separates presentation from content (although it helps), it&#8217;s using a database and a templating engine that separates the two.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
