Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • C CiviCRM Core
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,374
    • Issues 1,374
    • List
    • Boards
    • Service Desk
    • Milestones
  • Deployments
    • Deployments
    • Releases
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • Development
  • CiviCRM Core
  • Issues
  • #347

Closed
Open
Created Aug 20, 2018 by AkA84@AkA84

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

buttons

(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 heights

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

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking