<?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 in the large</title>
	<atom:link href="http://www.szafranek.net/blog/2006/10/10/css_in_the_large/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.szafranek.net/blog/2006/10/10/css_in_the_large/</link>
	<description>The homepage of Krzysztof Szafranek, a guy who makes websites</description>
	<lastBuildDate>Tue, 12 Jul 2011 11:31:52 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Brush</title>
		<link>http://www.szafranek.net/blog/2006/10/10/css_in_the_large/#comment-1951</link>
		<dc:creator>Brush</dc:creator>
		<pubDate>Wed, 18 Oct 2006 08:31:05 +0000</pubDate>
		<guid isPermaLink="false">http://szafranek/blog/2006/10/10/css-in-the-large/#comment-1951</guid>
		<description>&lt;p&gt;i do not think it&#039;s a smart idea since in this way we will loose the ability to do the standard import when we actualy want to do this.
how about @local-import ? or anything else?&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>i do not think it&#8217;s a smart idea since in this way we will loose the ability to do the standard import when we actualy want to do this.<br />
how about @local-import ? or anything else?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Szafranek</title>
		<link>http://www.szafranek.net/blog/2006/10/10/css_in_the_large/#comment-1953</link>
		<dc:creator>Szafranek</dc:creator>
		<pubDate>Sun, 15 Oct 2006 21:17:12 +0000</pubDate>
		<guid isPermaLink="false">http://szafranek/blog/2006/10/10/css-in-the-large/#comment-1953</guid>
		<description>&lt;p&gt;There is an &lt;a href=&quot;http://www.w3.org/TR/REC-CSS2/cascade.html#at-import&quot;&gt;@import&lt;/a&gt; directive in CSS. So the server-side parser could be enhanced to recognize this rule and merge files on the server, instead of sending another HTTP request.&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>There is an <a href="http://www.w3.org/TR/REC-CSS2/cascade.html#at-import">@import</a> directive in CSS. So the server-side parser could be enhanced to recognize this rule and merge files on the server, instead of sending another HTTP request.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brush</title>
		<link>http://www.szafranek.net/blog/2006/10/10/css_in_the_large/#comment-1952</link>
		<dc:creator>Brush</dc:creator>
		<pubDate>Sun, 15 Oct 2006 18:45:14 +0000</pubDate>
		<guid isPermaLink="false">http://szafranek/blog/2006/10/10/css-in-the-large/#comment-1952</guid>
		<description>&lt;p&gt;Hm..
About that multitude of requests for css:
- if your css files are being already parsed by the serverside
code while not introducing a new pseudo-directive to the css
that will effectively &#039;include&#039; another stylesheet into the current one?&lt;/p&gt;
&lt;p&gt;The include command could also use your inheritance hierarchy ofcourse but the end result would be a single css file.&lt;/p&gt;
&lt;p&gt;This would be a first usable idea from the &#039;meta css language&#039; departament and i think it&#039;s worth a try.&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>Hm..<br />
About that multitude of requests for css:<br />
- if your css files are being already parsed by the serverside<br />
code while not introducing a new pseudo-directive to the css<br />
that will effectively &#8216;include&#8217; another stylesheet into the current one?</p>
<p>The include command could also use your inheritance hierarchy ofcourse but the end result would be a single css file.</p>
<p>This would be a first usable idea from the &#8216;meta css language&#8217; departament and i think it&#8217;s worth a try.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Szafranek</title>
		<link>http://www.szafranek.net/blog/2006/10/10/css_in_the_large/#comment-1957</link>
		<dc:creator>Szafranek</dc:creator>
		<pubDate>Fri, 13 Oct 2006 22:14:46 +0000</pubDate>
		<guid isPermaLink="false">http://szafranek/blog/2006/10/10/css-in-the-large/#comment-1957</guid>
		<description>&lt;p&gt;Medyk: sounds interesting. I myself was rather skeptical about mixing CSS and server-side. Although stylesheets are parsed by Java servlet to resolve paths and allow the hierarchy to work, they contain CSS rules only, and no scripting at all. I decided to go that for the sake of simplicity.&lt;/p&gt;
