Skip to content
This repository

[feature request] More intelligent compression #116

Open
rupert654 opened this Issue June 12, 2011 · 88 comments
rupert654

It would be great if SASS output could be configured to more intelligently compress output. Here are some examples:

# Combine name-spaced selectors
# SASS                             # Preferred Output                 # Current Output
body {                             body{border:3px solid #ccc;}       body{border-width:3px;border-color:#ccc;border-style:solid;}
  border: {
    width: 3px;
    color: #ccc;
    style: solid
    }
}

# Combine multiple declarations
# SASS                             # Preferred Output                 # Current Output
body { border: solid #ccc; }       body{border:3px solid #ccc;}       body{border:solid #ccc;}
body { border-width: 3px; }                                           body{border-width:3px;}

# SASS                             # Preferred Output                 # Current Output
body { color: #ccc; }              body{color:#ccc;cursor:pointer;}   body{color:#ccc;}
body { cursor: pointer; }                                             body{cursor:pointer;}          

# Ignore overridden declarations
# SASS                             # Preferred Output                 # Current Output
body { border: 2px solid #400; }   body{border:3px solid #ccc;}       body{border:2px solid #400;}
body { border: 3px solid #ccc; }                                      body{border:3px solid #ccc;}

This would allow you to more expressively organise stylesheets and partials without sacrificing on output length. For example, you could have color, typography and layout partials which, when compiled, gave the same output as if they had been written all mixed together.

There maybe gotchas with doing this due to the cascading nature of stylesheets and this effectively changes the ordering of declarations. However, I can't immediately think of specifics and the first case at least does not seem to be problematic.

This should also only apply when the compressed output option has been set as the readability of stylesheets may be impacted. For example, in development, it might be useful for the output to indicate that the designer has intended to split declarations in a particular way.

Albert Varaksin
albeva commented June 13, 2011

I think this should be part of new option to enable / disable optimizations. Another opportunity for optimizations is coalescing common properties:

/* for example: */
.foo { width: 10px; height: 10px; color: red; }
.bar { width: 10px; height: 10px; color: yellow; }
/* would become: */
.foo, .bar { width:10px; height:10px; }
.foo { color: red; }
.bar { color: yellow }

This kind of optimization is not safe however and therefore users should be able to test and see what side effects if any appear.

Grady Kuhnline

This may not be 100% related to this thread but I've seen every other marginally related ticket being closed and referred here.

Specifically for dealing with media queries it would be useful to use some sort of output buffering to stash some css rules for later inclusion. The issue is hinted at in the media queries blog article where trying to correct for media queries inline will result in a number of identical @media declarations that have different rules in them. Output buffering will solve this really well. Each buffer would be named and additive so each time it is invoked, more is appended to the end of it. Once a buffer is output it is flushed.

Buffering is a completely different usecase than a @mixin. Buffers would allow for the creation of a responsive grid plugin that expected specific buffers for specific @media blocks. Additionally it'd be useful for projects that want to create print styles using @print blocks. Currently the only way to manage this is to simply add your additional rules directly to the media queries which is effective but can make the code a little harder to track. Not having buffers also completely removes the capability of using canned media queries baked into a compass extension, making it harder to convert projects like 320 and up into SASS for easy re-use.

Here's a simple example:

.left-column {
  width: 300px; // for browsers that don't support media queries
  @buffer small-devices {
    & { width: 100%; }
  }
  @buffer medium-devices {
    & { width: 150px; }
  }
  @buffer large-devices {
    & { width: 300px; }
  }
}
.main-column {
  width: 660px; // for browsers that don't support media queries
  @buffer small-devices {
    & { width: 100%; }
  }
  @buffer medium-devices {
    & { width: 330px; }
  }
  @buffer large-devices {
    & { width: 660px; }
  }
}


@media only screen and (min-width: 0) {
  @output small-devices;
}
@media only screen and (min-width: 768px) {
  @output medium-devices;
}
@media only screen and (min-width: 992px) {
  @output large-devices;
}
  • buffers are output at the time that @output is called in the natural CSS order. So if you add to a buffer after it's been output, nothing happens.
  • you can easily add more to a buffer using the names.
  • it might be useful to clear a named buffer with something like @clean my-buffer;
  • I don't know if it's possible to use the & symbol in content blocks like in my example but it'd be really useful.
  • It would also be useful to use the bubbling feature similar to how @media works. Something like div { @buffer my-buffer { width: 100px; } width: 200px; }
Maxime Fabre

Didn't think about an output buffer approach for media queries but I gotta say it doesn't look bad.

Norris

The buffer solution really looks good here...

Adam Campbell

+1

Olivier Gorzalka

yeah +1 for the buffer !

Kenneth Auchenberg

+1

cjcheshire
  • 1 and + 1 for media query squishing!
Nathaniel Higgins

+1 for everything suggested!

Deleted user
ghost commented July 06, 2012

The content you are editing has changed. Reload the page and try again.

+1 for sure.

Sending Request…

Attach images by dragging & dropping or selecting them. Octocat-spinner-32 Uploading your images… Unfortunately, we don't support that file type. Try again with a PNG, GIF, or JPG. Yowza, that's a big file. Try again with an image file smaller than 10MB. This browser doesn't support image attachments. We recommend updating to the latest Internet Explorer, Google Chrome, or Firefox. Something went really wrong, and we can't process that image. Try again.

Mike Simmonds
simmo commented July 23, 2012

+1 Great solution. Buffer would be a great feature.

Josh Rives

+1 for not repeating "@media screen and" a thousand times in my live file

Stan Angeloff

I've been hacking on a @buffer support in Sass and progress can be seen on StanAngeloff@nex3:master...StanAngeloff:feature/buffers The code is working at the moment, but lacks some features (see further down).

I plan on using this for my own projects, but if there is enough interest and the code is bug-free, I would be happy to submit a pull request for inclusion in core Sass.

The syntax I used is:

$device-size:  small;
$device-width: 640px;

body {
  color: white;
  @buffer #{$device-size}-screen {
    color: black;
  }
}

h1 {
  color: white;
  @buffer #{$device-size}-screen {
    color: black;

    .no-js & { color: red; }
  }
}

@media only screen and (max-width: #{$device-width}) {
  @flush #{$device-size}-screen;
}

Several features can be seen in action in the snippet above:

  • Rule bubbling
  • Interpolations
  • Parent selector (&) support
  • Converting between .scss <=> .sass using sass-convert

There is support for using @buffer within .sass files as well:

$device-size:  small
$device-width: 640px

body
  color: white
  #{$device-size}-screen ->
    color: black

h1
  color: white
  #{$device-size}-screen ->
    color: black

    .no-js &
      color: red

@media only screen and (max-width: #{$device-width})
  <- #{$device-size}-screen

What doesn't work / is missing

  • Error reporting and debugging has not been tested extensively
  • Buffer functions are not provided, e.g., buffer-exists(..) or buffer-empty(..)
  • This one is more for personal use -- ability to write buffers to files, i.e., generating media-specific files so main stylesheet can remain optimised for desktop screens

Try it out

  • Clone the repo

    $ git clone git://github.com/StanAngeloff/sass.git
    
  • Check out the feature/buffers branch

    $ cd sass
    $ git checkout feature/buffers
    
  • Build and install the gem

    $ gem build *.gemspec
    $ gem install --local *.gem
    

Feedback welcomed very much.

Mike Simmonds
simmo commented July 30, 2012

@StanAngeloff Very interested by this, it would be great if this was implemented into Sass.

Nathaniel Higgins

Does anyone have any reasoning for why this wouldn't be possible?

Luciano Battagliero

+1. Media queries are fundamentals these days, so would be really handy a more efficient way to manage the output to group them. Could be the one suggested by @heygrady —great idea BTW—, or another one, but would be nice to see some changes in the current approach.

Feross Aboukhadijeh

+1

Nathan Weizenbaum
Owner
nex3 commented August 20, 2012

@StanAngeloff Please open a separate pull request for your @buffer stuff so we can discuss it further. It's not directly related to this feature request.

Luciano Battagliero

@nex3 I think that @heygrady should open the separated pull request, since was his original idea and he probably can explain more in deep the matter. It's a really good idea the @buffer stuff. BTW: great work with the hacking @StanAngeloff.

iLan

+1. Would love to see something like this.

Grady Kuhnline

@ImBatta I didn't write any code, I was just offering an idea. I couldn't create a pull request without code. But thanks for thinking of me.

Luciano Battagliero

@heygrady Oh, you're right, I kinda suck in some GitHub stuff yet; sorry for the misunderstood. Hope the @buffer thing end up implemented.

But coming back to the original feature request, I don't think it's a good idea. These kind of compilation will cause many headaches for sure. Anyway, if many people is interested, it could be an optional way to compile.

Javier Sánchez - Marín

+1

Aaron Jensen

@StanAngeloff +1, how close is this to a pull request? This belongs in sass in my unqualified opinion.

Stan Angeloff

@aaronjensen: I have actually used my fork for a while now (eat your own dog food-style) and I am not happy with buffers.

I am not 100% convinced they are the best way of tackling the issue with @-media queries. You can already use @-if statements to output different queries to different files for each breakpoint so you don't really need buffers for that. On the other hand, if you want everything in a single file, a simple script file can do that for you on each stylesheet update.

So there's not a lot more left for buffers to solve IMHO.

In terms of a pull request, there have been changes in Sass around variadic functions so a rebase would be difficult. Furthermore, tests are incomplete in my implementation and you can do silly things like flushing a buffer from within the buffer itself causing a recursion and eventually a stack overflow. A lot of the tests are already duplicates of existing ones so there must be a better way of doing things.

Aaron Jensen

@StanAngeloff That's interesting to hear, I guess it makes sense. The only use case I could think of for it was media queries and combining them after the fact seems like it will work as long as you expect it and plan for it.

Thanks for the link to the script. Based of of that and a python version I found I just put together a sprockets processor that combines media queries: https://github.com/aaronjensen/sprockets-media_query_combiner

Maybe some will find it useful if all they want to do is merge media queries

jonascarlbaum

I read through this thread, allthough pretty fast, so could have missed something, haven't read the source code either, so I'm just saying that these are my bare thoughts after trying out Thoughtbot:s fine bourbon-extension neat and being a bit irritated over the duplicated media queries produced.

However, I was thinking about a different solution than the ones discussed here — it would be to implement buffer/rendering in the compiler, by using hashes and tree structures to store(add/appending) the rules, and finally render them instead of the present instant rendering routine — that would result in clean non-duplicated media queries etc.

The only consideration that comes in mind is the rule order, keeping the order in each level (css-rules only comes in two levels — document level and media query level), that could be accomplished by adding a counter for each interpreted sass-rule, and using it as a sort-index value for the interpreted row (rule or comments etc.), so rendering would be in correct order, preserving order for rows (rules and comments) — even in media queries — roughly thinking...

The fine thing in this is that the programmer that is using sass doesn't have to think of advanced buffers and other things, the sass-compiler would just do it right all the time — resulting in happy sass using programmers... ;)

Aaron Jensen

@jonascarlbaum I'm not entirely sure what you're describing, but I don't think there is a way to combine media queries and completely preserve the order of all rules if media queries are interleaved with non-media queries. Or am I missing something?

Did you see https://github.com/aaronjensen/sprockets-media_query_combiner ? It combines things without having to think about it. Of course it does put them all at the end of the css, so that changes the order.

Subbu

+1

jonascarlbaum
Grady Kuhnline

I would caution that, for Sass to remain successful, answers like, "another tool can do it", should be reviewed carefully. Sass has an issue with how to implement media queries and, more importantly, how to manage them on a significantly complex application.

What are the chances of getting the @buffer work turned into a Sass or Compass plugin? That way it can be installed on top of Sass without having to run a patched version of Sass. I think that is driving down adoption and preventing people from trying out what you've built.

I'm willing to hear that @buffer is more cumbersome in practice than it first appears. It may not make anything easier to work with. However, I worry about relying on 3rd party tools to cover up for the shortcomings of Sass. I would say that a tool like Media-query-combiner is more of a workaround than a long-term solution. I also feel like @bufffer has a broader application that may not even be understood.

The current official-ish solution is not ideal, as you end up with many duplicated media query rules. While a tool like sprockets-media-query-combiner may do the trick, it presupposes that users are on a project that has Sprockets available. Sass has a much broader audience than just Ruby on Rails developers and that means a Sprockets-based solution doesn't actually solve the problem for many users.

I personally see it as an issue that Sass is still so tied to Ruby on Rails. I see a lot of Node.js developers using Less.js instead of Sass because it integrates better with their platform. In my company, we use Sass on all of our projects and we rarely work on Ruby-based projects. We never have Sprockets available, many of our projects are on .NET. We use Compass to manage our real-time Sass compilation and simply forgo server-side, cached compilation that libraries like Sprockets afford.

I've seen threads debating the finer details of Sass vs Less vs Syltus syntax and I tend to agree that Sass is the most full featured and makes the most sense. However, portability is becoming an issue. Projects like libsass are trying to fix that (although I don't know how Compass would work with libsass). Recommending solutions to core issues that rely on platform specific 3rd party solutions is, IMHO, a poor approach.

Perhaps adding the essence of the sprockets-media-query-combiner to Sass is a better approach.

Aaron Jensen

I'm not actually familiar with how to add hooks into sass, otherwise I'd gladly drop the sprockets- part and make it sass-.

I totally agree that sprockets-media_query_combiner probably should not be a long term solution. The nuances with ordering of your media queries mean you have to be quite cognizant while using it or you can end up with media queries in the wrong order.

The buffer approach lets you specify the orders of your media queries well and be explicit. It would be magical if there were a way to get the buffer approach to span files so that you could, for example extract your media queries to their own file.

In other words, to take your previous example:

// application.css.scss
$device-size:  small;
$device-width: 640px;

body {
  color: white;
  @buffer #{$device-size}-screen {
    color: black;
  }
}

h1 {
  color: white;
  @buffer #{$device-size}-screen {
    color: black;

    .no-js & { color: red; }
  }
}

// media-queries.css.scss
@media only screen and (max-width: #{$device-width}) {
  @flush 'application', #{$device-size}-screen;
}

If the buffers were a plugin I would use it over the combiner I'd guess. I like the explicitness over the magic.

Grady Kuhnline

Compass has some thin documentation on creating a Compass plugin. That's probably the easiest way to approach it. There also appears to be some docs on writing plugin hooks for Sass. I've created a few Compass plugins but I got stuck on more complicated efforts because the documentation is pretty light and possibly inaccurate.

Aaron Jensen

Sass::Plugin seems to be more the thing that is used when sass is used as a plugin, rather than for adding plugins. Looking at the source, it seems the only real place that I can tell to insert the media query combiner would be in Sass::Engine#render, basically I'd need to alias method chain it. Maybe I'm missing something though.

Grady Kuhnline

I think Compass is the avenue for extending Sass. The internet has no advice that I can uncover.

Aaron Jensen

Even Compass simply monkey-patches sass when it wants to change behavior. I haven't seen any compass hooks that allow for modifying the pipeline. Unless there's something I'm missing

Aaron Jensen

Whipped together a quick sass only plugin to do the same thing: https://github.com/aaronjensen/sass-media_query_combiner

I should probably combine them into one gem. Another night I guess.

Josh Farneman

+1

Brett Jankord

+1 Would love to see this feature added.

Erin Keeffe

+1 Would also find this very helpful!

Alex Parker

I am working on a rails app, and was getting annoyed with the countless number of @media queries output when nesting @media. I love the nesting, but the output is not ideal.

I wrote this up: https://gist.github.com/4010097 then discovered this thread here. For those that don't want to jump to the gist:

I came to the same buffer conclusion, but with a slightly different approach, that felt similar to mixins, where they are predefined, rather than, "on the fly" I'm not sure which one is easier to implement into the sass source, but here is my pitch on it:

@buffer handhelds {
  @media only screen and (max-width: 959px) {
    @content;
  }  
}

.bluespace {
  width: 800px;
  height: 400px;
  background-color: blue;
  @append handhelds {
    width: 600px;
    height: 300px;
  }
}

.greenspace {
  width: 300px;
  height: 150px;
  @append handhelds {
    width: 200px;
    height: 100px;
  }
}

@flush handhelds;

As expected, this would produce:

.bluespace {
  width: 800px;
  height: 400px;
  background-color: blue;
}

.greenspace {
  width: 300px;
  height: 150px;
}

@media only screen and (max-width: 959px) {
  .bluespace {
    width: 600px;
    height: 300px;
  }
  .greenspace {
    width: 200px;
    height: 100px;
  }
}

I'm not sure if this is too significantly different other than predefining it first. All I know is i would love this functionality, but am too new to this to build the functionality into sass myself. Otherwise, I would be all over it.

Snugug
Aaron Jensen

the media query test Snugug mentions is here: http://aaronjensen.github.com/media_query_test/

It seems the primary benefit is file size and with compression the differences are minimal. Without compression it seems to be in the 3k range for a "reasonable" 40 media queries.

Ian Hill

I'm very keen to see some form of grouping, buffering or push stack mixins available in Sass.

I recently put together a demo of how buffering can be used in LESS, for features like media query grouping. I thought it might be useful as a talking point for this discussion.

Ideally, I'd like to achieve a similar result with Sass - If I've missed features in Sass that allow it to mirror this behaviour succinctly, please let me know.

For details, take a look at the overview and demo repo at: https://github.com/buymeasoda/less-media-queries

To paraphrase - In LESS, if you call a mixin multiple times, each call pushes the declaration onto a stack (similar to buffering):

.320up() {
    .nav {}
}

.320up() {
    .menu {}
}

When you finally use the mixin:

@media only screen and (min-width: 320px) {
    .320up;
}

It renders all the rules you added, in the order you defined:

@media only screen and (min-width: 320px) {
    .nav {}
    .menu {}
}

Using this technique, it's quite easy to write CSS with media queries in-place, alongside their related rules - and then output an optimised style sheet with grouped media queries, as well as separate legacy or IE specific style sheets from a single source.

There's the usual caveat of cascade order when using this approach, but I see that as a problem to be managed by the people authoring the CSS, rather that the pre-processor.

Artem Rizhov

You all are speaking about media and buffering, however the issue is about organising partials. I'd propose to move any talks about media and buffering to separated issue, because this is different thing.

Here is my vision of problem. I have a project where I have some special pages with different themes. All pages in a category have same structure, but differs in colors and images. Categories may differ in details, but they all have same layout. Also each theme has variants for different screen widths. Finally I need to compile all those parts to single stylesheet, because the page load speed is very important for this project. Each user will usually use one page, and I don't need to have any common stylesheet files. So, I have structure like this:

base.scss:

#header { font-family: Verdana; }

category1.scss

import "base.scss"
#header { height: 50px; }

theme1.scss

import "category1.scss"
#header { background: #abc; }

1024.scss

import "theme1.scss"
#header { width: 900px; }

This compiles to

#header { font-family: Verdana; }
#header { height: 50px; }
#header { background: #abc; }
#header { width: 900px; }

Now imagine I have about 50 selectors repeating in each file. The problem is that compiled css is too large and to messy. There are also another use cases. For example, you may use some base stylesheet in many projects.

For now I have a choice to move all repeating styles to base.css which uses variables (or mixins if you like) from another files. But this solution have few disadvantages:
1. I lose nice feature of nesting rules in all files except of base.scss.
2. I have to maintain a lot of variable names as addition to selectors.
3. I can't embed unique styles to base.scss, so I still have some duplicated selectors.
Using buffers does not help as I still have problem 1 and 2.

I'd propose to introduce new command @inherit. This should work similar to @import, but identical selectors should be merged. The order of selectors is taken from inherited stylesheet, and all new selectors are appended to the end of the generated stylesheet. If more than one file is inherited, they are processed in the order they appear.

Ian Hill

You all are speaking about media and buffering, however the issue is about organising partials. I'd propose to move any talks about media and buffering to separated issue, because this is different thing.

@artemrizhov I agree that there's a lot going on in this one issue, and that it might need to be split into dedicated discussion, but I'm not sure if the solutions for organising partials and media query grouping aren't potentially related.

It was hard to know where exactly to post about media query grouping based on searches in the issue list. There are other closed media query grouping tickets that cite this ticket as the one to use, as well as a blog post on The Sass Way referencing it.

merging media queries
#316

Responsive Web Design in Sass: Using Media Queries in Sass 3.2
http://thesassway.com/intermediate/responsive-web-design-in-sass-using-media-queries-in-sass-32

I'm happy to move my input to another place if it makes more sense.

Snugug

@buymeasoda The issue with the way that Less does it is that, by rewriting the selectors in the way that it does, it actually is changing the cascade. This can very quickly lead to unpredictable output. It's for this reason that the @target directive was proposed. It preserves the cascade while allowing us to move specific styles to separate style sheets. As pointed out in my previous comment, for all intents and purposes, grouping media queries in the output CSS is mostly purely a cosmetic issue as performance of non-grouped media queries is really only an issue at unrealistically high number of media queries and only before the cache.

Ian Hill

@Snugug That's definitely a caveat for any regrouping strategy, whether done by a pre-processor or by hand.

If @target or another proposal can provide similar flexibility and simplicity while retaining an exact cascade, that'd be great.

I don't personally consider regrouping strategies as "unpredictable" though - while the cascade will change when grouping media blocks, it's changed in a fixed and pre-defined manner. The rules within each block always retain their authored cascade. There are some more detail on that in the Caveats section of the LESS demo.

I'll take a look at the @target proposal, it sounds like an interesting idea.

Artem Rizhov

it actually is changing the cascade

@Snugug This is discussed a lot here and there, but I don't understand the problem. Actually @extend command is changing the order too. But cascade is not order only. The selector weight rule works very well. And anyway we always can check the resulting code and see how it generates. Some debug comments pointing to the source files will make things even more clear. And reordering does not seem really unpredictable while we know and understand rules.

Artem Rizhov

I've implemented @inherit directive that I proposed above. It works just like @import, but merges identical selectors. (Maybe @merge would be more appropriate name? :) ) So, if you write few files which inherit each other like this:

style.scss

@inherit 'base.scss';
body { color: #0f0; }

base.scss:

body { font: Verdana; }

This will result in style.css:

body { font: Verdana; color: #0f0; }

Any comments and suggestions are welcome.

https://github.com/artemrizhov/sass/commits/feature/inherit

(I never used Ruby before, and my code may be wrong somewhere. So suggestions may be really helpful.)

Artem Rizhov

I just noticed that there are different parsers for sass and scss files, so I implemented the feature for sass files only. Added support for scss files and fixed a bug.

Nathan Weizenbaum
Owner

People seem to be wondering why it's unacceptable to arbitrarily re-order CSS, so here's an example:

@media screen {
  .example1 {color: black}
}

.example2 {color: white}

@media screen {
  .example3 {color: blue}
}
<p class="example1 example2">P1</p>
<p class="example2 example3">P2</p>
<p class="example3 example1">P3</p>

Any re-ordering of the above rules will change the rendering of the HTML snippet. This situation may not be especially likely, but it's possible, and it gets much more likely the larger a body of CSS gets. Users need to be able to rely on Sass never to unexpectedly change the way their pages render because of some seemingly-unrelated change like adding a new media query far off in their stylesheet.

Artem Rizhov

@nex3 I'm agree with you. Re-ordering is unacceptable while it's arbitary. However, in some situations (like I described above) a developer may agree to predictable re-ordering in favour of consolidation of the repeating content in separated files. Even more, you can think about this feature like about a kind of mixin. You don't worry about re-ordering made by mixin, right? Because you don't consider the mixin content like an independent rules. So just think about merged rules like about one more (convenient) way to reuse the code.

The decision to use such consolidation with re-ordering should be made once on the development stage. Thus it should be implemented as a directive, but not an optimisation option. There should not be a way to change the rendering of HTML with a compile-time option. So actually nothing changes the rendering of HTML. The result should be same while we use same directives. If you use @inherit directive, the code will be always merged.

What you think?

I'm starting to use @inherit directive in my project, and probably will report about the result in about a week or two. For now it would be nice to get your opinion regarding to my feature proposition (and also about it's current implementation) and regarding to the arguments for reordering.

Nathan Weizenbaum
Owner

I don't think there's a way to implement @inherit as you describe it with sufficiently consistent behavior. Without a good, easily-comprehensible way of matching the order of rules between multiple files, you end up with behavior indistinguishable from arbitrary re-ordering to most users.

Artem Rizhov

Ok, I understand that you may have own vision. I just want to ask you to make sure I was clean enough.

My current implementation works as follow:
1. Import rules right in place the directive is used.
2. Merge properties into last inherited rule with matching selector, or leave it untouched if no match in the inherited document.
So the base file defines the order of base set of rules, and the child file appends (or prepends) additional rules to the end (begin) of generated file with it's own defined order.

Do you think such behaviour may be considered as non-consistent or hard to comprehend or even indistinguishable from arbitrary re-ordering?

Axel Etcheverry

+100000 for @inherit

Artem Rizhov

Just updated my fork for @inherit with latest changes (the default branch is changed to 'master'). If somebody is using it then please let me know if something is broken in new version.
What about me, I'm using this feature in our project, and it works well for now. Maybe I'll implement removing of duplicated properties later.

Sébastien Maccagnoni-Munch

I suggest using a command-line argument to the sass command, which could be called "--max-compression" or "--combine-and-reorder", to explicitly ask the compression engine to combine and reorder rules - the developer would explicitly set this option, if (s)he doesn't want it (s)he doesn't enable it.

Nathaniel Higgins
Artem Rizhov

I suggest using a command-line argument to the sass command, which could be called "--max-compression" or "--combine-and-reorder"

@tiramiseb , @nathggns Remember that the order is important in CSS (see discussion above). In some cases rules can not be combined and reordered. Sometimes order makes big sense, for example with CSS-based animation and effects. Uncontrolled behaviour makes it hard or even impossible to use such kind of compression in many cases. It will be more flexible if developer is able to specify what exactly should be combined.

Sébastien Maccagnoni-Munch

I know that order in CSS may be important. But some developers work in such a way that order doesn't matter. I'm one of them : I am careful about how rules are defined and I can move any of them in my CSS sources without any negative result.

That's why I'm suggesting an explicit option to enable reordering, which the developer would need to explicitly use if (s)he wants it.

Nathaniel Higgins
Artem Rizhov

@tiramiseb , @nathggns Hey guys, I understand, many people don't use (and even don't know about) cascading in cascading style sheets! But what about me (and other cascading guys)? ))) I see there is an option to NOT USE this feature. But I still need to use it! ))) Let's vote for something that works for anybody, not for you only. ;)

