Default button background color #169

Closed
scottmontminy opened this Issue Mar 13, 2013 · 16 comments

Comments

Projects
None yet
5 participants
@scottmontminy

It looks like the current release is missing the default blue background-color on the base .btn class in _beauton.scss. Not a biggie, but noticed the .btn--positive and .btn--negative classes do have background color so I'm assuming the .btn class is intended to have a background color too (the blue color).

@kevva

This comment has been minimized.

Show comment
Hide comment
@kevva

kevva Mar 13, 2013

Contributor

It's intentional, I believe. The .btn class is only structural, meaning that any modifiers (colors, sizes, etc.) should be defined like this for example .btn--primary { color: blue; }. By doing this we are making things more reusable.

Contributor

kevva commented Mar 13, 2013

It's intentional, I believe. The .btn class is only structural, meaning that any modifiers (colors, sizes, etc.) should be defined like this for example .btn--primary { color: blue; }. By doing this we are making things more reusable.

@scottmontminy

This comment has been minimized.

Show comment
Hide comment
@scottmontminy

scottmontminy Mar 13, 2013

Ah, that make sense. Thank you.

I was partially going off of the beautons repo, but using .btn--primary does provide more flexibility. Thanks again.

Ah, that make sense. Thank you.

I was partially going off of the beautons repo, but using .btn--primary does provide more flexibility. Thanks again.

@csswizardry

This comment has been minimized.

Show comment
Hide comment
@csswizardry

csswizardry Mar 13, 2013

Owner

Yeah, the current implementation is a bit of a half-way between beautons and inuit.css style build… I could add a default color to https://github.com/csswizardry/inuit.css/blob/fix/beautons/_defaults.scss#L135-L143 if you like?

Owner

csswizardry commented Mar 13, 2013

Yeah, the current implementation is a bit of a half-way between beautons and inuit.css style build… I could add a default color to https://github.com/csswizardry/inuit.css/blob/fix/beautons/_defaults.scss#L135-L143 if you like?

@scottmontminy

This comment has been minimized.

Show comment
Hide comment
@scottmontminy

scottmontminy Mar 13, 2013

I think the solution to have default colors makes a lot of sense. That would be great and thanks for the quick feedback.

Perhaps the default colors could be made to be more flexible than just for use with the beautons. For example, I could see using the default colors for other elements like alert notifications (e.g. info-only, warning, success, error), errors on forms, maybe even for inline highlights/pills.

For example:
Instead of $beautons-positive, perhaps $color-positive?
Then the .btn--positive class would default to background-color: $color-positive;

I think the solution to have default colors makes a lot of sense. That would be great and thanks for the quick feedback.

Perhaps the default colors could be made to be more flexible than just for use with the beautons. For example, I could see using the default colors for other elements like alert notifications (e.g. info-only, warning, success, error), errors on forms, maybe even for inline highlights/pills.

For example:
Instead of $beautons-positive, perhaps $color-positive?
Then the .btn--positive class would default to background-color: $color-positive;

@csswizardry

This comment has been minimized.

Show comment
Hide comment
@csswizardry

csswizardry Mar 13, 2013

Owner

About that…

That would take inuit.css a lot further into the design realm than I’d like to take it. beautons, as it is a different micro-lib altogether, need those colours, but nothing else in inuit.css does.

You can always set your variables in the web template’s _vars.scss though, which can be picked up later in your project :)

Owner

csswizardry commented Mar 13, 2013

About that…

That would take inuit.css a lot further into the design realm than I’d like to take it. beautons, as it is a different micro-lib altogether, need those colours, but nothing else in inuit.css does.

You can always set your variables in the web template’s _vars.scss though, which can be picked up later in your project :)

@scottmontminy

This comment has been minimized.

Show comment
Hide comment
@scottmontminy

scottmontminy Mar 13, 2013

I thought you might say that. =)

The reason I like inuit.css as a designer/developer is because you don't make any design assumptions, so no argument from me on keeping those more generic color variables out.

