/**
 * Front-end styles shared by the Divi 4 and Divi 5 builds of this plugin's
 * modules. Both render the same markup, so both read the same CSS and a page
 * looks identical in either builder.
 *
 * Keep this to structure and behavior only. Anything the buyer should be able
 * to change (color, font, spacing, border) belongs in a native Divi module
 * control, not here, the Design tab controls are Phase 3 follow-up work;
 * these are sane structural defaults until that lands.
 */

.pcd-frm-form-wrap {
	box-sizing: border-box;
}

.pcd-frm-form-wrap *,
.pcd-frm-form-wrap *::before,
.pcd-frm-form-wrap *::after {
	box-sizing: inherit;
}

.pcd-frm-form-title {
	margin: 0 0 16px;
}

.pcd-frm-field {
	margin: 0 0 16px;
}

.pcd-frm-field-label {
	display: block;
	margin: 0 0 6px;
	font-weight: 600;
}

/* Label Placement: Left (Settings tab), every field's label sits beside its
   input instead of above it. CSS Grid rather than flex on purpose: a field
   isn't always "one label + one input", a checkbox_group/radio field is
   "one label + several stacked options", and with flex, every one of those
   sibling elements becomes its own row-item (they'd all cram onto one
   horizontal line). Grid's auto-placement instead puts the label at column
   1 and lets every sibling that follows it flow into column 2, each on its
   own row within that column, the first option lines up beside the label,
   later ones stack under it, never squeezed onto one line. Deliberately
   doesn't try to align every field's label to one shared column width
   across the whole form the way a <table>-based layout would, that's a
   bigger, more opinionated change than "move the label," left for later if
   it's ever actually wanted. */
.pcd-frm-form-wrap--label-left .pcd-frm-field {
	display: grid;
	grid-template-columns: 160px 1fr;
	column-gap: 12px;
	align-items: start;
}

/* Default: span both columns, covers every field with no separate
   .pcd-frm-field-label element at all (a single checkbox toggle's own
   label wraps the checkbox instead; content/section-break render their own
   heading markup directly), without this, a lone child would auto-place
   into just the narrow 160px label column instead of the field's full
   width. Narrowed to column 2 below, only for what actually follows a
   real field label. */
.pcd-frm-form-wrap--label-left .pcd-frm-field > * {
	grid-column: 1 / -1;
}

.pcd-frm-form-wrap--label-left .pcd-frm-field-label {
	grid-column: 1;
	margin: 0;
}

.pcd-frm-form-wrap--label-left .pcd-frm-field-label ~ * {
	grid-column: 2;
}

.pcd-frm-required {
	color: #c0392b;
}

.pcd-frm-input {
	display: block;
	width: 100%;
	padding: 10px 12px;
	border: 1px solid #ccd0d4;
	border-radius: 4px;
	font: inherit;
	background-color: #fff;
	color: inherit;
}

/* No real front-end field is ever :disabled, only the admin builder's own
   live canvas preview is, wrapped in a <fieldset disabled> so it's inert
   (see PCD_FRM_Builder_Admin::render_field_preview_html()). Without this,
   every browser falls back to its own native disabled-input look (usually
   a dull grey fill), which reads as "broken," not "this is what your real
   field looks like", the entire point of that preview. Doesn't touch
   readonly (the calculated field's own intentional grey, just below,
   uses `readonly`, not `disabled`, precisely so this rule leaves it alone).

   Deliberately background-color, not the `background` shorthand: a <select>
   picks up wp-admin core's own chevron background-image + no-repeat, and
   `background: #fff` here would reset every background-* sub-property it
   doesn't mention, including background-repeat, back to its CSS default of
   `repeat`, which is exactly what tiled that chevron across the whole
   dropdown the first time this rule shipped with the shorthand. */
.pcd-frm-input:disabled {
	background-color: #fff;
	color: inherit;
	opacity: 1;
}

.pcd-frm-form textarea.pcd-frm-input {
	min-height: 120px;
	resize: vertical;
}

.pcd-frm-field-description {
	margin: 6px 0 0;
	font-size: 0.875em;
	opacity: 0.75;
}

.pcd-frm-field-file-hint {
	margin: 4px 0 0;
	font-size: 0.8em;
	opacity: 0.65;
}

/* A calculated field's value comes from its formula, never from typing
   the readonly look is the visual cue, not just the attribute. */
.pcd-frm-input--calculated {
	background: #f3f4f6;
	cursor: default;
}

