Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate unique indentifiers during a compilation run #771

Closed
chriseppstein opened this Issue May 27, 2013 · 8 comments

Comments

Projects
None yet
2 participants
@chriseppstein
Copy link
Member

chriseppstein commented May 27, 2013

An issue comment raised an interesting use case for creating unique identifiers. Without objection, I'll add a helper function to do this.

Note: the implementation for the unique number generation will be better than can be found in my gist in the comment thread. I intend to use ruby's Fixnum#succ method so that unique generation is fast, but I will start with a different number each time so that people don't try to depend on quasi-predictable output.

@nex3

This comment has been minimized.

Copy link
Contributor

nex3 commented May 31, 2013

I'm not sure I completely understand the use case for this. If you're generating a unique identifier just to extend it locally, why not just add the properties manually?

@chriseppstein

This comment has been minimized.

Copy link
Member Author

chriseppstein commented May 31, 2013

why not just add the properties manually?

I assume you mean "Why not just rewrite the base selector manually". The benefits of @extend are just as realizable in a local context as they are in a more global context. Manual selector rewriting is an inversion of control that is also difficult to express correctly in pure sass. What's more, this enables strategies like so:

$current-module: null;
$current-module-base: null;

@mixin module($name) {
  $old-module: $current-module;
  $old-module-base: $current-module-base;
  $current-module: $name;
  $current-module-base: unique-id();
  %#{$current-module-base} {
     stuff: here;
   }
  @content;
  $current-module: $old-module;
  $current-module-base: $old-module-base;
}

@include module(foo) {
  #whatever { @extend #{$current-module-base} }
}

Note: the above code would really clean up if we could pass arguments to the content block from the mixin.

@nex3

This comment has been minimized.

Copy link
Contributor

nex3 commented May 31, 2013

That example seems like you could just set $current-module-base to module-#{$name} or something similar. I'm also not sure what the purpose of the styles in %#{$current-module-base} is.

I really want to see a concrete example of the utility of this function.

@chriseppstein

This comment has been minimized.

@nex3

This comment has been minimized.

Copy link
Contributor

nex3 commented May 31, 2013

I don't understand why banner-bg isn't written like

@mixin banner-bg($height, $bgColor, $opacity: null, $extends: null) {
    @extend %bannerbg;

    &, &:before {
        height: $height;
        background-color: $bgColor;
        @if $extends != null {@extend #{$extends}}
    }

    &:before{
        @if $opacity != null {@include opacity($opacity)} 
        content: "";
        position: absolute; 
        right: 0;
        left: 0;
        z-index: -100;
    }
}
@chriseppstein

This comment has been minimized.

Copy link
Member Author

chriseppstein commented May 31, 2013

Because media queries.

@nex3

This comment has been minimized.

Copy link
Contributor

nex3 commented May 31, 2013

It looks like %bannerbg will prevent both versions of this mixin from working across media boundaries.

@chriseppstein

This comment has been minimized.

Copy link
Member Author

chriseppstein commented Jun 3, 2013

Closed by f3be0f4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.