<?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: CSS3 Feedback: Selector Blocks</title>
	<atom:link href="http://meyerweb.com/eric/thoughts/2009/02/12/selector-blocks/feed/" rel="self" type="application/rss+xml" />
	<link>http://meyerweb.com/eric/thoughts/2009/02/12/selector-blocks/</link>
	<description>Things that Eric A. Meyer, CSS expert, writes about on his personal Web site; it&#039;s largely Web standards and Web technology, but also various bits of culture, politics, personal observations, and other miscellaneous stuff</description>
	<lastBuildDate>Tue, 18 Jun 2013 15:30:40 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: Erling Ormar Vignisson</title>
		<link>http://meyerweb.com/eric/thoughts/2009/02/12/selector-blocks/#comment-468651</link>
		<dc:creator>Erling Ormar Vignisson</dc:creator>
		<pubDate>Mon, 29 Jun 2009 14:00:55 +0000</pubDate>
		<guid isPermaLink="false">http://meyerweb.com/?p=1034#comment-468651</guid>
		<description><![CDATA[Hey Erice - care to print this out and fax it to the W3C? Surely, they have a fax machine by now ;-)

http://lesscss.org/]]></description>
		<content:encoded><![CDATA[<p>Hey Erice &#8211; care to print this out and fax it to the W3C? Surely, they have a fax machine by now ;-)</p>
<p><a href="http://lesscss.org/" rel="nofollow">http://lesscss.org/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Erik</title>
		<link>http://meyerweb.com/eric/thoughts/2009/02/12/selector-blocks/#comment-447218</link>
		<dc:creator>Erik</dc:creator>
		<pubDate>Wed, 11 Mar 2009 09:49:28 +0000</pubDate>
		<guid isPermaLink="false">http://meyerweb.com/?p=1034#comment-447218</guid>
		<description><![CDATA[I would have loved to have this when we redesigned our company website – we had a handful of colors that are randomly used on each page, and if you add page specific styles on top of that you end up with a loooot of different color + page + container + element scenarios that turned into pages of repeating CSS rules.

Instead of having to handle one huge unruly CSS file I sprinkled some utility classes in my templates instead. Presentational hooks, but what can you do? Ease of maintenance was more important.

And yes, I know I&#039;m late to join the party :)]]></description>
		<content:encoded><![CDATA[<p>I would have loved to have this when we redesigned our company website – we had a handful of colors that are randomly used on each page, and if you add page specific styles on top of that you end up with a loooot of different color + page + container + element scenarios that turned into pages of repeating CSS rules.</p>
<p>Instead of having to handle one huge unruly CSS file I sprinkled some utility classes in my templates instead. Presentational hooks, but what can you do? Ease of maintenance was more important.</p>
<p>And yes, I know I&#8217;m late to join the party :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Arpan</title>
		<link>http://meyerweb.com/eric/thoughts/2009/02/12/selector-blocks/#comment-444108</link>
		<dc:creator>Arpan</dc:creator>
		<pubDate>Fri, 20 Feb 2009 20:01:03 +0000</pubDate>
		<guid isPermaLink="false">http://meyerweb.com/?p=1034#comment-444108</guid>
		<description><![CDATA[Here&#039;s an idea, how about we use a pre-processor in addition to adding support for the new CSS syntax.

example:
link rel=sass href=layout.sass
link rel=stylesheet href=layout.css

The layout.css would be generated from the layout.sass and used by current browsers. Newer browsers that can handle SASS, when they came across sites with SASS would use that file and disregard the css file.

This way, the new syntax gets standardised instead of 10 different preprecessors, and we can start using it immediately, and don&#039;t have to wait all browsers catch up.

Advantage for us (designers &amp; developers), we get something standardized that we can start using right away, that will save time and make maintenance so much easier.

Advantage for users, smaller files.]]></description>
		<content:encoded><![CDATA[<p>Here&#8217;s an idea, how about we use a pre-processor in addition to adding support for the new CSS syntax.</p>
<p>example:<br />
link rel=sass href=layout.sass<br />
link rel=stylesheet href=layout.css</p>
<p>The layout.css would be generated from the layout.sass and used by current browsers. Newer browsers that can handle SASS, when they came across sites with SASS would use that file and disregard the css file.</p>
<p>This way, the new syntax gets standardised instead of 10 different preprecessors, and we can start using it immediately, and don&#8217;t have to wait all browsers catch up.</p>
<p>Advantage for us (designers &amp; developers), we get something standardized that we can start using right away, that will save time and make maintenance so much easier.</p>
<p>Advantage for users, smaller files.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ben Hollis</title>
		<link>http://meyerweb.com/eric/thoughts/2009/02/12/selector-blocks/#comment-443608</link>
		<dc:creator>Ben Hollis</dc:creator>
		<pubDate>Wed, 18 Feb 2009 05:59:55 +0000</pubDate>
		<guid isPermaLink="false">http://meyerweb.com/?p=1034#comment-443608</guid>
		<description><![CDATA[As others have mentioned, SASS supports something very similar to this, and ever since I&#039;ve switched to using it I&#039;ve noticed a large increase in my productivity in creating complex, manageable styles. What&#039;s best is that with this feature, CSS becomes much more refactor-able - you can move blocks around or re-parent them with very little effort. Knocking out the redundancy is key in that situation. Honestly, there are projects I&#039;ve worked on where having this one feature has saved huge amounts of time and made the stylesheets immensely easier to read. 

SASS also adds a nice bit, the &quot;&amp;&quot; symbol, which lets you reference the parent selector when defining inner selectors, which can be useful for things like pseudo-selectors and browser-specific scoping:
&lt;code&gt;
#content {
&#160;&#160;width: 30px;
&#160;&#160;.msie &amp; {
&#160;&#160;&#160;&#160;width: 35px;
&#160;&#160;}
&#160;&#160;&amp;:hover {
&#160;&#160;&#160;&#160;color: blue;
&#160;&#160;}
}
&lt;/code&gt;
expands to:
&lt;code&gt;
#content {
&#160;&#160;width: 30px;
}
.msie #content {
&#160;&#160;width: 35px;
}
#content:hover {
&#160;&#160;color: blue;
}&lt;/code&gt;]]></description>
		<content:encoded><![CDATA[<p>As others have mentioned, SASS supports something very similar to this, and ever since I&#8217;ve switched to using it I&#8217;ve noticed a large increase in my productivity in creating complex, manageable styles. What&#8217;s best is that with this feature, CSS becomes much more refactor-able &#8211; you can move blocks around or re-parent them with very little effort. Knocking out the redundancy is key in that situation. Honestly, there are projects I&#8217;ve worked on where having this one feature has saved huge amounts of time and made the stylesheets immensely easier to read. </p>
<p>SASS also adds a nice bit, the &#8220;&amp;&#8221; symbol, which lets you reference the parent selector when defining inner selectors, which can be useful for things like pseudo-selectors and browser-specific scoping:<br />
<code><br />
#content {<br />
&nbsp;&nbsp;width: 30px;<br />
&nbsp;&nbsp;.msie &amp; {<br />
&nbsp;&nbsp;&nbsp;&nbsp;width: 35px;<br />
&nbsp;&nbsp;}<br />
&nbsp;&nbsp;&amp;:hover {<br />
&nbsp;&nbsp;&nbsp;&nbsp;color: blue;<br />
&nbsp;&nbsp;}<br />
}<br />
</code><br />
expands to:<br />
<code><br />
#content {<br />
&nbsp;&nbsp;width: 30px;<br />
}<br />
.msie #content {<br />
&nbsp;&nbsp;width: 35px;<br />
}<br />
#content:hover {<br />
&nbsp;&nbsp;color: blue;<br />
}</code></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Thomas Tallyce</title>
		<link>http://meyerweb.com/eric/thoughts/2009/02/12/selector-blocks/#comment-443320</link>
		<dc:creator>Thomas Tallyce</dc:creator>
		<pubDate>Tue, 17 Feb 2009 14:18:46 +0000</pubDate>
		<guid isPermaLink="false">http://meyerweb.com/?p=1034#comment-443320</guid>
		<description><![CDATA[Real shame about the inability to implement parent selectors. The classic use case is indeed images that have a link round them, but you don&#039;t want underlining.

Perhaps Eric&#039;s proposal for any-element linking would remove that use case?]]></description>
		<content:encoded><![CDATA[<p>Real shame about the inability to implement parent selectors. The classic use case is indeed images that have a link round them, but you don&#8217;t want underlining.</p>
<p>Perhaps Eric&#8217;s proposal for any-element linking would remove that use case?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Max Design - standards based web design, development and training &#187; Some links for light reading (17/2/09)</title>
		<link>http://meyerweb.com/eric/thoughts/2009/02/12/selector-blocks/#comment-443277</link>
		<dc:creator>Max Design - standards based web design, development and training &#187; Some links for light reading (17/2/09)</dc:creator>
		<pubDate>Tue, 17 Feb 2009 08:00:12 +0000</pubDate>
		<guid isPermaLink="false">http://meyerweb.com/?p=1034#comment-443277</guid>
		<description><![CDATA[[...] Eric&#8217;s Archived Thoughts: CSS3 Feedback: Selector Blocks [...]]]></description>
		<content:encoded><![CDATA[<p>[...] Eric&#8217;s Archived Thoughts: CSS3 Feedback: Selector Blocks [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jason Penney</title>
		<link>http://meyerweb.com/eric/thoughts/2009/02/12/selector-blocks/#comment-443219</link>
		<dc:creator>Jason Penney</dc:creator>
		<pubDate>Mon, 16 Feb 2009 19:44:54 +0000</pubDate>
		<guid isPermaLink="false">http://meyerweb.com/?p=1034#comment-443219</guid>
		<description><![CDATA[I sometimes have to work with third party controls that inject their own styles, but don&#039;t take enough care to make sure they aren&#039;t inheriting something that will cause the whole thing to fall apart.

More then once I&#039;ve copied the entire contents of reset.css and replaced each selector with some prefix rule, and I really like the idea of being able to do:

&lt;code&gt;#someContainer {@import url(reset.css);}&lt;/code&gt;]]></description>
		<content:encoded><![CDATA[<p>I sometimes have to work with third party controls that inject their own styles, but don&#8217;t take enough care to make sure they aren&#8217;t inheriting something that will cause the whole thing to fall apart.</p>
<p>More then once I&#8217;ve copied the entire contents of reset.css and replaced each selector with some prefix rule, and I really like the idea of being able to do:</p>
<p><code>#someContainer {@import url(reset.css);}</code></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stephen Howard</title>
		<link>http://meyerweb.com/eric/thoughts/2009/02/12/selector-blocks/#comment-443210</link>
		<dc:creator>Stephen Howard</dc:creator>
		<pubDate>Mon, 16 Feb 2009 18:12:29 +0000</pubDate>
		<guid isPermaLink="false">http://meyerweb.com/?p=1034#comment-443210</guid>
		<description><![CDATA[Just to clarify, when I mentioned preprocessing it was because I wish CSS did this natively, and I was just looking to do it for myself as I didn&#039;t know if it would ever happen in the standard.  The less preprocessing the better, I think.]]></description>
		<content:encoded><![CDATA[<p>Just to clarify, when I mentioned preprocessing it was because I wish CSS did this natively, and I was just looking to do it for myself as I didn&#8217;t know if it would ever happen in the standard.  The less preprocessing the better, I think.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Erik Mogensen</title>
		<link>http://meyerweb.com/eric/thoughts/2009/02/12/selector-blocks/#comment-443187</link>
		<dc:creator>Erik Mogensen</dc:creator>
		<pubDate>Mon, 16 Feb 2009 14:23:44 +0000</pubDate>
		<guid isPermaLink="false">http://meyerweb.com/?p=1034#comment-443187</guid>
		<description><![CDATA[Wirh regard to descendant selectors, I would build on today&#039;s selector syntax:

&lt;code&gt;
body.home #content &gt; .entry &gt; {
 h1, h2, h3, h4, h5, h6 {...}
}
&lt;/code&gt;]]></description>
		<content:encoded><![CDATA[<p>Wirh regard to descendant selectors, I would build on today&#8217;s selector syntax:</p>
<p><code><br />
body.home #content &gt; .entry &gt; {<br />
 h1, h2, h3, h4, h5, h6 {...}<br />
}<br />
</code></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tim Wright</title>
		<link>http://meyerweb.com/eric/thoughts/2009/02/12/selector-blocks/#comment-443024</link>
		<dc:creator>Tim Wright</dc:creator>
		<pubDate>Sun, 15 Feb 2009 16:43:00 +0000</pubDate>
		<guid isPermaLink="false">http://meyerweb.com/?p=1034#comment-443024</guid>
		<description><![CDATA[I&#039;m actually not a fan of nesting CSS like that. It doesn&#039;t seem like it would advance CSS at all, just bring up more arguments about structure. 

I&#039;d really rather see CSS variables implemented.]]></description>
		<content:encoded><![CDATA[<p>I&#8217;m actually not a fan of nesting CSS like that. It doesn&#8217;t seem like it would advance CSS at all, just bring up more arguments about structure. </p>
<p>I&#8217;d really rather see CSS variables implemented.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jemaleddin</title>
		<link>http://meyerweb.com/eric/thoughts/2009/02/12/selector-blocks/#comment-443023</link>
		<dc:creator>Jemaleddin</dc:creator>
		<pubDate>Sun, 15 Feb 2009 16:37:31 +0000</pubDate>
		<guid isPermaLink="false">http://meyerweb.com/?p=1034#comment-443023</guid>
		<description><![CDATA[Another nice thing would be to take thinks like blueprint classes and equate them to a single class:

#headline { .span-12, .prepend-5, .append-7, .last, .column }

Semantics + grid = awesome.]]></description>
		<content:encoded><![CDATA[<p>Another nice thing would be to take thinks like blueprint classes and equate them to a single class:</p>
<p>#headline { .span-12, .prepend-5, .append-7, .last, .column }</p>
<p>Semantics + grid = awesome.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steven</title>
		<link>http://meyerweb.com/eric/thoughts/2009/02/12/selector-blocks/#comment-442569</link>
		<dc:creator>Steven</dc:creator>
		<pubDate>Fri, 13 Feb 2009 15:55:27 +0000</pubDate>
		<guid isPermaLink="false">http://meyerweb.com/?p=1034#comment-442569</guid>
		<description><![CDATA[The comments feed comes up empty for me, btw ...]]></description>
		<content:encoded><![CDATA[<p>The comments feed comes up empty for me, btw &#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Johnson</title>
		<link>http://meyerweb.com/eric/thoughts/2009/02/12/selector-blocks/#comment-442553</link>
		<dc:creator>Michael Johnson</dc:creator>
		<pubDate>Fri, 13 Feb 2009 14:53:01 +0000</pubDate>
		<guid isPermaLink="false">http://meyerweb.com/?p=1034#comment-442553</guid>
		<description><![CDATA[&lt;a href=&quot;http://meyerweb.com/eric/thoughts/2009/02/12/selector-blocks/?#comment-442412&quot; rel=&quot;nofollow&quot;&gt;Steven&lt;/a&gt;, I don&#039;t have time to do it right now, but I&#039;ll try to work on the Dojo Soria stylesheet tonight. That&#039;s 350 rules in 1474 lines and about 41KB.

But you may be right about the gzip compression. The soria.css file compresses to 6536 bytes from 41374 bytes uncompressed, for 84% compression rate. However, I still perfer the grouping from a readability/maintainability standpoint.]]></description>
		<content:encoded><![CDATA[<p><a href="http://meyerweb.com/eric/thoughts/2009/02/12/selector-blocks/?#comment-442412" rel="nofollow">Steven</a>, I don&#8217;t have time to do it right now, but I&#8217;ll try to work on the Dojo Soria stylesheet tonight. That&#8217;s 350 rules in 1474 lines and about 41KB.</p>
<p>But you may be right about the gzip compression. The soria.css file compresses to 6536 bytes from 41374 bytes uncompressed, for 84% compression rate. However, I still perfer the grouping from a readability/maintainability standpoint.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bertilo Wennergren</title>
		<link>http://meyerweb.com/eric/thoughts/2009/02/12/selector-blocks/#comment-442537</link>
		<dc:creator>Bertilo Wennergren</dc:creator>
		<pubDate>Fri, 13 Feb 2009 14:15:25 +0000</pubDate>
		<guid isPermaLink="false">http://meyerweb.com/?p=1034#comment-442537</guid>
		<description><![CDATA[I agree with Eric that the HTML 5 scooped style element seems like a bad idea.

The thing that struck me about it, is that it would work (somewhat) well only for styles that are scooped for certain unique elements. It could do the equivalent of this:


@with #mydiv {
  .this { ... }
  .that { ... }
}


But it could not do anything like this:


@with .mykindofdiv {
  .this { ... }
  .that { ... }
}


You&#039;d have to add a scooped style element to every single div with the class &quot;mykindofdiv&quot;. That kind of repetition is not the right thing to do.]]></description>
		<content:encoded><![CDATA[<p>I agree with Eric that the HTML 5 scooped style element seems like a bad idea.</p>
<p>The thing that struck me about it, is that it would work (somewhat) well only for styles that are scooped for certain unique elements. It could do the equivalent of this:</p>
<p>@with #mydiv {<br />
  .this { &#8230; }<br />
  .that { &#8230; }<br />
}</p>
<p>But it could not do anything like this:</p>
<p>@with .mykindofdiv {<br />
  .this { &#8230; }<br />
  .that { &#8230; }<br />
}</p>
<p>You&#8217;d have to add a scooped style element to every single div with the class &#8220;mykindofdiv&#8221;. That kind of repetition is not the right thing to do.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Eric Meyer</title>
		<link>http://meyerweb.com/eric/thoughts/2009/02/12/selector-blocks/#comment-442529</link>
		<dc:creator>Eric Meyer</dc:creator>
		<pubDate>Fri, 13 Feb 2009 13:38:55 +0000</pubDate>
		<guid isPermaLink="false">http://meyerweb.com/?p=1034#comment-442529</guid>
		<description><![CDATA[&lt;a href=&quot;http://meyerweb.com/eric/thoughts/2009/02/12/selector-blocks/#comment-442323&quot; rel=&quot;nofollow&quot;&gt;Lachlan&lt;/a&gt;, so far as I can tell, that exact same capability exists in the CSS style-attribute module to which I linked, and it has for almost seven years now.  What&#039;s the rationale for adding brand-new element capabilities to HTML 5 in this circumstance, when the same thing could be done more cleanly through CSS alone?]]></description>
		<content:encoded><![CDATA[<p><a href="http://meyerweb.com/eric/thoughts/2009/02/12/selector-blocks/#comment-442323" rel="nofollow">Lachlan</a>, so far as I can tell, that exact same capability exists in the CSS style-attribute module to which I linked, and it has for almost seven years now.  What&#8217;s the rationale for adding brand-new element capabilities to HTML 5 in this circumstance, when the same thing could be done more cleanly through CSS alone?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
<!-- WP Super Cache is installed but broken. The path to wp-cache-phase1.php in wp-content/advanced-cache.php must be fixed! -->