.pcd-frm-checkbox-label,
.pcd-frm-radio-label {
	display: block;
	font-weight: normal;
	margin: 0 0 4px;
}

/* Compound fields (Name, Address, see PCD_FRM_Render::render_compound_field())
, several sub-parts sit in a row under one outer field label. Shared box
   layout here; per-key widths below are specific to each compound type
   (Name's Prefix/Suffix are short; Address's Street needs to be much wider
   than its City/State/Zip row). */
.pcd-frm-compound-part {
	display: inline-flex;
	flex-direction: column;
	vertical-align: top;
	margin: 0 12px 8px 0;
}

.pcd-frm-compound-part-label {
	font-size: 0.85em;
	font-weight: normal;
	opacity: 0.75;
	margin: 0 0 4px;
}

.pcd-frm-name-part--prefix,
.pcd-frm-name-part--suffix {
	width: 80px;
}

.pcd-frm-name-part--first,
.pcd-frm-name-part--middle,
.pcd-frm-name-part--last {
	width: 160px;
}

/* Address: Street/Address Line 2 span the full row on their own (a real
   street address needs more room than a fixed column width), City/State/
   Zip/Country share a second row at narrower fixed widths. */
.pcd-frm-address-part--street,
.pcd-frm-address-part--street2 {
	display: flex;
	width: 100%;
}

.pcd-frm-address-part--city {
	width: 220px;
}

.pcd-frm-address-part--state {
	width: 140px;
}

.pcd-frm-address-part--zip {
	width: 120px;
}

.pcd-frm-address-part--country {
	width: 160px;
}

.pcd-frm-field--has-error .pcd-frm-input {
	border-color: #c0392b;
}

/* Field Size (Appearance tab), sizes the whole field, not just the input,
   matching how Gravity/Fluent's own "Field Size" setting works. Large (the
   default) stays full-width, i.e. no rule needed for it. */
.pcd-frm-field--size-small {
	max-width: 200px;
}

.pcd-frm-field--size-medium {
	max-width: 400px;
}

.pcd-frm-field-empty-notice {
	margin: 0;
	padding: 8px 10px;
	background: #fef2f2;
	border: 1px dashed #c0392b;
	border-radius: 4px;
	font-size: 0.875em;
}

/* Honeypot: pulled off-screen rather than display:none, since some bots
   still skip visually-hidden-but-present fields but not display:none ones
   this stays in the layout flow, just invisible and unreachable by tab. */
.pcd-frm-hp-wrap {
	position: absolute;
	left: -9999px;
	width: 1px;
	height: 1px;
	overflow: hidden;
}

.pcd-frm-form-message {
	margin: 0 0 16px;
	padding: 10px 12px;
	border-radius: 4px;
	font-size: 0.95em;
}

.pcd-frm-form-message--success {
	background: #edf9f0;
	border: 1px solid #34a853;
	color: #1e7e34;
}

.pcd-frm-form-message--error {
	background: #fef2f2;
	border: 1px solid #c0392b;
	color: #c0392b;
}

.pcd-frm-form-submit {
	cursor: pointer;
}

.pcd-frm-form-submit:disabled {
	opacity: 0.6;
	cursor: default;
}

/* Multi-step (Phase 5): progress bar + Prev/Next controls. Step pages
   themselves need no layout rule, the `hidden` attribute (native HTML,
   not a class) is what actually shows/hides one, both here and for
   conditionally-shown fields. */

.pcd-frm-progress {
	display: flex;
	gap: 8px;
	margin: 0 0 20px;
}

.pcd-frm-progress-step {
	flex: 1;
	text-align: center;
	opacity: 0.5;
}

.pcd-frm-progress-step--active,
.pcd-frm-progress-step--done {
	opacity: 1;
}

.pcd-frm-progress-step-num {
	display: inline-block;
	width: 24px;
	height: 24px;
	line-height: 24px;
	border-radius: 50%;
	background: #e3e7ee;
	font-size: 0.8em;
	margin-bottom: 4px;
}

.pcd-frm-progress-step--active .pcd-frm-progress-step-num,
.pcd-frm-progress-step--done .pcd-frm-progress-step-num {
	background: currentColor;
	color: #fff;
}

.pcd-frm-progress-step-label {
	display: block;
	font-size: 0.8em;
}

.pcd-frm-step-nav {
	display: flex;
	justify-content: space-between;
	gap: 10px;
	margin: 20px 0 0;
}

.pcd-frm-step-prev,
.pcd-frm-step-next {
	cursor: pointer;
}