Nathaniel Higgins
Artem Rizhov

@nathggns I've proposed @inherit directive. Another people are talking about using @buffer with @media. Actually, just scroll up and you'll see ;)

Lu Nelson

I want to say a big +1 for the @buffer idea. I think it's an elegant and logical complement to the existing concepts of @extend and @include;

my suggestion—which I think is slightly simpler in the usage—is that @buffer could simply be a new directive that is applied in the place of @include for the case of non-parametric mixins that take a @content block.

In this scenario, @buffer causes the passed content block to be stored rather than immediately output, and later, @include outputs any buffered content to that point, plus new content passed.

It might look something like this:

// set up

@mixin tablet {
    @media only screen and (min-width: 480) {
        @content;
    }
}

// in-line usage: @buffer to hold the passed content

h1 {
    font-size: 24px;
    @buffer tablet {
        font-size: 36px;
    }
}

// @include to output buffered content, followed by any new content passed here

@include tablet {
    .wrapper {
        width: 440px;
    }
}

… with the result:

h1 {
    font-size: 24px;
}

@media only screen and (min-width: 480) {
    h1 {
        font-size: 36px;
    }
    .wrapper {
        width: 440px;
    }
}
sascha fuchs
gisu commented March 31, 2013

For me a +1 too for the Buffer Option. Responsive Webdesign and many "My Client have a new Idea" modifikations would @buffer a big help, to get a streamlined and small CSS.

