/*
 * BPBytes EditView re-skin.
 * Targets SuiteCRM's core include/EditView/EditView.tpl markup: one
 * <table class="yui3-skin-sam edit view panelContainer"> per panel, td[id$="_label"] label
 * cells next to the actual SugarField input cell. CSS only — initEditView()/onUnloadEditView()
 * bindings and field-level JS (relate/enum/date pickers) are untouched.
 */

#content.bpbytes-content [id$="_tabs"] .edit.view.edit508,
#content.bpbytes-content div[id^="detailpanel_"] {
    background: var(--bp-surface);
    border: 1px solid var(--bp-border);
    border-radius: var(--bp-radius-lg);
    box-shadow: var(--bp-shadow);
    margin-bottom: 20px;
    padding: 4px 0 8px;
}

/* Deliberately NOT styled like the page title (.moduleTitle) — a small muted uppercase
   "eyebrow" label reads clearly as a section divider rather than competing with it. */
#content.bpbytes-content div[id^="detailpanel_"] > h4 {
    margin: 0;
    padding: 14px 20px;
    font-size: 15px;
    font-weight: 700;
    letter-spacing: 0;
    text-transform: none;
    color: var(--bp-title);
    background: var(--bp-header-tint);
    border-radius: var(--bp-radius-lg) var(--bp-radius-lg) 0 0;
    border-bottom: 1px solid var(--bp-border);
    display: flex;
    align-items: center;
    gap: 8px;
}

#content.bpbytes-content div[id^="detailpanel_"].collapsed table.panelContainer {
    display: none;
}

#content.bpbytes-content div[id^="detailpanel_"] .expandLink,
#content.bpbytes-content div[id^="detailpanel_"].expanded .expandLink {
    display: none;
}

#content.bpbytes-content div[id^="detailpanel_"].collapsed .collapseLink {
    display: none;
}

#content.bpbytes-content div[id^="detailpanel_"].collapsed .expandLink {
    display: inline-flex;
}

/*
 * EditView header cleanup, per request: SugarView::getModuleTitle() always renders a .favorite
 * star and a .utils "+Create" shortcut in the page's top title bar - redundant while already
 * editing a record, same reasoning as DetailView's own (detailview.css). :has(.edit.view.edit508)
 * detects EditView specifically so ListView's own "+Create" stays untouched.
 *
 * include/EditView/header.tpl's second header cell (class="edit-view-pagination") renders
 * {$PAGINATION} (include/EditView/SugarVCR.tpl) - which, on an EditView, is not just the VCR
 * prev/next record nav but ALSO a "Save and Continue" button bundled into that same cell
 * (SugarVCR.tpl's own <button id="save_and_continue">). Removing the "Save and Continue" +
 * pagination pair as one is what dropping this whole cell does. td.buttons then gets what
 * was that cell's share of the row.
 */
#content.bpbytes-content:has(.edit.view.edit508) .moduleTitle .favorite,
#content.bpbytes-content:has(.edit.view.edit508) .moduleTitle .utils {
    display: none;
}

#content.bpbytes-content td.buttons:has(+ td.edit-view-pagination) {
    width: 100%;
}

#content.bpbytes-content td.edit-view-pagination {
    display: none;
}

/*
 * "View Change Log" (Audit) button - function.sugar_button.php's "Audit" case, id=
 * "btn_view_change_log" - opens the field-history popup. Same id/button also renders on
 * DetailView, now folded into the header "Actions" dropdown there (detailViewTabs.js) - this is
 * scoped to EditView only (:has(.edit.view.edit508)) so that DetailView option is left alone.
 */
#content.bpbytes-content:has(.edit.view.edit508) #btn_view_change_log {
    display: none;
}

