GitLab

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:

1. Use the .button class, but only if you apply it to a <a> or a [type="button"]
2. Use the .crm-button class, but it won't work correctly if you apply it to a <a>
3. Use the .crm-form-submit class, but only if you apply it to a input[type="button"] or a input[type="submit"]
4. 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

1. a.button has a padding of 2px 6px, resulting in a height of 23px
2. span.button has a padding of 1px, resulting in a height of 20px
3. button.crm-button has a padding of 3px 6px resulting in a height of 24px
4. input[type="button"] and input[type="submit"] have the same padding of a.button, but probably because of how they are rendered by the browser they end up with a different height, 19px
5. .crm-button input[type=button] has a padding of 3px 5px 2px, resulting in a height of 22px
6. .crm-button .crm-form-submit has a padding of 1px 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