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

defaults that allow easy user override. #7

Closed
scottkellum opened this issue Aug 19, 2011 · 5 comments
Closed

defaults that allow easy user override. #7

scottkellum opened this issue Aug 19, 2011 · 5 comments

Comments

@scottkellum
Copy link
Member

It is more important to allow the user to set the defaults, but I understand the importance of defaults being baked in. The nature of the cascade makes this hard to do as a standalone file.

@codingdesigner
Copy link
Contributor

Ahh, just did some testing on this. You can set default values before defining the function or mixin like we had before, but the problem you found was an error in the example sass file. The were setting new !default values, but were being ignored. The solution is to just set a new value to the variable. Like so:

_modular-scale.sass

$ratio: $golden !default
$base-size: 12px !default
$property: font-size !default
$class-slug: ms !default

// Modular Scale function
@function modular-scale($multiple, $base-size, $ratio)

example.sass

.foo
  width: modular-scale(2)
// $base-size value is 12px

$base-size: 14px

.bar
  width: modular-scale(2)
// $base-size value is 14px

$base-size: 16px !default

.baz
  width: modular-scale(2)
// $base-size value is 14px

This solves the problem. I'll push the code for this today.

@codingdesigner
Copy link
Contributor

pushed some code:

  • add default values back. fix the redeclared defaults in the test sass file
  • organize the example sass file
  • removing the duplicate test html and css. Went with the server version because I find it useful, and because that's the way the config.rb file was set up

@scottkellum
Copy link
Member Author

nice, why use .html.erb though?

@codingdesigner
Copy link
Contributor

mostly because it was working with Serve. I think its moderately helpful while developing. not a dealbreaker for me if you feel like simplifying that tho.

@scottkellum
Copy link
Member Author

ah, that makes sense. We can leave it as-is for now but in the long run I would like everything as bare-bones simple as possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants