/*
 * A disabled control that looks disabled.
 *
 * TABLER 1.5 FIXED THE INPUT AND LEFT THE SELECT, WHICH IS THE CASE THIS WAS WRITTEN FOR.
 *
 * 1.5 added --tblr-bg-forms-disabled, so the background does change now where 1.4.0's did not in
 * dark. But the background was never the whole signal, and measuring Tabler alone - this sheet
 * disabled, on the samples app - shows which half moved. Contrast of the enabled-to-disabled change:
 *
 *                      background        text
 *     dark   input        1.209          2.051
 *     dark   select       1.209          1.000   no change at all
 *     light  input        1.045          2.132
 *     light  select       1.045          1.000   no change at all
 *
 * A text input is now fine unaided: it dims its text as well as its background, which is two cues.
 * A SELECT STILL CHANGES NOTHING BUT ITS BACKGROUND, exactly as the first version of this comment
 * called out - "a disabled select is worse still: its text color does not change either". In light
 * mode that leaves 1.045 as the entire signal, which is the same 1.5% shift this sheet was written
 * to reject, unchanged by the upgrade. Screenshotted with the sheet off: the disabled select is not
 * distinguishable from the enabled ones beside it.
 *
 * So the opacity stays, and the reason is the select rather than a preference for dimmer controls.
 * It dims border, glyph and text together, which is a cue that does not depend on the one channel
 * Tabler leaves flat, and disabled controls are exempt from WCAG 1.4.3's contrast floor so dimming
 * costs nothing there. The not-allowed cursor stays too, and is still the only non-color cue either
 * stylesheet provides - measured, Tabler leaves the cursor at default.
 *
 * The cost of keeping it, stated so it is a decision rather than an oversight: a disabled control
 * here is dimmer than the same control on Tabler's own pages, so an application matching a Tabler
 * design will see a difference. Drop the opacity if that matters more than the select.
 *
 * A disabled select is the case that still matters, and the table above is why: its text color
 * does not change in either scheme, so the background is its whole signal.
 *
 * This matters here beyond taste. Wicket renders `disabled` for any component with setEnabled
 * (false), and a form that disables a field until a checkbox is ticked is asking the visitor to
 * notice which is which; a settings page of inherited values is most of one.
 *
 * The fix is opacity rather than another background, and that is deliberate. Picking a color means
 * picking one per scheme, and then picking again for a control on a card rather than on the page,
 * since dark mode's form background (#111827) and card surface (#1f2937) are both in play and a
 * value distinct from one sits on top of the other. Opacity is a ratio, so it holds against any
 * surface, dims border and text together, and is the same signal Bootstrap already uses for a
 * disabled button - --bs-btn-disabled-opacity, 0.65.
 *
 * not-allowed rather than Tabler's default cursor, because the pointer is the other half of the
 * message and costs nothing.
 *
 * Checkboxes, radios and switches are deliberately absent. Tabler already handles those, and
 * measurably: .form-check-input:disabled is opacity 0.5 with pointer-events: none, and
 * .form-check-input:disabled ~ .form-check-label is opacity 0.7 with cursor: default. Adding 0.65
 * on top would make the input *less* dimmed than Tabler leaves it.
 *
 * :disabled only. [readonly] is excluded on purpose: a readonly control is still focusable, still
 * copyable and still submitted, and dimming it would say the opposite.
 */
.form-control:disabled,
.form-select:disabled,
.form-control-color:disabled,
.form-range:disabled {
	opacity: 0.65;
	cursor: not-allowed;
}

