better sass

[CPJ]

Hello,

 

Great work with sass. It would be nice to be able also to “cut” extra selectors for even smaller css file and keep the right structure of scss file.

 

Example:

 

scss:

 

#main {

 .button {

   border 1px solid red;

 

 #left{

  a {

   color: black;

  }

 

  .button {

    border: 1px solid black;

  }

 

 }

}

 

the resultin css should be:

 

.button {  // here it cutted the extra #main

 border: 1px solid red;

}

 

#left .button {  // here cutted the extra #main but kept the #left for selector priority

 border: 1px solid black;

}

 

a {  // cutted the #left and #main selectors

 color: black;

}

 

And this should keep track through all scss files inside the project.

 

 

[Roy Tomeij]

That's a terribly bad idea :) This will literally break pretty much every website using Sass. You may want to brush up on your CSS, cascade, etc :)

[anotheruiguy]

Wait, what? You want nested selectors to be output as parent selectors? How is this perceived as a benefit? 

[Lorin Tackett]

Hrm… I see scoping as a very good idea. What you're asking for sounds confusing… especially at scale of multiple thousands of lines over numerous files.

When I scope a set of rules, I don't want to be left wondering whether I've given them a global definition. In many cases, I wouldn't have. Which means my scopes will unintentionally bleed onto other styles in the application in a very unpredictable fashion.

Can you give me a use-case where this works better than 1-to-1, predictable selector nesting?

--
You received this message because you are subscribed to the Google Groups "Sass" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sass-lang+...@googlegroups.com.
To post to this group, send email to sass...@googlegroups.com.
Visit this group at http://groups.google.com/group/sass-lang?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[CPJ]

I don't think it's a terribly bad idea. Actually I think is a very good idea. That's what I would like for sass to be able to do.

The benefit is that the generated css files are much smaller while the scss files are easyear to read, track (code) and modify.

It can be done as long as the preprocessor keeps track of all the scss files inside the project and all of them are preprocessed even if only one scss file is modified.

I would love to see this made.

[Chris Eppstein]

Any such optimization implies an adherence to a coding standard that is no way universal. Sass is not opinionated about such things and so we cannot introduce optimizations that could break a website.

However, there are a number of optimizations that *can* be done safely, but which we are not doing yet, and we do have that project on our TODO list.

Chris

[CPJ]

I can see where the cofusion is but let me explain:

In case of the "a" selector, in this particular case, if you write inside css
a
is exacly the same (the same final result when showing the page inside the browser) as
#main #left a

In case of .button however, we have two conflicting .button one inside #main and the other inside #main #left. In this case (of conflicting selectors), there are not all scope selectors dropped but only the ones that are not necessary (like #main in this case). If you think about what I said in the first post, you'll find that the normal resulting css file (as sass does it right now) and the proposed css file as I wrote in my first post gives identical results inside the browser.
So, in case of non conflicting selectors the scopes are dropped and in case of conflicting selectors, there are added only the needed scopes to modify the selectors priority and drop the other.
Maybe when I express myself in english I'm not that well understud. However, I hope this makes the things clearer.

[Chris Eppstein]

I think you should just write the selectors that you want to end up with. Obviousness is a feature.

Chris

[CPJ]

What if one has a very complex structure with many nested selectors and each one has some declarations inside. That means it cannot drop any of them inside the nested scss code. It could make an outside (of nested scss code) declaration of that selector in order to keep the resulting css file smaller. Than keeping track is harder when you use only some selectors and not make the scss code nested (as html page is).
Ok, what you propose me is similar to what's happening inside css and people have managed to do things in the past. I think we use preprocessor in order to make things easyer (kipping better track of scss code, in this case) and better (keeping the resulting css files smaller).

Take this example

#main {
  a { color: black}
  .columns {
    #left {
      a {color: red}
    }
  }
}

The resulting css would be:
#main a {color:black}
#main .column #left a {color: red}

of course this could be written inside scss, in order to get smaller resulting css file as:

#main {
  a {color: black}
}

.columns #left a {color: red}   // or #main #left a as selector and scope

But that way you loose track of what is where and you probably have to look inside html file in order to keept track.


This is my proposal for sass team. I think is a great idea and should keep it in mind. I know it's not a easy one to do, but it has many benefits.

Best regards.

[Roy Tomeij]

As Chris said, just write what you want. If you want "a" and not "#main a", just write "a". If I nest "a" within "#main", I most certainly want Sass to output "#main a". If you believe "#main a" and "a" are the same, you have no idea how CSS works.

[CJC]

I'd have to agree with the majority here. If it hurts seeing this don't look at the output ;)

Has anyone done any extensive tests or seen anything to prove more explicit can slow down the render?

[CPJ]

I think rendering speed is not modified.
What is modified is the size of resulting css, which results in lower download time and lower GPRS/3G costs.
It's the same thing as the difference between compressed and expanded output. And, if you wish, it has the same effect as using @extend %xxx. You use both of them (compressed and @extend), to get smaller css file.
I think by using this technique you can reduce the size of resulting css by 25-50% without broking the nesting inside scss.

Anyway, thank you for all your opinions.

[Roy Tomeij]

Gzip your code. The size difference will be nearly non-existent :)

While your proposal does indeed (significantly) decrease file size, it will break apps. Authors rely on the cascade, and they no longer can't if we start making modifications under the hood that alter specificity for instance.

[Eric Meyer]

It actually doesn't matter how much this would optimize the file, it simply *can not* work. There is no possible way to do it without breaking the cascade because there is no way for a pre-processor to know what your code actually represents. 

The cascade is to important and fragile to let a pre-processor touch it. Authors don't just rely on the cascade - it defines what CSS is. The cascade is the very core of the language, and these "optimizations" drastically alter the meaning of the code.

If you want your "a" style scope to be global, put it there. If you want it nested, nest it. Those are important decisions for the developer to make. They have different meanings, and can't be automated.

-e