--
You received this message because you are subscribed to the Google Groups "Compass" group.
To post to this group, send email to compas...@googlegroups.com.
To unsubscribe from this group, send email to compass-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/compass-users?hl=en.
> Is there currently a way to tell compass/sass to support selector
> minification. Instead of interpreting nesting literally, maybe it is
> able to remove unnessessary levels if they are nor required to get to
> the element to which you are trying to apply style to?
Could you provide a concrete example of an annoyingly long selector that
Sass is producing and how you would like it shortened, so that we can
see a concrete case of how such minification would work?
--
Brandon Craig Rhodes bra...@rhodesmill.org http://rhodesmill.org/brandon
> Maybe I'm missing something here, but you have full control over how
> deep your nesting is in Sass. If you don't want deep nesting, don't
> make deep nesting.
You might be missing something. I *think* the questioner wants to use
nesting, which is how Sass lets us write a group of related selectors,
for a new purpose: to simply group related rules with indentation, but
*without* recursively building deep selectors.
I think the questioner should just use big "##################" comments
to group things instead of overloading a nice Sass feature like
concentric selector building, but it's not my call. :-)
--
> …if you go beyond two levels down, selectors become radically huge and
> inefficient…
Because this is a fairly new topic for me: how much efficiency is lost
in a browser like IE or Firefox when a selector is made more specific,
and becomes something long like:
#body div.content div.main p.text span.identifier
instead of something very short like:
p.text span.identifier
Is the problem that browsers have indexes with which they can find
everything that matches "p.text", but that if you qualify that with
"#body" then the indexing can't be used but a straight recursive search
beneath the "#body" element becomes the way to match the selector
instead? I would be interested to see some numbers on performance.
--
> i was not talking about browser rendering inefficiency. Plus what you
> have mentioned as an example is a bad and inefficient practice as is,
> with out linking it to browser rendering gaines and losses in my
> opinion.
What, then, is your objection? That more specific selectors cost bandwidth?
Brandon, it is valid css seletor. No doubt about it, and occasionally you need to write it in this manner.
But my fed experience tells me otherwise. In highly modular mark up and css structure, that exceeds 2000 lines of code for css alone. The less complex selector you have that based on selector naming convention you have implemented, the less likely of a chance you having of shooting yourself in the foot.
Why mocking bandwidth?
On Tuesday, March 29, 2011 at 10:52 PM, Eric Meyer wrote:
This is a problem inherent to CSS and not something that Compass/Sass could even address well if it wanted to. Your CSS (and Sass) has *no idea* what selectors would be efficient and still work, because your CSS (and Sass) knows nothing of your actual HTML structure, nor does it know when or how you are using the cascade to override different styles in different ways. You have to write it the way you want it because the way it is written effects what it means. There simply isn't any way to implement this reasonably in any CSS pre-processor. Any decision the processor would make would be a wild guess at what you meant.
--