Thanks for taking the time to address this thread.

I thought you might say that. =)

The reason I like inuit.css as a designer/developer is because you don't make any design assumptions, so no argument from me on keeping those more generic color variables out.

Thanks for taking the time to address this thread.

@csswizardry

This comment has been minimized.

Show comment
Hide comment
@csswizardry

csswizardry Mar 13, 2013

Owner

Yeah, beautons is almost a step too far IMO, but I will leave the variables in and configurable. Like I say though, the inuit.css web template has a place for all your custom variables :)

Thanks for taking the time to address this thread.

Don’t mention it :)

Owner

csswizardry commented Mar 13, 2013

Yeah, beautons is almost a step too far IMO, but I will leave the variables in and configurable. Like I say though, the inuit.css web template has a place for all your custom variables :)

Thanks for taking the time to address this thread.

Don’t mention it :)

@andykirk

This comment has been minimized.

Show comment
Hide comment
@andykirk

andykirk Mar 13, 2013

Hi, just to chip in here, I also agree that inuit's greatest strength is it's 'design-free' approach.

However, there are a few things that are design related, and it's my opinion that all of these things should be set using variables, rather than needing to override them. The table--striped colour is one example.

More discussion: #94.

I'd be happy to go through inuit and find all these cases. Perhaps 'fix' them in a branch and create a PR? At least so you can take a look?
What do you think?

Cheers

Hi, just to chip in here, I also agree that inuit's greatest strength is it's 'design-free' approach.

However, there are a few things that are design related, and it's my opinion that all of these things should be set using variables, rather than needing to override them. The table--striped colour is one example.

More discussion: #94.

I'd be happy to go through inuit and find all these cases. Perhaps 'fix' them in a branch and create a PR? At least so you can take a look?
What do you think?

Cheers

@kevva

This comment has been minimized.

Show comment
Hide comment
@kevva

kevva Mar 13, 2013

Contributor

I think we should keep the number of variables as low as possible. It's not worth creating a variable if these design related things only occur in a few places.

Contributor

kevva commented Mar 13, 2013

I think we should keep the number of variables as low as possible. It's not worth creating a variable if these design related things only occur in a few places.

@andykirk

This comment has been minimized.

Show comment
Hide comment
@andykirk

andykirk Mar 13, 2013

Hi,

It's not worth creating a variable if these design related things only occur in a few places.

– I'd be interested to know why you think that. Is there any particular reason?
Since inuit now has a defaults file, it doesn't seem to me to be a lot more work.

I think we should keep the number of variables as low as possible

– Again, curious to know the reasoning behind this.

Cheers

Hi,

It's not worth creating a variable if these design related things only occur in a few places.

– I'd be interested to know why you think that. Is there any particular reason?
Since inuit now has a defaults file, it doesn't seem to me to be a lot more work.

I think we should keep the number of variables as low as possible

– Again, curious to know the reasoning behind this.

Cheers

@kevva

This comment has been minimized.

Show comment
Hide comment
@kevva

kevva Mar 13, 2013

Contributor

Well, it's unnecessary bloat imo. It's a slippery slope to begin adding variables for everything. I think that the user can override small things like a background-color in a few places. They're likely to do it anyway.

The purpose of the framework is to separate the theme from the structure so I don't see why we would begin adding more theme variables in, especially not for small things like this.

Contributor

kevva commented Mar 13, 2013

Well, it's unnecessary bloat imo. It's a slippery slope to begin adding variables for everything. I think that the user can override small things like a background-color in a few places. They're likely to do it anyway.

The purpose of the framework is to separate the theme from the structure so I don't see why we would begin adding more theme variables in, especially not for small things like this.

@andykirk

This comment has been minimized.

Show comment
Hide comment
@andykirk

andykirk Mar 13, 2013

Hmm. IMO, that's just shifting the bloat on to the end users code.

Take this:

.table--striped{
  tbody tr:nth-of-type(odd){
    background-color:#ffc; /* Override this color in your theme stylesheet */
  }
}