/*
 * table-layout:fixed - not the browser default (auto), which sizes every column off the widest
 * content anywhere in that column across every row. A field with several sub-controls side by
 * side (e.g. Datetimecombo) needs more room than a single dropdown, and under auto layout that
 * drags its ENTIRE column that wide for every row sharing it, while the sibling column - never
 * containing anything wider than one control - stays narrower. Fixed layout follows the declared
 * widths below exactly, ignoring content, so both value columns (37.5% each, from templateMeta.
 * widths) match regardless of what lands in either one. The label column gets a fixed PIXEL
 * width rather than a percentage, since fixed layout takes a declared width completely literally
 * with no fallback for a label that doesn't fit - a percentage width can't grow for a long label
 * the way auto layout's width:1% hint could.
 */
#content.bpbytes-content table.panelContainer.edit {
    width: 100%;
    border-collapse: collapse;
    table-layout: fixed;
}

/* Users EditView keeps its hidden tab sections outside the YUI content node, so the YUI skin
   cannot hide their contents when the tab links are hidden. Keep only User Information visible. */
#content.bpbytes-content #EditView_tabs > .user-tab-content:not(:first-of-type) {
    display: none;
}

#content.bpbytes-content table.panelContainer.edit tr {
    border-bottom: 1px solid var(--bp-border);
}

#content.bpbytes-content table.panelContainer.edit tr:last-child {
    border-bottom: none;
}

/*
 * vertical-align:top, not middle - a row's height comes from its TALLEST cell (e.g. a
 * Textarea/Description field sharing a row with a plain dropdown like Location), and middle
 * only ever looks right when every cell in a row happens to be the same height. Otherwise the
 * shorter field's own control centers in the extra space while its OWN label (already
 * vertical-align:top below) stays pinned to the top, so label and value drift apart the
 * taller its row-sharing sibling is - "Location" sitting well below "Location:" next to a
 * multi-line "Work Description" textarea was exactly this. Top keeps every value flush with
 * its own label regardless of what else shares the row.
 */
#content.bpbytes-content table.panelContainer.edit td {
    padding: 10px 20px;
    vertical-align: top;
    font-size: 13px;
}

/*
 * A fixed pixel width, not a percentage - sized generously enough for the longest label seen so
 * far ("Medical Treatment Required?:" plus its required-asterisk) - rather than relying on a
 * percentage of the table's own width, which can compute to less room than a long label needs on
 * a narrower panel/viewport. white-space is normal (wrapping allowed), not nowrap, as a fallback
 * for anything even longer than that: table-layout:fixed takes a declared width literally with no
 * escape hatch, so a label that still doesn't fit wraps onto a second line instead of overflowing
 * into the field column next to it.
 */
#content.bpbytes-content table.panelContainer.edit td[id$="_label"] {
    color: var(--bp-text-muted);
    font-weight: 600;
    width: 240px;
    max-width: 240px;
    white-space: normal;
    overflow-wrap: break-word;
    word-break: break-word;
    vertical-align: top;
    padding-top: 14px;
}

/*
 * A single-field row whose value cell spans the other 3 grid columns via colspan (e.g. a bool
 * checkbox with a long, sentence-length label - EditView.tpl only ever adds colspan when a
 * field def explicitly sets one, which a plain single-checkbox row commonly does so its
 * checkbox has room) rendered its OWN label cell as if table-layout:fixed's declared width
 * didn't apply to it at all - the label ran on as one unbroken line instead of wrapping at
 * 240px like every other row's label does. Repeating the width/wrap declarations here with
 * !important, scoped to exactly that row shape, is what actually took effect - table-layout:
 * fixed is only guaranteed to size columns from a table's FIRST row of cells, and a later row
 * whose sibling cell's colspan doesn't match that first row's column count is exactly the edge
 * case that guarantee doesn't cover, so this needs to hold its ground regardless of whatever
 * width the browser was otherwise computing for it.
 */
#content.bpbytes-content table.panelContainer.edit tr:has(> td[colspan]) > td[id$="_label"] {
    width: 240px !important;
    max-width: 240px !important;
    white-space: normal !important;
    overflow-wrap: break-word !important;
    word-break: break-word !important;
}

