Skip to content

Loading…

Default button background color #169

Closed
scottmontminy opened this Issue · 16 comments

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

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

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
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?

@scottmontminy

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
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 :)

@scottmontminy

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
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 :)

@andykirk

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

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

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

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

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

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

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
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 :)

@stefsullrew

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 csswizardry added a commit that referenced this issue
@csswizardry [refs #169] Add default beautons colour.
Conflicts:
	_defaults.scss
306caf7
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.