:root {
  --primary-font-color: #404040;
  --primary-font-face: 'Open Sans', sans-serif;
  --primary-font-size: 19px;

  --primary-color: #1fb29d;
  --primary-color-bright: #e1f3f1;
  --dialog-bgcolor: #fff;
  --cancel-color: #888;

  --text-input-bgcolor: #fff;
  --text-input-border-color: #ccc;
  --text-input-border: 1px solid var(--text-input-border-color);
  --text-input-border-radius: 4px;
  --text-input-focus-ring-color: #4a90d9;
  --disabled-input-background-color: #eeeeed;

  --highlighted-item-color: #b4d6ce;

  font-size: var(--primary-font-size);
}

body {
  margin: 0px;
  background: #eeeeed;
  color: var(--primary-font-color);
  font-family: var(--primary-font-face);
  display: flex;
  flex-direction: column;
  height: 100vh;
}

/* When switching back and forth between two "overflow-y: auto" pages that
   both contain the same centered top menu and one of the pages has more content
   that can fit in a single screenful while the other doesn't; then the
   appearing/disappearing of the scrollbar will cause the page content (and the
   centered top menu) to move back and forth ~16px (the width of the scrollbar)
   horizontally on navigation. Doing "overflow-y: scroll" is a bit ugly, and
   doing body { margin-left: calc(100vw - 100%); margin-right: 0; } only works
   if the scroll container is body. In our case, the scroll container is
   "react-root" instead (see comment on bottom-bar) because that's the element
   that has the "overflow: auto" property. For this reason, a third approach is
   used to eliminate the horizontal jank:

   https://stackoverflow.com/questions/18548465/prevent-scroll-bar-from-adding-up-to-the-width-of-page-on-chrome/49717276#49717276
   This page also lists various hacks to deal with the above problem:
   https://stackoverflow.com/questions/45524214/how-do-i-stop-my-web-content-from-shifting-left-when-the-vertical-scrollbar-appe
 */
#react-root-container {
  overflow: auto;
  flex: 1 1 auto;
  width: 100vw;
}

#react-root {
  width: inherit;
  max-width: 100%;
}

/* If the bottom-bar is implemented using a absolute positioned element, then
   the virtual keyboard on many mobile browsers will render above the
   bottom-bar. Because the bottom-bar contains a save button, it's important
   that the user doesn't accidentally miss it i.e. it's a pretty serious issue
   if it ends up rendering behind the virtual keyboard.
*/
#bottom-bar {
  flex: 0 0 auto;
}

/* The "focus-visible" CSS below renders a standard focus outline when TAB is
   used to move focus between widgets, but doesn't render the focus outline when
   the mouse is used to click a button etc. Because :focus-visible is not
   supported in browsers yet, a polyfill is used: https://github.com/WICG/focus-visible
*/
/* Regarding stylelint-disable below, see: https://github.com/stylelint/stylelint/issues/3886 */
/* stylelint-disable */
:focus:not(:focus-visible) {
  outline: none;
}
.js-focus-visible :focus:not(.focus-visible) {
  outline: none;
}
/* stylelint-enable */