#content.bpbytes-content table.panelContainer.edit .required {
    color: var(--bp-danger);
    margin-left: 3px;
}

/*
 * A plain bool field's checkbox and its own label text, swapped by style.js's
 * moveCheckboxBeforeLabel(): the (narrow, fixed-width) label cell now holds just the checkbox,
 * and the (wide) value cell now holds the label text, styled to still read as a label
 * (muted/bold, matching td[id$="_label"] above) since visually it's acting as one. Right-
 * aligning the checkbox (rather than centering it) puts it at this cell's own right edge, next
 * to the label text's own left edge in the next cell. Only the checkbox side's padding is
 * tightened (to 0, flush with the column boundary) - the value cell keeps the same padding-left
 * as every other row's field, so the label text still starts at exactly the same x-position as
 * "Select"/every other field in the form, not shifted left out of alignment with them.
 */
#content.bpbytes-content table.panelContainer.edit td.bpbytes-checkbox-label-cell {
    text-align: right;
    vertical-align: middle;
    padding-top: 10px;
    padding-right: 0;
}

#content.bpbytes-content table.panelContainer.edit td.bpbytes-checkbox-value-cell {
    color: var(--bp-text-muted);
    font-weight: 600;
    vertical-align: middle;
}

/*
 * Radioenum/checkbox-group fields (include/SugarFields/Fields/Radioenum/EditView.tpl, and any
 * other field using Smarty's {html_radios}/{html_checkboxes}) render each option as
 * "<label><input type=radio/checkbox />Option text</label>" with NO separator (this app's
 * radioenum fields never set vardef.separator) and no space between the input and the text -
 * so with nothing else forcing layout, all of a group's options ran together inline with zero
 * gap between the control and its own text, AND between one option and the next - on a row
 * where the label column's own text also wrapped onto 2 lines (a long question), that wrapped
 * second line and the value column's run-together options ended up at the same vertical
 * position, reading as overlapping text. Making each option's own <label> a block-level flex
 * row - input first (already true in the markup; this only adds the missing visual gap),
 * text after - stacks every option on its own line unconditionally (not dependent on a
 * separator that may or may not be set) with clean, consistent spacing, matching the requested
 * "(control) Label" order for both radio and checkbox groups throughout the app.
 */
#content.bpbytes-content table.panelContainer.edit td:has(> label > input[type="radio"]),
#content.bpbytes-content table.panelContainer.edit td:has(> label > input[type="checkbox"]) {
    vertical-align: top;
    padding-top: 14px;
}

#content.bpbytes-content table.panelContainer.edit label:has(> input[type="radio"]),
#content.bpbytes-content table.panelContainer.edit label:has(> input[type="checkbox"]) {
    display: flex;
    align-items: flex-start;
    gap: 6px;
    margin: 0 0 8px;
    font-weight: 400;
    color: var(--bp-text);
    cursor: pointer;
}

#content.bpbytes-content table.panelContainer.edit label:has(> input[type="radio"]):last-child,
#content.bpbytes-content table.panelContainer.edit label:has(> input[type="checkbox"]):last-child {
    margin-bottom: 0;
}

#content.bpbytes-content table.panelContainer.edit label > input[type="radio"],
#content.bpbytes-content table.panelContainer.edit label > input[type="checkbox"] {
    flex: 0 0 auto;
    margin: 2px 0 0;
    accent-color: var(--bp-primary);
}

/*
 * Text-like inputs across all SugarField EditView widgets. width/max-width/box-sizing are load-
 * bearing, not cosmetic: core's own field templates hardcode intrinsic sizing (Textarea's
 * EditView.tpl sets cols="80"/rows, plain text inputs default to size="20" wide when no
 * explicit size is given) — sized in *characters*, not relative to the table cell they sit in.
 * With table.panelContainer.edit's value <td> otherwise unconstrained, a couple of wide
 * textareas in the same row was enough to blow the whole 4-column (label/value/label/value)
 * table past the container's width, clipping the entire second label/value pair off the right
 * edge of the screen instead of wrapping. Forcing every field to fill its own <td> instead of
 * its attribute-driven intrinsic size keeps the table's real width within the panel.
 */
#content.bpbytes-content input[type="text"],
#content.bpbytes-content input[type="password"],
#content.bpbytes-content input[type="email"],
#content.bpbytes-content input[type="number"],
#content.bpbytes-content textarea,
#content.bpbytes-content select {
    width: 100%;
    max-width: 100%;
    box-sizing: border-box;
    border: 1px solid var(--bp-border-strong);
    border-radius: var(--bp-radius);
    padding: 9px 14px;
    font-size: 14px;
    font-family: var(--bp-font);
    color: var(--bp-text);
    background: var(--bp-surface);
}

/*
 * Multienum fields (custom/js/multiple-select.min.js) hide the real <select> and draw their own
 * widget instead: a <div class="ms-parent" style="width: 89%"> that the plugin itself writes as
 * an INLINE style, not CSS. That's narrower than the plain single-select <select> right next to
 * it, which gets width:100% of its own <td> from the rule above - so a multi-select field (e.g.
 * "Nature of Injury") and a single-select field (e.g. "First Aid Given?") end up visibly
 * different widths even though their <td> cells are the same size. !important is required here
 * only because it's overriding an inline style, which normal CSS specificity can never win
 * against otherwise.
 */
#content.bpbytes-content .ms-parent {
    width: 100% !important;
}

#content.bpbytes-content input[type="text"]:focus,
#content.bpbytes-content input[type="password"]:focus,
#content.bpbytes-content input[type="email"]:focus,
#content.bpbytes-content input[type="number"]:focus,
#content.bpbytes-content textarea:focus,
#content.bpbytes-content select:focus {
    border-color: var(--bp-primary);
    outline: none;
    box-shadow: 0 0 0 3px var(--bp-primary-soft);
}

/*
 * Datetimecombo (include/SugarFields/Fields/Datetimecombo/EditView.tpl) packs several small
 * controls — the date text input plus, built by its own JS into #..._time_section, separate
 * hour/minute/meridian <select> elements — side by side inside one field cell via its own
 * <table class="dateTime"><td class="dateTimeComboColumn">. The width:100% rule above is right
 * for a field that's the only control in its cell, but applied here it would stretch each of
 * these small controls to fill the whole row. table-layout:fixed caps every value column to a
 * hard-ceiling declared width regardless of content, so these composite sub-controls need fixed,
 * small per-control widths of their own rather than filling their shared cell.
 */
#content.bpbytes-content table.dateTime input,
#content.bpbytes-content table.dateTime select,
#content.bpbytes-content .datetimecombo_time_section input,
#content.bpbytes-content .datetimecombo_time_section select {
    max-width: none;
}

#content.bpbytes-content table.dateTime input.datetimecombo_date {
    display: inline-block;
    width: 100px !important;
    max-width: 100px !important;
    box-sizing: border-box;
    vertical-align: middle;
}

#content.bpbytes-content table.dateTime {
    display: inline-table;
    vertical-align: middle;
    white-space: nowrap;
}

#content.bpbytes-content table.dateTime td.dateTimeComboColumn {
    display: table-cell;
    white-space: nowrap !important;
    vertical-align: middle;
}

#content.bpbytes-content table.dateTime td.dateTimeComboColumn:first-child {
    width: 136px;
    min-width: 136px;
}

#content.bpbytes-content table.dateTime .datetimecombo_date_group {
    display: inline-flex;
    align-items: center;
    gap: 6px;
    white-space: nowrap;
}