Chris Eppstein
Collaborator

I intend to spend some serious time thinking about this issue and what I think may be a related one where content from different source locations is meant to be merged together instead of appended.

In particular, I'd like to see how we can expose some very general capabilities that can be turned into useful best practices and patterns in frameworks like compass and breakpoint.

We care deeply about the quality of sass code output but we care equally about making the authoring AND debugging experience as pain-free as possible.

Chris Eppstein
Collaborator

For what I mean by "merging content" see the docs on Archetype: http://www.archetypecss.com/tutorials/extending-core-components/ and how they must circumvent traditional css syntax to accomplish this.

Norbert Sienkiewicz
ozeczek commented May 31, 2013

+1 for @buffer

Najera

+1 for @buffer

Elise Chant

+1 for @media bubbling

Jake Wilson

+1 for the @buffer idea.

Nathaniel Higgins

Shouldn't this have been addressed by now?

Ricky Lee

Love the buffer concept as a workaround but compiler could be smarter. +1

Jannik Zschiesche

A somehow related issue about better compression (or smarter @extend with placeholder selectors)

_inc.scss

%test { color: red; }

_imp#.scss (# = 1, 2, 3)

@import "inc";
.imp# { @extend %test; } // # = 1, 2, 3

main.scss

@import "imp1";
@import "imp2";
@import "imp3";

Which produces

.imp1, .imp2, .imp3 {
  color: red; }

.imp1, .imp2, .imp3 {
  color: red; }

.imp1, .imp2, .imp3 {
  color: red; }

I would have expected that placeholders are added only once, right before the place they are @extended for the first time.
I know, that technically the placeholder is duplicated, but I would have expected it to be unique in the project.

Aaron Jensen

I know, that technically the placeholder is duplicated, but I would have expected it to be unique in the project.

different problem. You're looking for: https://github.com/chriseppstein/compass/tree/master/import-once

Vinay Raghu rvinay88 referenced this issue in zurb/foundation March 24, 2014
Open

Media queries for reveal #4780

maxshearer

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.