&lt;p&gt;Cezary:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;Fixed, thanks for spotting this.&lt;/li&gt;
&lt;li&gt;I was basing mostly on a common sense, but after you comments I did some research.
In case of my project “dozens” of small CSS modules would mean about 30-50 files, 1-2 kilobytes each.
Kept-Alive you mentioned eliminates initial overhead of establishing TCP/IP connection.
But each file has to be requested and reponse headers must be sent anyway.
For such a small files it means about twice as much overhead.
It also means that 1k file will use two TCP packets instead of one (one for the file itself, the second for HTTP headers).
In fact it has an impact on performance of the server (especially since CSS files are parsed), download time and bandwith usage.
I agree that these are completely unsignificant issues when we are talking about a weblog or small website.
But it does count on high-traffic websites.&lt;/li&gt;
&lt;li&gt;The issues I faced almost don&#039;t affect a client at all.
But when you have really many websites, few front-end developers (not to mention server-side guys) and hundreds
of stylesheets, it quickly becomes a real problem, not only a philosophical issue.
The code performance is one thing, but developers&#039; efficiency is at least as much important.
Unmaintainable code means delayed schedules and angry managers :).&lt;/li&gt;
&lt;/ol&gt;</description>
		<content:encoded><![CDATA[<p>Medyk: sounds interesting. I myself was rather skeptical about mixing CSS and server-side. Although stylesheets are parsed by Java servlet to resolve paths and allow the hierarchy to work, they contain CSS rules only, and no scripting at all. I decided to go that for the sake of simplicity.</p>
<p>Cezary:</p>
<ol>
<li>Fixed, thanks for spotting this.</li>
<li>I was basing mostly on a common sense, but after you comments I did some research.<br />
In case of my project “dozens” of small CSS modules would mean about 30-50 files, 1-2 kilobytes each.<br />
Kept-Alive you mentioned eliminates initial overhead of establishing TCP/IP connection.<br />
But each file has to be requested and reponse headers must be sent anyway.<br />
For such a small files it means about twice as much overhead.<br />
It also means that 1k file will use two TCP packets instead of one (one for the file itself, the second for HTTP headers).<br />
In fact it has an impact on performance of the server (especially since CSS files are parsed), download time and bandwith usage.<br />
I agree that these are completely unsignificant issues when we are talking about a weblog or small website.<br />
But it does count on high-traffic websites.</li>
<li>The issues I faced almost don&#8217;t affect a client at all.<br />
But when you have really many websites, few front-end developers (not to mention server-side guys) and hundreds<br />
of stylesheets, it quickly becomes a real problem, not only a philosophical issue.<br />
The code performance is one thing, but developers&#8217; efficiency is at least as much important.<br />
Unmaintainable code means delayed schedules and angry managers :).</li>
</ol>
]]></content:encoded>
	</item>
	<item>
		<title>By: Cezary Okupski</title>
		<link>http://www.szafranek.net/blog/2006/10/10/css_in_the_large/#comment-1954</link>
		<dc:creator>Cezary Okupski</dc:creator>
		<pubDate>Thu, 12 Oct 2006 12:07:13 +0000</pubDate>
		<guid isPermaLink="false">http://szafranek/blog/2006/10/10/css-in-the-large/#comment-1954</guid>
		<description>&lt;ol&gt;
&lt;li&gt;A typo in your article, Krzysztof - &quot;…Currently I&#039;ve &lt;strong&gt;splited&lt;/strong&gt; stylesheets…&quot; - should be - &lt;strong&gt;split&lt;/strong&gt; ;P&lt;/li&gt;
&lt;li&gt;In paragraph &quot;Going further&quot; you mention &quot;dozens of request&quot;… You should be aware that user agents open only one connection to get all resources the page needs. The connection is &lt;strong&gt;kept alive&lt;/strong&gt;. Opening a connection is time consuming but sending further HTTP requests is not as it seems. HTTP headers is a matter of bytes (maybe hundreds ;)). What else could influence the performance? Getting files from the HDD? It takes microseconds. In my opinion performance issues are not worth considering here when splitting CSS files.&lt;/li&gt;
&lt;li&gt;I have to agree with the final conclusion that there is no silver bullet. In my opinion you as a developer should obviously document the employed strategy whatever it was and the client should select people smart enough that know what they can and want to achieve in managing the websites. That is all. You should always remember that your CMS serves (as I guess) to communicate ideas - no matter if with one or two home.gif&#039;s. Sole use of CSS speeds up page rendering time (if applied properly which I am sure is the case). Further systematization attempts are a matter of developer&#039;s reality&#039;s perception. These are only philosophical issues.&lt;/li&gt;
&lt;/ol&gt;</description>
		<content:encoded><![CDATA[<ol>
<li>A typo in your article, Krzysztof &#8211; &#8220;…Currently I&#8217;ve <strong>splited</strong> stylesheets…&#8221; &#8211; should be &#8211; <strong>split</strong> ;P</li>
<li>In paragraph &#8220;Going further&#8221; you mention &#8220;dozens of request&#8221;… You should be aware that user agents open only one connection to get all resources the page needs. The connection is <strong>kept alive</strong>. Opening a connection is time consuming but sending further HTTP requests is not as it seems. HTTP headers is a matter of bytes (maybe hundreds ;)). What else could influence the performance? Getting files from the HDD? It takes microseconds. In my opinion performance issues are not worth considering here when splitting CSS files.</li>
<li>I have to agree with the final conclusion that there is no silver bullet. In my opinion you as a developer should obviously document the employed strategy whatever it was and the client should select people smart enough that know what they can and want to achieve in managing the websites. That is all. You should always remember that your CMS serves (as I guess) to communicate ideas &#8211; no matter if with one or two home.gif&#8217;s. Sole use of CSS speeds up page rendering time (if applied properly which I am sure is the case). Further systematization attempts are a matter of developer&#8217;s reality&#8217;s perception. These are only philosophical issues.</li>
</ol>
]]></content:encoded>
	</item>
</channel>
</rss>

