Buttons: Initial pass at buttons, covering sizes, options, disabled, active, focus, and hover states

[sfrisk]

This is my first initial pass at buttons. It this is the direction people want to go with for buttons, I can add a few more options for buttons (colors, button group, block button etc).

[cvrebert]

Why so much @extending? It's arguably an antipattern.

[sfrisk]

@cvrebert As I think about it, mixins would probably have be better solution, especially if we want to add additional options. I can easily switch to using mixins instead. Part of this issue was also to test the BEM naming convention (since we haven't had any commits with that yet), and get an idea if visually this was the type of button we wanted to go with. I'll update the PR (although probably not tonight) with a mixin version.

[sfrisk]

Or you know, maybe just make things mixins tonight, since I can't sleep. Let me know what you think, and if you approach works.

[cvrebert]

Have you considered:

• Block-level buttons
• A class to make a <button> look like a normal <a>
• Additional classes to emulate the appearance of :active, :focus, :hover

[sfrisk]

Block-level buttons were actually next on my list of things to add.
Making a button look like a link is a good one, I will add it to the list. Same with classes for active/hover/focus.

Sent from my iPhone

On Jul 17, 2015, at 1:47 AM, Chris Rebert notifications@github.com wrote:

Have you considered:

Block-level buttons A class to make a look like a normal Additional classes to emulate the appearance of :active, :focus, :hover` — Reply to this email directly or view it on GitHub.

Consider implementing https://github.com/twbs/bootstrap/pull/15947 as well

[cvrebert]

Also, what about combinations of multiple states? (Example: https://github.com/twbs/bootstrap/issues/16767)

[sfrisk]

@cvrebert Ooo, I hadn't thought of that one. Might need to tweak how disabled styling currently works to make that work.

[sfrisk]

Also @geekman-rohit pointed out that the primary button contrast don't actually pass accessibility contrast checking. I used colors suggested for use with the Chassis Logo, but if anyone has any alternative color suggestions that are accessible, I would love to hear them.

[geekman-rohit]

Basically we want the background - foreground colors to have more contrast so they are easier to read to all people. We also need to see what tests it should pass? I think the primary button should pass AAA while it should be okay for disabled buttons to be AA or even A http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html

[arschmitz]

there are automated tools we can use with grunt for this sort of checking its been on my todo for a while to set them up

[sfrisk]

I'll add an issue for Accessibility Checking

[sfrisk]

This was brought up in the meeting today, but should we have the default button be a "block" button, since we'll be designing this mobile first, with an optional modifier to have an inline button? Or the other way around?

[geekman-rohit]

I think it should be inline with a modifier to make it block.

[sfrisk]

@geekman-rohit added some different types of buttons to test the performance stuff you're working on

[sfrisk]

Closing this in favor of #138, which is our new approach on this.