#content.bpbytes-content table.dateTime .datetimecombo_time_section,
#content.bpbytes-content table.dateTime .datetimecombo_time_section > span {
    display: inline-flex;
    align-items: center;
    white-space: nowrap;
}

#content.bpbytes-content table.dateTime button[id$="_trigger"] {
    display: inline-flex;
    vertical-align: middle;
    margin: 0;
}

/*
 * 50px, not the generic select's 62px, with tighter padding to match: at this width the shared
 * select rule's chevron padding (32px right, sized/positioned for a normal full-width dropdown)
 * would eat almost the entire box, leaving no room for "04"/"15"/"PM". A smaller chevron pulled
 * in closer to the edge keeps these three legible while still shrinking the widget's total
 * footprint - the actual goal, since this composite field's combined width (date + calendar
 * button + 3 of these selects) is what was making its whole column wider than the plain-dropdown
 * column beside it.
 */
#content.bpbytes-content .datetimecombo_time_section select {
    width: 50px;
    padding-left: 6px;
    padding-right: 16px;
    background-position: right 3px center;
    background-size: 9px;
}

/*
 * table.panelContainer.edit td's 10px/20px padding (above) is a descendant selector, so it also
 * lands on table.dateTime's own <td class="dateTimeComboColumn"> cells nested inside it — 20px
 * left AND right on EACH of the two cells (date+calendar, then hour/minute/meridian) adds up to
 * a 40px gap between them, far more than the widget was designed for. Repeating
 * panelContainer.edit in the selector (matching the actual ancestor) is required to outrank
 * that rule's own specificity so padding:0 here actually takes effect.
 */
#content.bpbytes-content table.panelContainer.edit table.dateTime td {
    padding: 0;
}

/* Native <select> keeps whatever OS-default dropdown chrome it has by default, which looks
   inconsistent next to text inputs and next to relate-field combo widgets that draw their own
   arrow — replacing it with the same custom chevron used throughout the theme makes every plain
   dropdown look the same regardless of browser/OS. */
#content.bpbytes-content select {
    appearance: none;
    -webkit-appearance: none;
    -moz-appearance: none;
    padding-right: 32px;
    background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='none' stroke='%235b667a' stroke-width='2.5' stroke-linecap='round' stroke-linejoin='round'%3E%3Cpolyline points='6 9 12 15 18 9'/%3E%3C/svg%3E");
    background-repeat: no-repeat;
    background-position: right 10px center;
    background-size: 12px;
    cursor: pointer;
}

/* Text fields and dropdowns share the 40px control height of the relate (search) fields. */
#content.bpbytes-content input[type="text"],
#content.bpbytes-content input[type="password"],
#content.bpbytes-content input[type="email"],
#content.bpbytes-content input[type="number"],
#content.bpbytes-content select {
    min-height: var(--bp-control-h);
}

/* The relate (search) fields use the same chevron as the dropdowns instead of the plugin's solid triangle. */
#content.bpbytes-content .ms-parent .ms-choice > div.icon-caret,
#content.bpbytes-content .ms-parent .ms-choice > div.icon-caret.open {
    border: 0;
    margin-top: 0;
    top: 0;
    right: 0;
    width: 32px;
    height: 100%;
    background: var(--bp-chevron) no-repeat right 10px center / 12px;
}

#content.bpbytes-content table.panelContainer.edit textarea {
    min-height: 88px;
}

/* Datetime/Date/Datetimecombo's calendar-trigger button (include/SugarFields/Fields/
   Datetimecombo/EditView.tpl) hardcodes Bootstrap's class="btn btn-danger" — a bright red
   button with no relation to the theme at all. Scoped to the button's own id$="_trigger"
   suffix (set consistently by every date-family field) so a genuine, unrelated "danger" button
   elsewhere (e.g. a real delete action) is never touched by this override. */
