Styling input controls globally interferes with other plug-ins - more granular selectors needed

[rhollhumer]

This ticket was closed before but needs to be re-opened as I feel it is a reasonable request. It is not acceptable to suggest "Third party plugin support is never guaranteed.". It is good practice to enforce css classes and selectors to be specific to the framework, constantly being aware of possible impacts outside of the framework. Just as namespaces are essential to JavaScript programming and being careful about the use of global variables, regardless of what framework, for example jQuery has addressed that appropriately, BS also needs to be cognizant of outside ramifications. I simply cannot accept that the code below cannot be expressed more granularly and to expect us (the users of BS) to customize the css to address this is not the correct approach. You wouldn't specify HTML properties for example that would adversely affect regular html pages would you or enforce weird styling on the body tag, since it is used by all, why then not consider addressing the generic styling you place on input tags?

Here is the code again where the styling is too generic and needs to be more granular in prefixing the selector with "controls'.

textarea, input[type="text"], input[type="password"], input[type="datetime"], input[type="datetime-local"], input[type="date"], input[type="month"], input[type="time"], input[type="week"], input[type="number"], input[type="email"], input[type="url"], input[type="search"], input[type="tel"], input[type="color"], .uneditable-input {
-moz-transition: border 0.2s linear 0s, box-shadow 0.2s linear 0s;
background-color: #FFFFFF;
border: 1px solid #CCCCCC;
border-radius: 3px 3px 3px 3px;
box-shadow: 0 1px 1px rgba(0, 0, 0, 0.075) inset;
}

select, textarea, input[type="text"], input[type="password"], input[type="datetime"], input[type="datetime-local"], input[type="date"], input[type="month"], input[type="time"], input[type="week"], input[type="number"], input[type="email"], input[type="url"], input[type="search"], input[type="tel"], input[type="color"], .uneditable-input {
color: #555555;
display: inline-block;
font-size: 13px;
height: 18px;
line-height: 18px;
margin-bottom: 9px;
padding: 4px;
}

[mdo]

A handful of similar issues have come up in the past about different components being too generic and interfering with other tools, plugins, and what not. In some cases, it's easy to solve that—nearly all of our composite components have (somewhat) unique classes (.navbar, .btn-group, etc). For the most basic of HTML elements, we've opted to not be overly specific.

The extreme of being specific for everything is requiring a class for every single element—.h1 instead of h1—but that isn't practical or the right thing to do. If that extreme isn't right, and the complete opposite isn't—because how could we style all our components with generic HTML elements and no classes?—then we have to stop somewhere in the middle.

Similarly, at what point do we stop catering to others instead of doing what is right for most folks just trying to bootstrap their projects? Can you imagine creating having to maintain a project that has nuances for dozens, potentially hundreds, other tools? Again, it's impractical and just doesn't scale.

These selectors are already more specific than they were with 2.0.3 where we were styling all input elements, then overriding by type. It added more overhead, create oddities in different browsers and mobile phones, and just became a pain to maintain. This method is, to us, the easiest way to provide the most bang for your buck without overly complicating forms (which by the way are already a paint point for users).

Given all that, what would you propose we change? Create a class for each type of form control and ask developers to implement that in addition to the element and type? That doesn't seem like the right choice either, but I'm open to hearing anything else. I always want to simplify things, but not at the cost of adding unintended complication.

[mdo]

@rhollhumer Since we can't change much here without breaking backward compatibility, I'm going to close this out. Feel free to email me or mention me if you have additional thoughts.