/* External-form usability pass: bold/larger readable labels, and hiding grid
   row-actions that only make sense for an internal Desk user (an external
   respondent has no reason to ever see Move/Duplicate/Insert Above/Insert
   Below/Delete on a table row -- the one Add Row/Delete Row control each
   table already has, where allowed, is the only add/remove action needed).
   Kashish, live: "why you remove delete row option for that child table also
   where we select like here if we select wrong and i wnat to delete then?"
   -- then, once broadened to every table: "no i only want for that child
   table in which we have option of selecction". So: stays hidden by default
   below (most of these tables are fixed/pre-seeded question rows, e.g.
   TANG's *_grid rating tables, where delete has no legitimate use); the one
   named exception -- a genuine pick-from-a-list "Table MultiSelect" table
   where a wrong row really does need deleting -- is carved back in further
   down, scoped to that field only. */

.web-form-container .control-label {
	font-weight: 700;
	font-size: 15px;
	white-space: normal;
	overflow-wrap: break-word;
}

.web-form-container .frappe-control {
	font-size: 14.5px;
}

/* Field description/help text (e.g. a question's own answer-options list)
   renders with Frappe's own ".text-extra-muted" class -- a light grey that's
   hard to read, especially on a long paragraph like this. Darkened for
   legibility; kept a shade lighter than the label itself so the visual
   hierarchy (label vs. helper text) still reads clearly. */
.web-form-container .help-box,
.web-form-container .grid-description {
	color: #3a4750 !important;
}

/* Grid row expanded-edit view: Move/Duplicate/Insert Above/Insert Below/
   Delete are all internal-only actions with no external-facing equivalent
   asked for -- hidden unconditionally, regardless of a table's own
   add/delete-row setting (that setting still governs the plain "Add Row"/
   trash-icon controls elsewhere in the same grid). */
.web-form-container .grid-move-row,
.web-form-container .grid-duplicate-row,
.web-form-container .grid-insert-row,
.web-form-container .grid-insert-row-below,
.web-form-container .grid-append-row,
.web-form-container .grid-delete-row,
.web-form-container .grid-remove-rows,
.web-form-container .grid-duplicate-rows,
.web-form-container .grid-remove-all-rows,
.web-form-container .grid-add-multiple-rows {
	display: none !important;
}

/* Exception: every user-addable child table (the applicant can freely Add
   Row -- anything NOT locked via grid.cannot_add_rows in that form's own
   client_script for a fixed/pre-seeded catalog) needs a working Delete Row,
   the same way "TaRa AtmaNirbhar Grant" TANG workshop surveys' own "What is
   a logic model used for?" question originally needed one on its own
   (previously a [data-fieldname="logic_model_used_for"]-scoped rule here --
   removed 2026-09-19, superseded by this generic one once
   atma_child_table_ux.js started auto-detecting every such field
   portal-wide, not just window.ATMA_MULTISELECT_DISPLAY's own narrower
   registry; that fieldname-only rule also never covered TANG ToC's own
   sibling "toc_used_for" field despite sharing the identical child doctype,
   which this fixes too). Rather than hand-adding each field's own
   [data-fieldname=...] selector here, atma_child_table_ux.js marks each one
   it auto-detects with this class at runtime -- one CSS rule covers every
   current and future field. "Delete all" stays hidden per Kashish -- too
   destructive/easy to trigger by accident; the row-level Delete and
   checkbox-select-then-Delete pair are enough to fix a wrong pick or an
   empty row.

   .grid-remove-rows needs :not(.hidden) here -- code-review catch: Frappe
   toggles that exact button's own ".hidden" class based on whether a row's
   checkbox is ticked (grid.js refresh_remove_rows_button()), and plain
   ".hidden{display:none!important}" (specificity 0,0,1,0) loses outright to
   this override's higher specificity (0,0,3,0) without the :not() -- the
   button would render permanently, checkbox state or not. .grid-delete-row
   has no such toggle (grid_row_form.js only ever gates it on cannot_delete_
   rows, which these tables don't set), so it doesn't need the same guard. */