#content.bpbytes-content button[id$="_trigger"].btn-danger {
    background: var(--bp-surface);
    border: 1px solid var(--bp-border-strong);
    color: var(--bp-text-muted);
    border-radius: var(--bp-radius-sm);
    height: 28px;
    width: 28px;
    padding: 0;
    display: inline-flex;
    align-items: center;
    justify-content: center;
    box-shadow: none;
}

#content.bpbytes-content button[id$="_trigger"].btn-danger:hover {
    background: var(--bp-surface-alt);
    color: var(--bp-primary);
    border-color: var(--bp-primary);
}

/* span.dateTime is also used, unrelated, by modules/Calendar/tpls/header.tpl for its
   goto-date icon (no input.date_input inside) - :has() keeps this scoped to the EditView
   date field markup above so the calendar toolbar's icon placement isn't disturbed. */
#content.bpbytes-content span.dateTime:has(input.date_input) {
    display: flex;
    align-items: center;
    gap: 6px;
    width: 100%;
    white-space: nowrap;
}

#content.bpbytes-content span.dateTime:has(input.date_input) input.date_input {
    display: inline-block;
    flex: 1 1 auto;
    width: auto !important;
    max-width: none !important;
    min-width: 0;
    box-sizing: border-box;
}

#content.bpbytes-content span.dateTime:has(input.date_input) button[id$="_trigger"] {
    flex: 0 0 auto;
    margin: 0;
}

#content.bpbytes-content .edit-view-field-shim,
#content.bpbytes-content table.panelContainer.edit input[type="checkbox"] {
    accent-color: var(--bp-primary);
    width: 15px;
    height: 15px;
}

/*
 * The email address widget (include/SugarEmailAddress/templates/forEditView.tpl) splits each
 * line 50/50 between the address input and its primary/opt-out/invalid flags via Bootstrap's
 * col-sm-6 - a viewport-width breakpoint, not a container-width one. It always fires at normal
 * desktop widths regardless of how narrow the EditView value <td> actually is, so the <input
 * type="email"> (already width:100% of its own immediate parent, from the shared text-input rule
 * above) only ever fills half of that already-narrow cell - unlike every other field's input/
 * select, which fills the whole thing. Stacking the two halves full-width instead of side-by-side
 * is what actually gives the input the same "fills the cell" length as the rest of the form; the
 * flags just move to their own row underneath rather than being squeezed into the other half.
 */
#content.bpbytes-content .email-address-input-container,
#content.bpbytes-content .email-address-options-container {
    float: none;
    width: 100%;
    max-width: 100%;
}

#content.bpbytes-content .email-address-options-container {
    margin-top: 8px;
}

/*
 * add_error_style() (include/javascript/sugar_3.js) reacts to a failed validate_form() check by
 * appending <div class="required validation-message">Invalid Value: ...</div> as another child
 * of the invalid field's own parentNode - for a plain field that's just its <td>, so the message
 * (a block-level div) already falls onto its own line below with no help needed. The email
 * widget's parentNode is Bootstrap's .input-group instead (display:table, so it can lay the
 * address input and its remove button out side by side) - and per the CSS table spec, a
 * display:table parent forces even a display:block child into an anonymous table-cell in that
 * SAME row, no matter what display the child itself asks for. That's what squeezed the address
 * input down to make room for the message next to it instead of below it. position:absolute
 * removes the message from table layout entirely (out-of-flow boxes are exempt from the
 * anonymous-table-object fixup), so the input keeps the full row to itself and the message
 * still lands directly under it - .input-group is already position:relative (Bootstrap), so
 * that's what it's positioned against.
 */
#content.bpbytes-content .input-group .validation-message {
    position: absolute;
    top: 100%;
    left: 0;
    display: block;
    width: 100%;
    margin-top: 4px;
}

