/*
 * Application styles — Tailwind CDN handles utility classes.
 * Add custom component styles below.
 */

/* flatpickr's own stylesheets used to be two @import url(/...) calls to
   cdn.jsdelivr.net from here. They are now served from this app, alongside the
   vendored JS — see vendor/javascript/flatpickr.js. Two blocking CDN requests
   for a form control's appearance is the wrong dependency for an app used in
   basements, and a stylesheet that fails to load leaves the picker unstyled
   rather than merely unthemed. Linked from the layout (application.html.erb)
   rather than @imported, so Sprockets fingerprints them like every other asset.
   flatpickr.css and flatpickr_dark.css are vendor files: do not hand-edit them.
   App-level overrides belong below, where they always have. */

/* Flatpickr theme overrides to match app design */
[data-theme="dark"] .flatpickr-calendar {
  background: #1e293b;
  border-color: #334155;
  box-shadow: 0 4px 24px rgba(0,0,0,0.4);
}
[data-theme="dark"] .flatpickr-day {
  color: #e2e8f0;
}
[data-theme="dark"] .flatpickr-day:hover,
[data-theme="dark"] .flatpickr-day:focus {
  background: #334155;
  border-color: #334155;
}
[data-theme="dark"] .flatpickr-day.selected,
[data-theme="dark"] .flatpickr-day.selected:hover {
  background: #15803d;
  border-color: #15803d;
}
[data-theme="dark"] .flatpickr-months .flatpickr-month,
[data-theme="dark"] .flatpickr-weekdays,
[data-theme="dark"] span.flatpickr-weekday {
  background: #1e293b;
  color: #94a3b8;
}
[data-theme="dark"] .flatpickr-current-month input.cur-year,
[data-theme="dark"] .flatpickr-current-month .flatpickr-monthDropdown-months {
  color: #e2e8f0;
}
[data-theme="dark"] .flatpickr-time input {
  background: #1e293b;
  color: #e2e8f0;
}
[data-theme="dark"] .flatpickr-time .flatpickr-time-separator,
[data-theme="dark"] .flatpickr-time .flatpickr-am-pm {
  color: #94a3b8;
}
/* Alt input (display input) should match app input style.

   review cycle 2026-07-27: this rule set border-COLOR only. With no
   border-style, CSS renders no border at all, so the Scheduled Date field on
   the project form looked borderless next to every sibling. The border those
   siblings show comes from an inline `border: 1px solid var(--input-border)`
   in the markup, and flatpickr copies the original input's className to the
   input it substitutes but NOT its inline style -- date_picker_controller.js
   patches that back for `altInput`, but on a phone flatpickr shows a separate
   `mobileInput` instead, which the controller never touches. Hence width and
   padding looked right (classes copied) while the border vanished.

   Set the full shorthand, not just the colour. text-align guards the other
   half of the report: iOS renders a native <input type="date"> with its value
   centred, which made the field the only left-misaligned control on the form. */
.flatpickr-input.flatpickr-mobile,
input.flatpickr-input[readonly] {
  background-color: var(--input-bg) !important;
  border: 1px solid var(--input-border) !important;
  color: var(--text) !important;
  text-align: left !important;
}

/* Audit items 2 and 4 (Ben, production 2026-08-13): the Scheduled Date field
   was STILL centred, and ran off the right edge of the phone, despite the
   text-align above. That rule is one box too high. iOS Safari does not render
   a date input's value in the input itself -- it renders it inside the
   ::-webkit-date-and-time-value pseudo-element, which ignores the input's
   text-align and carries its own margin, and whose intrinsic width is what the
   input sizes itself to. So `width: 100%` from the `w-full` class loses to a
   wider min-content, and the value stays centred inside it.

   Targeted at input[type="date"] rather than at .flatpickr-mobile on purpose:
   the bug belongs to the native control, so the rule follows the native
   control. flatpickr hands the field to it on any phone (date_picker_controller
   sets no disableMobile), and a page where flatpickr has not run at all keeps a
   plain native input carrying no flatpickr class to match on.

   (When this was written flatpickr also came from a CDN, so a phone that could
   not reach jsdelivr was a third route to the same bare input. It is vendored
   as of 2026-08-14 and that route is closed -- the rule is still correct, for
   the two reasons above.) */
input[type="date"],
input[type="time"],
input[type="datetime-local"] {
  min-width: 0;
  max-width: 100%;
}

input[type="date"]::-webkit-date-and-time-value,
input[type="time"]::-webkit-date-and-time-value,
input[type="datetime-local"]::-webkit-date-and-time-value {
  text-align: left;
  margin: 0;
}

