Skip to content
This repository was archived by the owner on Nov 9, 2022. It is now read-only.

Entity Button

ebollens edited this page Aug 31, 2012 · 2 revisions

Eric 8/31/12

Support for Multiple Elements

I completely agree with a[class=button], button, and input[class=button]. I'd like to see them implemented so that you can just choose to use one if you so choose though (not hard to do - the preliminary example already in the repo even does this).

Button Types

We should figure out the sentiment-based color scheme - and then use and the marketing names here! I would like to see us stick to the same sentiments across all (like having .warning everywhere rather than .danger in some places and .error in others - tricky question though)

Visual (Non-Semantic) Button Classes

Size might be a necessary evil, but I'm not convinced - context should dictate size, and thus would be part of the sheet, not some additional class defined for the end user (though I wouldn't oppose a mixin that lets someone scale a button they're defining in SASS).

Style-less Button

I don't see a point: just use an a tag without the button class.

Logan 8/31/12

Support for Multiple Elements

Elements a[class=button], button, and input[class=button] should all be supported.

Button Types

Twitter Bootstrap includes the following types for buttons (http://twitter.github.com/bootstrap/base-css.html#buttons):

  • Default (White)
  • Primary (Blue)
  • Info (Light Blue)
  • Success (Green)
  • Warning (Orange)
  • Danger (Red)
  • Inverse (Black)
  • Link (see discussion below)

Foundation includes the following types (http://foundation.zurb.com/docs/buttons.php):

  • Default (Blue)
  • Secondary (White)
  • Success (Green)
  • Alert (Red)

I believe that, in Foundation, these "button types" are actually CSS state/utility classes that are used throughout the framework. I'm not sure if we want to consider this approach, although there is a danger in trying to combine the language used to describe type and state. For example, Bootstrap uses .danger for red buttons ("red" could change of course), but .error for red alerts, which makes sense, while Foundation uses .alert for both.

"Disabled" State

Support should be included for both input[disabled] and .disabled.

Visual (Non-Semantic) Button Classes

Twitter Bootstrap includes a number of non-semantic, visually-focused CSS classes for buttons:

  • .btn-large
  • .btn-small
  • .btn-mini
  • .btn-block

Foundation does the same:

  • .tiny
  • .small
  • .medium
  • .large
  • .radius (Slight border radius)
  • .round (Hardcore border radius)

I think the size utility classes may be a necessary evil. I don't think .radius or .round should be included; we should create a slightly rounded look and feel for the buttons that fits the framework. I can't tell if .btn-block is also a necessary evil?

Style-less Button

So I think this is new; Bootstrap has a class for stripping all of the styling from a button so that it looks like a link (.btn-link: http://twitter.github.com/bootstrap/base-css.html#buttons), but the element still has all of the Bootstrap button features (I'm not sure to what extent).

I would almost like to avoid adding this into the framework unless we see the definite need as it feels like a bit of an oddball button type.

Clone this wiki locally