/*
 * Taking the message out of flow (above) means nothing after it in NORMAL flow knows it's
 * there any more - on the email widget specifically, that's .email-address-options-container
 * (the Primary/Opt Out/Invalid flags), sitting immediately below with no gap of its own to
 * absorb it, so the message and the flags' own labels landed right on top of each other.
 * Reserving space for it on the line-container ahead of time (rather than trying to measure
 * the message's actual rendered height) is the same trade-off the rest of this file already
 * makes for a field with no fixed content size - one line's worth is enough for this message
 * in every language string it's actually built from (ERR_INVALID_VALUE + a field label).
 */
#content.bpbytes-content .email-address-input-container:has(.validation-message) {
    padding-bottom: 24px;
}

/* ---- Control proportions shared with the login page: 40px tall, 12px corners, 14px text ---- */

/* The multiple-select plugin's drop-down widget (custom/css/multiple-select.css draws it square) */
#content.bpbytes-content .ms-parent .ms-choice {
    height: var(--bp-control-h);
    line-height: calc(var(--bp-control-h) - 2px);
    border: 1px solid var(--bp-border-strong);
    border-radius: var(--bp-radius);
    background: var(--bp-surface);
    color: var(--bp-text);
    font-size: 14px;
    padding-left: 14px;
}

#content.bpbytes-content .ms-parent .ms-choice > span {
    color: var(--bp-text);
}

#content.bpbytes-content .ms-parent .ms-choice:focus,
#content.bpbytes-content .ms-parent.ms-open .ms-choice {
    border-color: var(--bp-primary);
    box-shadow: 0 0 0 3px var(--bp-primary-soft);
    outline: none;
}

#content.bpbytes-content .ms-drop {
    border: 1px solid var(--bp-border-strong);
    border-radius: var(--bp-radius);
    box-shadow: var(--bp-shadow-lg);
    font-size: 14px;
    overflow: hidden;
}

/* Date + time fields share one row, so their inner boxes stay compact */
#content.bpbytes-content table.dateTime input.datetimecombo_date {
    padding: 9px 6px 9px 10px;
    font-size: 13px;
}

#content.bpbytes-content select.datetimecombo_time {
    width: 46px;
    min-width: 46px;
    padding: 9px 12px 9px 6px;
    background-position: right 4px center;
    background-size: 9px;
    font-size: 13px;
}

/* Short text fields (size="1" to "5", e.g. a crontab value) keep room for what they show. */
#content.bpbytes-content input[type="text"][size="1"],
#content.bpbytes-content input[type="text"][size="2"],
#content.bpbytes-content input[type="text"][size="3"],
#content.bpbytes-content input[type="text"][size="4"],
#content.bpbytes-content input[type="text"][size="5"] {
    min-width: 72px;
}

/*
 * Line-item panels (Advanced OpenWorkflow Conditions and Actions). Each line is a table nested
 * inside a panelContainer.edit cell. The generic rules above - 10px/20px cell padding and
 * width:100% on every select - are meant for a label/value grid; inside an auto-layout nested
 * table the percentage widths and wide padding resolve against shrink-to-fit cells, so every
 * select collapsed to a few characters and the email recipient row stacked into a 92px column.
 * These tables get the full width of their cell, tighter padding, and selects that keep a
 * readable minimum width.
 */
#content.bpbytes-content table.panelContainer.edit table#aow_conditionLines,
#content.bpbytes-content table.panelContainer.edit table#actionLines,
#content.bpbytes-content table.panelContainer.edit table.action-table,
#content.bpbytes-content table.panelContainer.edit table.lines,
#content.bpbytes-content table.panelContainer.edit table.relationship,
#content.bpbytes-content table.panelContainer.edit table.email-line {
    width: 100%;
    border-collapse: collapse;
}

#content.bpbytes-content table.panelContainer.edit table#aow_conditionLines td,
#content.bpbytes-content table.panelContainer.edit table#actionLines td {
    padding: 6px 8px;
}

#content.bpbytes-content table.panelContainer.edit table#aow_conditionLines thead td {
    padding-top: 0;
    color: var(--bp-text-muted) !important;
    font-weight: 600;
}