/* design-review 2026-07-21: the time picker's numeric up/down spinners were
   too small to reliably tap on a real mobile device. CSS-only enlargement --
   time_picker_controller.js keeps disableMobile:true unchanged (that flag
   exists for a real dark-mode legibility bug on native <input type=time>,
   not something to revisit here). Applies in both themes; this is a sizing
   fix, not a color one. */
.flatpickr-time .numInputWrapper {
  width: 3em;
}
.flatpickr-time input.numInput {
  font-size: 22px;
  font-weight: 700;
  padding: 10px 0;
}
.flatpickr-time .numInputWrapper span.arrowUp,
.flatpickr-time .numInputWrapper span.arrowDown {
  height: 30%;
  right: 3px;
}
.flatpickr-time .numInputWrapper span.arrowUp:after,
.flatpickr-time .numInputWrapper span.arrowDown:after {
  border-width: 7px;
}
.flatpickr-time .flatpickr-am-pm {
  font-size: 16px;
  padding: 10px 8px;
}

/* Google Places Autocomplete dropdown (address_autocomplete_controller.js,
   city_autocomplete_controller.js) ships with Google's own light-only
   default styling and injects its .pac-container as a direct child of
   <body>, so it needs its own dark-theme override here rather than through
   the app's normal Tailwind/ERB styling. */
[data-theme="dark"] .pac-container {
  background-color: var(--card-bg);
  border: 1px solid var(--border);
  box-shadow: 0 4px 24px rgba(0,0,0,0.4);
}
[data-theme="dark"] .pac-item {
  background-color: var(--card-bg);
  color: var(--text);
  border-top-color: var(--border);
}
[data-theme="dark"] .pac-item:hover,
[data-theme="dark"] .pac-item-selected {
  background-color: var(--input-bg);
}
[data-theme="dark"] .pac-item-query {
  color: var(--text);
}
[data-theme="dark"] .pac-matched {
  color: var(--badge-green-text);
}
[data-theme="dark"] .pac-icon {
  filter: invert(1) grayscale(1) brightness(1.8);
}

/* iOS Safari auto-zooms the whole page on focus of any text input/select/
   textarea rendered below 16px (many of ours use Tailwind's text-sm, 14px),
   and the zoomed-in state can persist after the field blurs. Force 16px on
   mobile only so it never triggers, without touching maximum-scale (which
   would disable legitimate pinch-zoom for everyone). */
@media (max-width: 640px) {
  input, select, textarea {
    font-size: 16px !important;
  }
}

/* Brief highlight when a clip's "N point sources" label scrolls you to the
   rows that clip produced (point_source_link_controller.js). Uses the badge
   green pair so it reads as "these are the ones" in both themes, and respects
   reduced-motion by simply not animating -- the scroll still happens. */
.point-source-flash {
  animation: point-source-flash 1.6s ease-out;
  border-radius: 6px;
}
@keyframes point-source-flash {
  0%, 35% { background-color: var(--badge-green-bg); }
  100%    { background-color: transparent; }
}
@media (prefers-reduced-motion: reduce) {
  .point-source-flash { animation: none; }
}

/* Audit item 8: Kaito must not sit on top of a form being filled in. The
   widget hides itself while any text-entry field has focus (see
   kaito_controller.js). !important because render() resets the element's
   inline display on every status poll, which would otherwise un-hide it
   mid-typing. */
.kaito-suppressed {
  display: none !important;
}

/* The room page's load indicator (TODO item 24, spec
   docs/superpowers/specs/2026-08-20-room-page-load-indicator-design.md).

   Turbo Drive already injects `.turbo-progress-bar` on any visit slower than
   its delay -- the work here is styling and timing, not building. Default is a
   blue 3px bar; this makes it the amber the sync bar's progress track already
   uses, because that colour means "in progress, not finished" in this app and a
   page load is the same kind of thing.

   It stays INDETERMINATE. Turbo animates toward ~90% and waits, since a browser
   cannot know how many bytes are left; the sync bar's amber is determinate and
   means "3 of 7", a real count. The two share a colour and a position but not a
   truthfulness -- consistent where they can be, honest where they cannot.

   `!important` on the background: Turbo writes its own `background-color`
   into the element's inline style when it creates the bar, and an inline
   declaration beats any stylesheet rule without it. Getting this wrong is
   invisible -- the bar simply stays Turbo's blue, which looks exactly like
   having written no rule at all, which is why there is a browser check. */
.turbo-progress-bar {
  height: 3px;
  background-color: var(--badge-yellow-text) !important;
}