/*!
 * DataLabelify - forms.css
 * The minimum styling the WPForms takeover layer cannot do without.
 *
 * SCOPE RULE
 *   Own classes (.dl-*) are styled normally. Anything WPForms already owns
 *   (.wpforms-error, .wpforms-error-container, .wpforms-confirmation-container-full)
 *   is wrapped in :where(), which has ZERO specificity - so if the parity build ships
 *   WPForms' own stylesheet (it does) or the Blocksy theme overrides it, their rules
 *   win and the visitor sees the same design as on WordPress. These are a safety net
 *   for the case where a page renders an error before WPForms CSS has loaded.
 *
 * RTL
 *   Logical properties only (inset-inline, margin-block, padding-inline). No left/
 *   right anywhere, so Arabic needs no second stylesheet.
 */

/* -- honeypot: off-screen, unfocusable, invisible to AT, still in the POST body -- */
.dl-hp {
  position: absolute !important;
  inset-inline-start: -9999px;
  inset-block-start: auto;
  width: 1px;
  height: 1px;
  overflow: hidden;
  clip-path: inset(50%);
  white-space: nowrap;
  pointer-events: none;
}

.dl-hp input {
  width: 1px;
  height: 1px;
  opacity: 0;
}

/* -- resume upload: the real <input type=file> injected into WPForms' Dropzone div -- */
.wpforms-uploader .dl-file-input {
  display: block;
  width: 100%;
  margin-block-start: 0.75em;
  font: inherit;
  cursor: pointer;
}

.wpforms-uploader .dl-file-chosen:not(:empty) {
  display: block;
  margin-block-start: 0.5em;
  font-size: 0.9em;
  opacity: 0.85;
  word-break: break-word;
}

/* -- in-flight state -------------------------------------------------------- */
.dl-form-busy {
  cursor: progress;
}

.dl-form-busy .wpforms-submit,
.wpforms-submit.wpforms-disabled {
  opacity: 0.6;
  cursor: progress;
}

.dl-form-busy .wpforms-field input,
.dl-form-busy .wpforms-field textarea,
.dl-form-busy .wpforms-field select {
  pointer-events: none;
}

/* -- zero-specificity safety net for WPForms' own state classes -------------- */
:where(.wpforms-error) {
  display: block;
  margin-block-start: 0.35em;
  font-size: 0.875em;
  line-height: 1.4;
  color: #d63638;
}

:where(input.wpforms-has-error),
:where(textarea.wpforms-has-error),
:where(select.wpforms-has-error) {
  border-color: #d63638;
}

:where(.wpforms-error-container) {
  margin-block-end: 1em;
  padding-block: 0.75em;
  padding-inline: 1em;
  border-inline-start: 3px solid #d63638;
  background: rgba(214, 54, 56, 0.07);
  color: #8a1f21;
  font-size: 0.95em;
  line-height: 1.5;
}

:where(.wpforms-confirmation-container-full) {
  margin-block: 1em;
  padding-block: 1em;
  padding-inline: 1.25em;
  border: 1px solid #b5dfb5;
  background: #eaf7ea;
  color: #1f5c2e;
  line-height: 1.6;
}

:where(.wpforms-confirmation-container-full) p:last-child {
  margin-block-end: 0;
}

/* NO dark-mode block, deliberately.
 *
 * The parity build is light-only: not one captured page declares
 * `color-scheme`, and the Blocksy theme ships no dark theme. A
 * `prefers-color-scheme: dark` block here therefore never matches a real host
 * page's background — it composites dark text over white.
 *
 * Measured, against the white the page actually paints:
 *   #b8e6c2 on rgba(47,107,61,.18)  -> 1.06:1   (an invisible confirmation)
 *   #f3a3a4 on rgba(214,54,56,.14)  -> 1.62:1
 * Against the light values kept above:
 *   #1f5c2e confirmation            -> 7.22:1
 *   #8a1f21 error                    -> 8.26:1
 *
 * Today WPForms' own stylesheet outranks these :where() rules, so the dark
 * block was dead code — which is exactly why it had to go. These rules exist as
 * the fallback for the case where wpforms-full.min.css has NOT loaded, and in
 * that one case a visitor whose OS is in dark mode would have got
 * "we received your message" at 1.06:1. A safety net that fails in the only
 * situation it exists for is worse than none.
 *
 * Reintroduce dark styling when the static build actually ships a dark theme,
 * and gate it on a class the host page sets, never on the OS preference.
 */