#content.bpbytes-content table.panelContainer.edit table#aow_conditionLines td > select,
#content.bpbytes-content table.panelContainer.edit table#aow_conditionLines td > input[type="text"],
#content.bpbytes-content table.panelContainer.edit table#actionLines table.lines td select,
#content.bpbytes-content table.panelContainer.edit table#actionLines table.relationship td select {
    min-width: 140px;
}

/* A recipient line is delete button + type + target + value on one row. */
#content.bpbytes-content table.panelContainer.edit table.email-line td {
    display: flex;
    align-items: center;
    gap: 8px;
    padding: 6px 0;
}

#content.bpbytes-content table.panelContainer.edit table.email-line td > select,
#content.bpbytes-content table.panelContainer.edit table.email-line td > span {
    flex: 1 1 0;
    min-width: 0;
}

#content.bpbytes-content table.panelContainer.edit table.email-line td > select:first-of-type {
    flex: 0 0 90px;
}

/* Delete and add buttons use the theme's secondary button style. */
#content.bpbytes-content table.panelContainer.edit table.action-table .delete-btn a.btn-danger,
#content.bpbytes-content table.panelContainer.edit td > button[onclick^="add_emailLine"] {
    display: inline-flex;
    align-items: center;
    justify-content: center;
    min-width: var(--bp-btn-h);
    height: var(--bp-btn-h);
    padding: 0 12px;
    border: 1px solid var(--bp-border-strong);
    border-radius: var(--bp-radius);
    background: var(--bp-surface);
    color: var(--bp-text);
    cursor: pointer;
}

#content.bpbytes-content table.panelContainer.edit table.action-table .delete-btn a.btn-danger:hover {
    border-color: var(--bp-danger, #d92d20);
    color: var(--bp-danger, #d92d20);
}

#content.bpbytes-content table.panelContainer.edit td > button[onclick^="add_emailLine"] img {
    display: none;
}

#content.bpbytes-content table.panelContainer.edit td > button[onclick^="add_emailLine"]::before {
    content: "+";
    font-size: 18px;
    line-height: 1;
}

/* Name / Select Action / delete sit on one row. */
#content.bpbytes-content table.panelContainer.edit table.action-table > tbody > tr:first-child > td[field="delete"] {
    width: 1%;
    vertical-align: bottom;
}

/* Per-action parameter tables (e.g. Send Email) mix rows of different cell counts, so a table
   grid sizes them badly; lay each row out as a flex line instead - labels at their natural
   width, the value cell taking the rest. */
#content.bpbytes-content table.panelContainer.edit table[data-workflow-action] > tbody > tr {
    display: flex;
    align-items: flex-start;
    gap: 12px;
}

#content.bpbytes-content table.panelContainer.edit table[data-workflow-action] > tbody > tr > td {
    flex: 0 0 auto;
    padding: 6px 0;
}

#content.bpbytes-content table.panelContainer.edit table[data-workflow-action] > tbody > tr > td:last-child {
    flex: 1 1 0;
    min-width: 0;
}

#content.bpbytes-content table.panelContainer.edit table[data-workflow-action] > tbody > tr > td > button[onclick^="add_emailLine"] {
    margin-bottom: 6px;
}

#content.bpbytes-content table.panelContainer.edit table[data-workflow-action] > tbody > tr > td:last-child {
    text-align: left;
}

#content.bpbytes-content table.panelContainer.edit table[data-workflow-action] > tbody > tr > td > select {
    width: 100%;
    min-width: 0;
    max-width: 360px;
}

/* Nested parameter tables reuse the "_label" ids, which the generic 240px label column rule
   would otherwise size. */
#content.bpbytes-content table.panelContainer.edit table[data-workflow-action] td[id$="_label"] {
    width: auto;
    max-width: none;
    padding-top: 6px;
    white-space: nowrap;
}