/*
 * A password reveal that sits inside the field rather than beside it.
 *
 * PasswordFormField.revealable() renders its toggle in the input group's own .input-group-text
 * span, which is the right structure and, under both Bootstrap and Tabler, the wrong appearance for
 * this particular addon: the span carries its own border and background, so a control that belongs
 * to the field reads as a second segment bolted onto it, divided by a rule.
 *
 * Tabler ships the answer as .input-group-flat, and it cannot be used from where the markup is
 * written - that class has to sit on the group element, and the group is wicket-bootstrap5's, a
 * theme-free module that cannot name a Tabler class. So the treatment is applied here, selected by
 * the marker the library does write. :has() for the same reason: it lets the theme key off markup
 * the other module owns, and needs no new plumbing in FormField to expose the group. Baseline
 * across browsers since 2023.
 *
 * EVERY VALUE AN APPLICATION MIGHT DISAGREE WITH IS A CUSTOM PROPERTY WITH A FALLBACK, AND THAT IS
 * NOT DECORATION.
 *
 * The first version of this sheet wrote the focus ring and the focus border directly. Both are
 * (0,3,0), the same as an application's own `.some-card .input-group:focus-within`, so the two tied
 * and source order decided - and this sheet is contributed by the theme, after the application's.
 * A sign-in page styled entirely in its own accent therefore got Tabler's primary blue on one field
 * out of five, and the only way out was to escalate specificity with a `:has(.bs5-reveal)` selector
 * of its own. Measured on exactly that page before this was rewritten.
 *
 * Declared as fallbacks at the point of use rather than set on the group, which matters: a property
 * set on .input-group would beat one an application inherits from an ancestor, and the ancestor is
 * where an application naturally states its palette. `var(--x, default)` loses to any declaration
 * anywhere above it, which is the behaviour wanted.
 */
.input-group:has(.bs5-reveal) > .form-control:not(:last-child) {
	border-right: 0;
}

/*
 * The addon holding the toggle, not every addon in the group.
 *
 * `.input-group:has(.bs5-reveal) > .input-group-text` was the first spelling and it matched both:
 * a password field with a leading lock glyph lost that glyph's left border too, so the field opened
 * at its left edge instead of closing the seam at its right. Selecting the addon that contains the
 * control keeps it to the one that needs it, and drops the group-level :has() as redundant.
 */
.input-group > .input-group-text:has(.bs5-reveal) {
	border-left: 0;
	background: var(--bs5-reveal-addon-bg, var(--tblr-bg-forms));
}

.input-group:has(.bs5-reveal):focus-within {
	border-radius: var(--tblr-border-radius);
	box-shadow: var(--bs5-reveal-ring, 0 0 0 .25rem rgba(var(--tblr-primary-rgb), .25));
}

/* Both halves take the focus border, or the ring frames two differently-edged pieces. */
.input-group:has(.bs5-reveal):focus-within > .form-control,
.input-group:has(.bs5-reveal):focus-within > .input-group-text {
	border-color: var(--bs5-reveal-focus-border, var(--tblr-border-color));
}

/* The control's own ring would otherwise be drawn inside the group's, one rectangle within another. */
.input-group:has(.bs5-reveal) > .form-control:focus {
	box-shadow: none;
}

/*
 * An addon that moves with the control it belongs to.
 *
 * Tabler gives .form-control `transition: border-color .15s ease-in-out, box-shadow .15s ease-in-out`
 * and gives .input-group-text nothing - measured at `all` with a duration of 0s. So on focus the
 * control eases over 150ms while the chip beside it changes instantly, and a field that is drawn as
 * one box visibly comes apart for the length of the transition and puts itself back together.
 *
 * Not specific to the password reveal, which is where this was first noticed and first fixed. It is
 * every input group with an addon: a leading icon on an e-mail field shows it just as plainly.
 * Tabler declares the same transition itself, but only under .input-group-flat, so the fix here is
 * to stop that being the one arrangement that behaves.
 *
 * background-color is included because a theme that tints the addon on focus - which this one does
 * in its sign-in card - otherwise animates the border and jumps the fill.
 *
 * Deliberately (0,1,0). This is a default an application should be able to overrule with any rule
 * of its own, which is the mistake the reveal block above was rewritten to stop making.
 */
.input-group-text {
	transition: border-color .15s ease-in-out, box-shadow .15s ease-in-out,
		background-color .15s ease-in-out;
}

@media (prefers-reduced-motion: reduce) {
	.input-group-text {
		transition: none;
	}
}