<?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"
	>
<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>
	<pubDate>Tue, 06 Jan 2009 10:39:40 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: Igor Yuriev</title>
		<link>http://cafe.elharo.com/web/refactoring-html/why-css/#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'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-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're less useful for anyone who needs to consume the data though since it's no longer obvious what's presentation and what'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-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't separate presentation from content with HTML and CSS. The tools just aren'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't work&lt;/em&gt;. It'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'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'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's all "oh, but we had to stick this div there to make sure that that thing over there could be styled like we wanted". 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 "this part is a menu", but many things most definitely aren'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's not CSS that separates presentation from content (although it helps), it'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>
