Love nesting, hating generated selectors.

[gnrlbzik]

So compass/sass parses out nesting as it interprets it. Literely. 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?

[Chris Eppstein]

I don't understand. Can you provide some code examples that demonstrate what you're talking about?

--
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.

[Brandon Craig Rhodes]

gnrlbzik <gnrl...@gmail.com> writes:

> 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

[Raving Genius]

SASS only generates as many levels of nesting that you specify. Do you
want it to arbitrarily limit your nesting in the generated CSS? For
instance if you have styles that nest 7 levels deep, SASS would only
output at most 5 selector levels automatically? I created a gist
(https://gist.github.com/887370) to illustrate what I *think* you are
talking about. Please correct me if that is not what you meant.

If that is indeed what you are wanting, I would say this should not be
the default behavior and it should be configurable.

[Alesei N]

@Raving Genius yes this is what i meant.

i am just asking for now if this is something that is available. through configuration or through flaging of some sort per selector.

why i have asked this, as per  Raving Genius code sample.  I like the idea that in compass/sass i get to nest things which in long term help you organise code very well. But if you go beyond two levels down, selectors become radically huge and inaficient, and in many cases to achive application of style to particular element, you do not need to be that specific, unless there is a conflict of rules that you need to resolve.

I will provide coding example later tonight, as soon as i get home.

Thank you.

Alesei Narkevitch
224.392.2592
gnrlbzik / skype & gtalk

[Raving Genius]

If you are nesting this deep, however, you are doing it wrong. It
would always be better and safer to manually cut back the number of
nested selectors you are using.

[Alesei N]

well i know, thats why i was wondering, if i can keep the nesting for organizational purposes and not pollute the selector. i never go beyond 2nd level down in nesting.

Thank you.

Alesei Narkevitch
224.392.2592
gnrlbzik / skype & gtalk

[Chris Eppstein]

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.

chris

[Brandon Craig Rhodes]

Chris Eppstein <ch...@eppsteins.net> writes:

> 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. :-)

[Chris Eppstein]

If that's the case, i'm -1 on that feature.

chris

--

[Alesei N]

I am not asking to implement this feature, i am asking if such minification is available. To optimize selector. When necessary.

It is fair to assume that i might not completely understand the use of concentric selector building as Brandon Craig Rhodes have said.

But, still.

Thank you.

Alesei Narkevitch
224.392.2592
gnrlbzik / skype & gtalk

[Chris Eppstein]

Sass does not currently do any optimizations except compression.

chris

[Lorin Tackett]

If feels like you are criticizing the powerfulness of a tool, rather than asking how to swing the hammer. It would benefit everyone who's trying to help you if you would copy/paste a more specific example of the problem you're having.

Chances are, you're abusing one of the features that makes Sass powerful. You're certainly not alone on that one; I once generated a 2mb selector (!!!!) with careless nesting before. Sass has no problem shooting you squarely in the foot, if you ask it nicely.

-Lorin

[Chris Eppstein]

Just to be clear, Lorin has a unique ability to fail spectacularly. #zing

[Lorin Tackett]

=D

It's true.

[Alesei N]

here is an example: git://gist.github.com/887612.git

Thank you.

Alesei Narkevitch
224.392.2592
gnrlbzik / skype & gtalk

[Chris Eppstein]

I don't understand why you don't just write what you want to have.

[Lorin Tackett]

I agree with Chris. That is certainly the lowest overhead to get the result you want. However, if you want the nesting for organization, you can do something similar to this: 

https://gist.github.com/887634

-Lorin

[Brandon Craig Rhodes]

Alesei N <gnrl...@gmail.com> writes:

> …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.

[Alesei N]

Chris, i already do that and have been for many years, i specifically format my code for readability and use comments to group related portions  in dev environment before i deploy.

nesting in SASS just gave me a valid way to omit the practice that i usually follow, because i can practically achieve the same effect with less effort and greater readability. Even though SASS nesting is essentially done for other reasons.

Thank you.

Alesei Narkevitch
224.392.2592
gnrlbzik / skype & gtalk

[Alesei N]

Brandon,

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.

 

Thank you.

Alesei Narkevitch
224.392.2592
gnrlbzik / skype & gtalk

--

[Brandon Craig Rhodes]

Alesei N <gnrl...@gmail.com> writes:

> 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?

[Alesei N]

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.

On Mar 25, 2011 5:17 PM, "Brandon Craig Rhodes" <bra...@rhodesmill.org> wrote:

[Alesei N]

Why mocking bandwidth?

[Eric Meyer]

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.

[Mario "Kuroir" Ricalde]

Just don't nest more than what is needed. I usually use my command to convert all nodes from HTML to SCSS but then I gradually make them into lower nestings.

For instance you'll usually see something like:

.module a

.module b

.module .header h1

.module .header a

Never do what the guys from Inception did, go deeper than 4 levels.

-- 
Mario "Kuroir" Ricalde

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.

--

[Alesei N]

Eric and Mario.

Thanks for your input, I am not trying to be an ass or anything, but i perfectly understand the techniques that i need to use to achieve my selectors out of compass context and with understanding the limitation of compass and it actual purpose i now adjusted my coding practice accordingly.

But the intent of my original post was to find out if compass can give me an ability to control the selectors complexity within SCSS nesting, like specifying flag that would exclude tag/class/id of direct parent item.

Compass still translates SCSS into css. it is a adjusted syntax of css, so why would I not be able to do certain modifications like that in theory, another question, does compass provide this capability.

Thank you.

Alesei Narkevitch
224.392.2592
gnrlbzik / skype & gtalk

[capi etheriel]

@alesei: probably, the issue is you're mapping your selectors to your markup, like:

.menu 

  li.item {

    background-color: blue;

    a {

      text-decoration: none; } }

but really, you only need

.menu

  .item {

    background-color: blue; }

  a {

  text-decoration: none; }

think like this and you will rarely ever write a selector of more than three levels.

i implemented selectors for every core feature of drupal barely using the third level.