Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • B bootstrap
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 263
    • Issues 263
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 114
    • Merge requests 114
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Bootstrap
  • bootstrap
  • Merge requests
  • !7809

BS3: Require .btn-default for all standard buttons

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Mark Otto requested to merge bs3_adding_btn_default into 3.0.0-wip May 08, 2013
  • Overview 0
  • Commits 1
  • Pipelines 0
  • Changes 6

Why

The base-modifier class approach we use just about everywhere in Bootstrap works great most of the time, but when doing any level of customization, things start to get hairy real quick. Currently, if you override .btn, you thus override .btn-default and every other modifier class. If you then want to customize .btn-default some more, you have twice the overrides on that single button class.

Impact

The impact of this goes well beyond buttons, but the immediate effects will be seen on every button. The required markup for a button will change to require two classes:

<!-- Current syntax -->
<button type="button" class="btn">Save changes</button>

<!-- Proposed syntax -->
<button type="button" class="btn btn-default">Save changes</button>

This change also applies to standard button groups—any basic button there will require two classes for a regular gray button. This is just like the primary, success, or info buttons we provide.

Improving customization

The big motivator here is improved customization. Here's a look at how you might customize buttons now, and how it could be improved with this proposed change:

/* Current approach */

/* Setting background of all buttons to red overrides .btn-primary because 
   it's the same level of specificity as .btn */
.btn {
  font-family: "Courier New", Courier, monospace;
  background-color: red;
}
/* Which means, we need to override the primary button if we want that to remain blue. */
.btn-primary {
  background-color: blue;
}

/* Proposed approach */

/* Apply common changes to the base class still. */
.btn {
  font-family: "Courier New", Courier, monospace;
}
/* But keep the specific button changes to one class to prevent another round 
   of overrides. Thus, no need to reset the .btn-primary here as it remains unaffected. */
.btn-default {
  background-color: red;
}

Benefits of LESS

While this does complicate the pre-defined classes, those who use these classes as mixins will see little change. For example, if you want to make .save-changes into a button, the required LESS code for that barely changes:

/* Current syntax */
.save-changes {
  .btn();
}

/* Proposed syntax */
.save-changes {
  .btn();
  .btn-default();
}

Looking elsewhere

Beyond the impact of all basic buttons in Bootstrap requiring this extra class, this change will set the course for all other components that use similar approaches with modifier classes. This means the following components will see a slight reworking in the same vein as the buttons here:

  • Labels
  • Alerts (the default alert will likely be white or gray)
  • Progress bars
  • Panels

Open questions and todos

I'm pretty set on this direction, but I'm probably missing a few things and I'm open to adjusting our execution before merging in. Specifically, I have the following to figure out:

  • Does .btn-default make sense, or does another adjective feel more appropriate?
  • Anything missing from or out of date in the docs?

<3

Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: bs3_adding_btn_default