/* SafeKivi Date Picker — styles for the calendar popover sk-datepicker.js renders. Loaded app-wide by layout.html, right after site.css, because the accents below resolve through the Design Config tokens site.css declares (and theme.js re-writes per tenant): the calendar re-themes with the rest of the application instead of carrying its own palette. The one deliberate exception is the popover's own surface — see `.sk-dp` below. */ /* The enhanced input keeps type="date" for its value semantics, but the browser's own indicator icon would now open a *second*, native calendar beside ours — hide it. (WebKit/Blink only; Firefox has no equivalent hook, there the script suppresses the native popup via mousedown instead.) */ .sk-dp-input::-webkit-calendar-picker-indicator { display: none; } /* No `cursor: pointer` here on purpose: the field is still a text control whose segments accept typing and click-to-select, and the I-beam is what says so. The calendar is an addition to that, not a replacement for it. */ /* `.sk-input-clear` is positioned at `right: 34px` (site.css) to sit clear of the browser's own calendar button — which the rule above has just removed. On an enhanced field that reservation is an empty 34px gutter with the clear button floating in from the edge, so it returns to the inset the control's own padding implies. */ .sk-input-icon:has(.sk-dp-input) .sk-input-clear { right: 12px; } /* ── Row alignment ────────────────────────────────────────────────────────── A date input does NOT size like a text input. Its height comes from the shadow-DOM segments (dd-mm-yyyy), and Chrome enforces an intrinsic minimum on them that exceeds the control's own line box — so the field renders a couple of pixels taller than the selects beside it on the same row. That minimum cannot be styled away from inside: zeroing the segments' padding and line-height helps where padding is the cause, but leaves the intrinsic floor intact (measured: still up to ~2.7px over a text input). So the height is stated explicitly against the control's own line box, taking it off intrinsic sizing altogether. Deliberately NOT `box-sizing: content-box`, which resolves the height perfectly on its own but is not a per-axis property — it changes what `width` means too. Several date fields here carry an inline width (`style="width:150px"` on the email-log filters, `max-width:125px` on the super-admin log filters), and an inline declaration outranks any class, so those would keep their px as a CONTENT width and render ~22px wider than the control beside them. A visible width break is a bad trade for a sub-pixel height gain. The vertical padding is carried in a variable because this app ships two control sizes. The only approximation left is the 2px border term: at non-100% zoom borders resolve to fractional pixels, leaving up to ~0.5px — invisible, and an order of magnitude below the ~2-3px the intrinsic minimum contributes. `1lh` is the control's real line box, so this holds on any form whose controls use a different line-height — unlike a hardcoded `1.5em`, which inflates the field wherever that assumption does not hold. Gated on `lh` support; without it the field simply keeps its natural height, as before. */ @supports (height: 1lh) { .sk-dp-input { height: calc(1lh + (var(--sk-dp-pad-y, 8px) * 2) + 2px); } /* The app's small control (site.css: `padding: 6px 10px`) — the incident report, email-log and super-admin date filters all use it. */ .form-control-sm.sk-dp-input { --sk-dp-pad-y: 6px; } /* Every one of these sits in a form row (or filter toolbar) beside a plain sharing its row (2026-08-21) - each one hand-confirmed against its template, not inferred from the pattern alone. Dropping to the same 6px this component already uses for the small control (above) closes the gap. The real `padding` is lowered alongside `--sk-dp-pad-y`, not just the variable - the calc above sizes the box from that variable, so moving one without the other would leave the digits sitting on a border 4px too close for the room the box actually reserves them. #aDueDate training/assignments.html - Priority, Assignment Type #actDetailDue partials/_remediation_detail_modal.html - Assignee, Severity #actCreateDue partials/_remediation_create_modal.html - Assignee, Severity #inputDob profile/index.html - Gender #dCapaDue incidents/detail.html - Assign To #logFormPerformedDate assets/detail.html - Type #planStartDate control_center/audit_plans.html - Recurrence, End date #planEndDate control_center/audit_plans.html - Recurrence, Start date #findingDueDate partials/_audit_finding_modal.html - Classification, Severity */ #aDueDate.sk-dp-input, #actDetailDue.sk-dp-input, #actCreateDue.sk-dp-input, #inputDob.sk-dp-input, #dCapaDue.sk-dp-input, #logFormPerformedDate.sk-dp-input, #planStartDate.sk-dp-input, #planEndDate.sk-dp-input, #findingDueDate.sk-dp-input { padding-top: 6px !important; padding-bottom: 6px !important; --sk-dp-pad-y: 6px; } /* Same mismatch as the group above, but on fields that were already `.form-control-sm` (the small-control rule immediately above this one) - three log/report filter toolbars pairing a small date field with a small Select2