/* 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;
}

/* Grid column headers (child table "list of documents" style tables):
   Frappe's own .grid-heading-row fixes a 32px row height with no wrap
   allowance. Kashish: "wrap text is not there in the list of documents
   can we do this like in all web forms child tables wrap text also for
   column names" -- scoped to .web-form-container (every web form, not
   just Doc Submission) rather than one table/doctype, so this covers
   every current and future child table column header portal-wide, no
   per-table rule needed.

   The real truncation isn't on .grid-static-col (the outer cell) at all
   -- confirmed live, 2026-10-13: a first attempt styling only that outer
   element had zero effect, screenshotted still truncating ("OD Area
   foc...", "The project...") on Project Feedback/Consultant Feedback's
   own tables. Root cause, traced in grid_row.js: the header's actual
   text sits in its OWN nested `<div class="static-area ellipsis">`
   (shared with data cells -- the surrounding code's own comment: "set
   title attribute to see full label for columns in the heading row"),
   and core's plain `.ellipsis` utility class (frappe's global.scss) sets
   white-space/overflow/text-overflow directly on THAT inner div --
   overriding the outer container's own white-space/overflow does nothing
   to a child that sets those properties itself. Targets that inner div
   specifically now. Data CELL values in non-Text columns still truncate
   -- a separate, narrower ask if that's wanted too. */
.web-form-container .grid-heading-row,
.web-form-container .grid-heading-row .grid-row {
	height: auto;
	min-height: 32px;
}
.web-form-container .grid-heading-row .grid-static-col {
	height: auto;
}
.web-form-container .grid-heading-row .grid-static-col .static-area.ellipsis {
	white-space: normal !important;
	overflow: visible !important;
	text-overflow: unset !important;
	word-wrap: break-word;
}

/* Data CELL values, not just column headers: Kashish, 2026-10-14, screenshot
   of FOI Capacity Assessment's Budgeting confidence grid -- "We understand
   the difference between programmatic a..." truncated identically to the
   header-row case above, same root cause (the SAME shared .static-area.
   ellipsis inner div, just inside an ordinary .grid-row instead of
   .grid-heading-row this time). Exactly the narrower, separate ask this
   file's own earlier comment anticipated ("Data CELL values in non-Text
   columns still truncate"). Same fix, same broad .web-form-container scope
   -- every child table's row values, portal-wide. */
.web-form-container .grid-body .grid-row {
	height: auto;
	min-height: 32px;
}
.web-form-container .grid-row .grid-static-col {
	height: auto;
}
.web-form-container .grid-row .grid-static-col .static-area.ellipsis {
	white-space: normal !important;
	overflow: visible !important;
	text-overflow: unset !important;
	word-wrap: break-word;
}

/* Footer: keep Delete (destructive) visually apart from Next/Submit (the
   actions a respondent actually wants most of the time), so a misclick is
   less likely. */
.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;
}

/* Submit: Kashish, 2026-10-14 -- "keep submit button but not near save draft
   or next button" -- the JS override that hid Submit until the last page
   (atma_web_form.js) is a real monkey patch around a genuine Frappe gap
   (allow_incomplete, needed for Save Draft/resume-later, has the side
   effect of keeping Submit visible on every page too), and kept breaking in
   new ways every time it was touched. Decided to stop fighting that native
   behaviour instead: Submit stays visible everywhere, same as plain Frappe
   does by default, but pushed to its own position (flex order, same
   mechanism the delete-btn separation above already uses) with zero JS
   behaviour override at all.

   Follow-up, same day: "thoda aur alg" (a bit more separate) -- margin-left
   alone only separated it when the row had enough width to wrap on its own;
   flex-basis: 100% forced it onto its own line, but only spanning its own
   parent's column (.right-area), sitting under Next/Save Draft specifically
   rather than the full footer width -- "can we keep this button bottom of
   dots" confirms the ask is a full-width bar under the ENTIRE footer row
   (left-area/Previous + center-area/dots + right-area all together), not
   just under its own nested column. A flex child can't outgrow its own
   parent's box through flex properties alone, so this takes it out of the
   row's flex flow entirely (position: absolute, anchored to .web-form-
   footer itself, given position: relative below so the anchor is this
   footer and not some further, unrelated ancestor) and spans it edge to
   edge instead. padding-bottom on the footer reserves the room this now
   needs below the row, since an absolutely positioned element no longer
   pushes later content down on its own.

   Also recoloured, same ask ("can we keep in other color") -- a distinct
   blue, not the same mint/teal every progress action (Next, Previous,
   Save Draft's own hover) already uses, so Submit reads as its own,
   separate kind of action rather than one more button in that group. */
.web-form-footer {
	position: relative;
	/* The Submit button was overflowing past the card's bottom border --
	   56px matched margin-top(12px) + the button's own height almost
	   exactly, so the button's real rendered height (border/line-height
	   included) pushed a few px past this reserved space and crossed the
	   card's own bottom border. A few px of slack fixes that without changing
	   the button's own look or position relative to the footer row. */
	padding-bottom: 64px;
}

.web-form-footer .right-area .submit-btn {
	position: absolute;
	left: 0;
	right: 0;
	top: 100%;
	/* Kashish: "keep little upper, ye border se bahar ja rha" -- still crossing
	   the card's bottom border even with the padding-bottom slack above;
	   trimmed from 12px to pull it further up inside that reserved space. */
	margin-top: 4px;
	background-color: #1d4ed8 !important;
	border-color: #1d4ed8 !important;
	color: #fff !important;
}

.web-form-footer .right-area .submit-btn:hover {
	background-color: #1e40af !important;
	border-color: #1e40af !important;
}

/* Discard: Kashish, 2026-10-13: "remove discard button from all over the
   web forms we do not need this" -- hidden, not removed from the DOM.
   Frappe core's own setup_previous_next_button() (web_form.js) attaches
   the Next button via insertAfter(".right-area .discard-btn") -- hiding
   (rather than the JS .remove() this app used to do for other internal-
   only actions) keeps that anchor present in the DOM so Next still
   attaches exactly where it always has, with no knock-on effect on that
   insertion at all. The old "move Discard next to Previous" JS fix (#4,
   atma_web_form_ux.js) is retired now that there's nothing left to move. */
.web-form-footer .right-area .discard-btn {
	display: none !important;
}

/* 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,
.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) and apparently a plain
   ".btn-primary" class 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 a class.
   Targets ".btn-next" alone (not ".btn-next.btn-primary") since 2026-09-30
   -- this used to depend on a JS-added "btn-primary" class (removed,
   Kashish: "we do not want monkey patch if not required"); ".btn-next" is
   Frappe's own permanent class on this button (set once in its own
   web_form.js template), so styling it directly needs no JS at all. */
.web-form-footer .btn-next,
.web-form-footer .btn-next:active {
	background-color: var(--btn-primary-bg, #171717) !important;
	border-color: var(--btn-primary-bg, #171717) !important;
}

.web-form-footer .btn-next: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;
}

/* Monkey-patch remediation plan, Step 4 (2026-10-07): "Edit your response"
   is one of 2 buttons Frappe's own render_success_page() adds after a real
   Submit (web_form.js) -- allow_edit=1 (needed so a saved Draft stays
   reopenable) makes it show after a genuine final Submit too, which this
   app doesn't want (every form here locks a real submission server-side,
   atma_web_form.js's own after_load hook already JS-hid the whole function
   via render_success_page = function(){}, which also collaterally hid the
   OTHER button it adds, "View your response" -- restored by hiding only
   this one here, in CSS, instead. */
.success-footer .edit-button {
	display: none !important;
}