.web-form-container .atma-select-per-row-grid .grid-delete-row,
.web-form-container .atma-select-per-row-grid .grid-remove-rows:not(.hidden) {
	display: revert !important;
}

/* Footer: keep Discard/Delete (destructive) visually apart from Next/Submit
   (the actions a respondent actually wants most of the time), so a misclick
   is less likely. Discard itself is moved into left-area, next to Previous
   (see atma_web_form_ux.js) -- this just spaces the two apart there. */
.web-form-footer .left-area {
	display: flex;
	align-items: center;
	gap: 8px;
}

.web-form-footer .right-area {
	display: flex;
	align-items: center;
	flex-wrap: wrap;
	gap: 8px;
}

.web-form-footer .right-area .delete-btn {
	margin-left: 20px;
}

/* Page progress dots: now clickable (see atma_web_form_ux.js) -- show that
   with a pointer cursor. */
.web-form-footer .center-area.paging .slide-step {
	cursor: pointer;
}

/* The primary action button (Next/Submit, and any other .btn-primary this
   stylesheet reaches -- it's only ever loaded on portal/website pages, never
   Desk, via web_include_css, so this is safe to apply broadly): the button's
   own fill colour is left as-is -- the actual problem is its white text,
   low-contrast against the theme's own light mint fill. Bold, dark text
   instead, so it's readable regardless of the fill shade. frappe_desk_theme's
   own ".btn-primary { !important }" rule loads AFTER this stylesheet, so an
   equal-specificity !important rule here would still lose the tie on source
   order -- these selectors are deliberately more specific (multiple classes)
   so they win regardless of load order. */
body .btn-primary,
body .btn-primary:active,
.web-form-footer .btn-next.btn-primary,
.web-form-footer .submit-btn.btn-primary {
	font-weight: 700 !important;
	color: #0b3d2a !important;
}

body .btn-primary span,
body .btn-primary:active span {
	color: #0b3d2a !important;
}

/* Previous: same green fill as Next/Submit -- reuses the theme's own
   --btn-primary-bg/--btn-primary-hover-bg custom properties (set at runtime
   by frappe_desk_theme from the portal's own theme color) rather than a
   hardcoded hex, so it always matches whatever that color actually is --
   plus the same bold/dark text treatment for readability on that fill. */
.web-form-footer .btn-previous,
.web-form-footer .btn-previous:active {
	background-color: var(--btn-primary-bg, #171717) !important;
	border-color: var(--btn-primary-bg, #171717) !important;
}

.web-form-footer .btn-previous:hover {
	background-color: var(--btn-primary-hover-bg, var(--btn-primary-bg, #171717)) !important;
	border-color: var(--btn-primary-hover-bg, var(--btn-primary-bg, #171717)) !important;
}

.web-form-footer .btn-previous,
.web-form-footer .btn-previous span {
	font-weight: 700 !important;
	color: #0b3d2a !important;
}

/* Next: Kashish, live, 2026-09-20 -- "green color on next button not
   showing". Unlike Submit (server-template-rendered with "btn-primary"
   from page load), Next is created client-side as plain "btn btn-default
   btn-next btn-sm" (frappe's own web_form.js) -- REMOVE_POST_SUBMIT_
   BUTTONS_JS only ever adds the "btn-primary" class to it afterward, and
   apparently that alone isn't enough to pick up frappe_desk_theme's own
   green fill for a "btn-sm"-sized button (unlike Previous just above,
   which never relied on the "btn-primary" class working correctly and
   sets its own background explicitly instead). Same fix: set the fill
   directly from the same CSS variable, rather than trust the class alone. */
.web-form-footer .btn-next.btn-primary,
.web-form-footer .btn-next.btn-primary:active {
	background-color: var(--btn-primary-bg, #171717) !important;
	border-color: var(--btn-primary-bg, #171717) !important;
}

.web-form-footer .btn-next.btn-primary:hover {
	background-color: var(--btn-primary-hover-bg, var(--btn-primary-bg, #171717)) !important;
	border-color: var(--btn-primary-hover-bg, var(--btn-primary-bg, #171717)) !important;
}