Buttons inconsistencies
Problem
While working on Shoreditch I spent some time doing an inventory of the different variations, in terms of markup, of a button in civi (it's not fully comprehensive, for example i left out the "disabled" versions) and it looks to me that there are several inconsistencies that civi would benefit from addressing or at least mitigating
(source: https://gist.github.com/AkA84/9cfcfa610971461493dee1e63c0e06fb)
1. Too many ways of doing the same thing
Right now there are several ways to add a standard civi button to a page, and all of them with caveats:
- Use the
.button
class, but only if you apply it to a<a>
or a[type="button"]
- Use the
.crm-button
class, but it won't work correctly if you apply it to a<a>
- Use the
.crm-form-submit
class, but only if you apply it to ainput[type="button"]
or ainput[type="submit"]
- Use the plain tag without classes, but only if it's
[type="button"]
, as either<button>
or[type="submit"]
will not be styled
Ideally there should be only one class that provides the desired state (say, .crm-button
). Just like it works in Bootstrap (http://getbootstrap.com/docs/3.3/css/#buttons)
2. There are differences to the style in each variation
The differences are mostly about padding, which in turn cause the height to vary
-
a.button
has a padding of2px 6px
, resulting in a height of 23px -
span.button
has a padding of1px
, resulting in a height of 20px -
button.crm-button
has a padding of3px 6px
resulting in a height of 24px -
input[type="button"]
andinput[type="submit"]
have the same padding ofa.button
, but probably because of how they are rendered by the browser they end up with a different height, 19px -
.crm-button input[type=button]
has a padding of3px 5px 2px
, resulting in a height of 22px -
.crm-button .crm-form-submit
has a padding of1px 8px 2px 4px
, resulting in a height of 21px
It gets pretty evident once you line them up
3. Some variations are floated by default
a.button
and span.crm-button
are floated by default to the left, which is pretty confusing. Not sure why this layout decision was hardcoded on these variations, but it prevents one to use them without having to "counter" the floating each time
Solution
I think issue no.2 is the one with the better chances of being fixed without introducing regression issues, as it's just about consolidating the padding and height of all the variations
Issues no.1 and no.3 instead I can imagine that if fixed would likely cause problems downstream. At the very least some documentation of what should be the correct/preferred way to add a button in a civi page should mitigate the confusion and eventually lead to an adoption of a single variation as the "right" one over the others, which over time would become legacy and could eventually be removed
Shoreditch of course should be able to correct most if not all of the above by simply overriding the original css, but I thought worth flagging the problem anyway as it might be worth considering addressing the problems in the original "theme" as well