You'd have to repeat that whole thing in your styles.scss, whereas you easily could have:

.table--striped{
  tbody tr:nth-of-type(odd){
    background-color:$table-stripe-colour;
  }
}

and in the defaults have $table-stripe-colour:#ffc.

Then if you want to override this, you can just change the variable in your _vars.scss.
To me, that's less bloat overall :-)

Hmm. IMO, that's just shifting the bloat on to the end users code.

Take this:

.table--striped{
  tbody tr:nth-of-type(odd){
    background-color:#ffc; /* Override this color in your theme stylesheet */
  }
}

You'd have to repeat that whole thing in your styles.scss, whereas you easily could have:

.table--striped{
  tbody tr:nth-of-type(odd){
    background-color:$table-stripe-colour;
  }
}

and in the defaults have $table-stripe-colour:#ffc.

Then if you want to override this, you can just change the variable in your _vars.scss.
To me, that's less bloat overall :-)

@kevva

This comment has been minimized.

Show comment
Hide comment
@kevva

kevva Mar 13, 2013

Contributor

Yeah, well, it's a preference. If there were five other places where #ffc existed we could name it to something like $base-accent-color or something but I doubt there are.

Contributor

kevva commented Mar 13, 2013

Yeah, well, it's a preference. If there were five other places where #ffc existed we could name it to something like $base-accent-color or something but I doubt there are.

@andykirk

This comment has been minimized.

Show comment
Hide comment
@andykirk

andykirk Mar 13, 2013

It's a preference sure.

$base-accent-color is a good name :-)

Don't forget the end user may want to use $base-accent-color multiple times in their own styles, even if it doesn't appear multiple times in the framework, and it'd already be there.

It's a preference sure.

$base-accent-color is a good name :-)

Don't forget the end user may want to use $base-accent-color multiple times in their own styles, even if it doesn't appear multiple times in the framework, and it'd already be there.

@csswizardry

This comment has been minimized.

Show comment
Hide comment
@csswizardry

csswizardry Mar 13, 2013

Owner

This is all stuff worth thinking about, but I’m with @kevva at the moment; inuit.css tries to do as little design as possible, so adding in (potentially) dozens of style-related variables sets a precedence that may lead other things to follow…

If #ffc was used loads then yeah, I’m with you, but making a variable visible to a user up front for just one small usage seems to be a little far… Thanks for the discussion, though :)

Owner

csswizardry commented Mar 13, 2013

This is all stuff worth thinking about, but I’m with @kevva at the moment; inuit.css tries to do as little design as possible, so adding in (potentially) dozens of style-related variables sets a precedence that may lead other things to follow…

If #ffc was used loads then yeah, I’m with you, but making a variable visible to a user up front for just one small usage seems to be a little far… Thanks for the discussion, though :)

@stefsullrew

This comment has been minimized.

Show comment
Hide comment
@stefsullrew

stefsullrew Mar 16, 2013

While I also love the fact that little to no design is included in inuit, I would really like to see the base btn--postive and btn--negative colors use a variable instead of a hard-coded color.

I have very specific green/red from my designer that is repeated in a variety of places (alerts, form validation, etc). I have already created a variable for this locally, but it seems like defining your own red/green variable (or whatever color your positive/negative indicators are) would be logica to create in the framework.

It doesn't seem like bloat since it's a very common design option.

While I also love the fact that little to no design is included in inuit, I would really like to see the base btn--postive and btn--negative colors use a variable instead of a hard-coded color.

I have very specific green/red from my designer that is repeated in a variety of places (alerts, form validation, etc). I have already created a variable for this locally, but it seems like defining your own red/green variable (or whatever color your positive/negative indicators are) would be logica to create in the framework.

It doesn't seem like bloat since it's a very common design option.

csswizardry added a commit that referenced this issue Mar 19, 2013

[refs #169] Add default beautons colour.
Conflicts:
	_defaults.scss
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment