/*!
 * JVN Core - front-end stylesheet
 * Part of the JVN Workshops plugin. Enqueued by JVNW_Assets.
 *
 * ---------------------------------------------------------------------------
 * WHY THIS FILE EXISTS, 1.8.2
 * ---------------------------------------------------------------------------
 * Until 1.8.2 every rule below was returned as a <style> block from the
 * function that drew the markup it styled, and so was printed inside <body>,
 * once per form. Measured on the live site, 1 August 2026:
 *
 *     11,806 B   the opt-in block          printed once PER FORM
 *      2,209 B   the popup block
 *        759 B   the consent bar block
 *     10,468 B   the workshop form block
 *
 * On /contact/, which draws three opt-in forms, that came to 38,386 B of
 * inline CSS, 23,612 B of which was the same block repeated. Brotli
 * compresses the repetition almost perfectly - printing the block once per
 * page rather than once per form would have saved 27 bytes on /contact/ - so
 * de-duplication was never the point and is not claimed as a benefit here.
 * The point is that a stylesheet is fetched once and then cached for the
 * whole site, while an inline block is re-sent with every document. Removing
 * it from the HTML measured:
 *
 *     home     brotli 80,603 -> 76,644   -3,959 B  (4.9% of the document)
 *     post     brotli 71,000 -> 66,930   -4,070 B  (5.7%)
 *     contact  brotli 49,040 -> 44,962   -4,078 B  (8.3%)
 *
 * ---------------------------------------------------------------------------
 * IT IS ENQUEUED SITEWIDE AND UNCONDITIONALLY. THIS IS DELIBERATE.
 * ---------------------------------------------------------------------------
 * JVNW_Optin::css() used to carry a docblock arguing the opposite: that a
 * wp_enqueue_style() needs a hook, the hook needs to know whether the page has
 * a form on it, and the only cheap test - has_shortcode( $post->post_content )
 * - is false for every one of these forms, because they live in the footer, in
 * popups and in page-builder blocks rather than in post content. That argument
 * was correct about the mechanism and is answered by not attempting it. There
 * is no condition. The handle is registered on every page.
 *
 * The reason is Hummingbird. Asset Optimization combines stylesheets into a
 * bundle keyed by the set of handles on the page, so a conditional enqueue
 * produces a different bundle per page type. This site has lost CSS combining
 * twice from bundle churn. A uniform handle set is worth more than the ~4 KB
 * saved by omitting this file from a page that has no form on it.
 *
 * AFTER CHANGING THIS FILE OR ITS VERSION: re-scan Site Files in Hummingbird's
 * Asset Optimization, or posts will serve 25-30 uncombined stylesheets.
 *
 * ---------------------------------------------------------------------------
 * ORDER WITHIN THIS FILE IS LOAD-BEARING. DO NOT SORT IT.
 * ---------------------------------------------------------------------------
 * Two orderings matter and both are easy to destroy with a tidy-up:
 *
 * 1. THE OPT-IN SECTION COMES LAST. The workshop-form section carries bare
 *    .jvnw-form, .jvnw-check and .jvnw-note rules, and opt-in markup uses the
 *    same classes. Several pairs tie on specificity - .jvnw-form label and
 *    .jvnw-optin label are both (0,1,1) - so source order is what decides
 *    them, and the opt-in rule has to win. This is not a new arrangement: on
 *    any workshop page the footer newsletter form already resolved this way,
 *    because the workshop block was printed in the content and the opt-in
 *    block in the footer after it. The file reproduces the cascade that has
 *    been in production since 1.6.x rather than inventing one.
 *
 * 2. INSIDE THE OPT-IN SECTION, the .light / .jvnw-text-light override of
 *    .jvnw-note opacity must stay after the plain .jvnw-note rule it
 *    overrides. It is a same-specificity override and nothing but order
 *    carries it.
 *
 * ---------------------------------------------------------------------------
 * THIS FILE NOW LOSES TO ANY STYLESHEET PRINTED AFTER IT.
 * ---------------------------------------------------------------------------
 * As inline <body> blocks these rules were the last CSS in the document and
 * won every tie by default. They no longer are. JVNW_Assets enqueues at
 * priority 100 on wp_enqueue_scripts so the file still prints after the
 * theme's stylesheets, but that is a convention, not a guarantee. Every rule
 * here that has to beat the theme does so on specificity or !important, which
 * is why the selectors are as long as they are. Do not shorten one on the
 * grounds that it "obviously" wins.
 *
 * The one that concretely changed hands is worth naming. The JVN Performance
 * plugin prints <style id="jvn-extra-css"> at wp_head priority 102 - measured
 * on /contact/, 2 August 2026, 12,961 B. It carries one enormous grouped
 * selector whose members include, character for character:
 *
 *     .jvnw-optin .jvnw-form p.jvnw-submit button.jvnw-btn:not(.jvnw-btn-theme)
 *     .jvnw-pop-cta a.jvnw-btn
 *     .jvnw-pop-sub
 *
 * declaring font-family:"Open Sans","Open Sans Caps Fallback",sans-serif
 * !important. A grouped selector's specificity is computed per member, so the
 * first of those is (0,5,2) - a dead tie with the opt-in rule in section 4,
 * both !important. This file prints from wp_print_styles, long before priority
 * 102, so from 1.8.2 the Performance rule wins that tie on order. Before 1.8.2
 * the opt-in block was in <body>, after it, and won - which is exactly why the
 * contact form's submit button was the only uppercase element on the site
 * still drawn with lowercase-tuned metrics.
 *
 * The tie has also been removed outright: section 4's rule no longer declares
 * font-family at all. Both halves were done deliberately, so the outcome does
 * not depend on which stylesheet lands second. font-family was the ONLY
 * property those two rules had in common - checked declaration by declaration
 * against the live block, not assumed - so nothing else changed hands.
 */

/* =========================================================================
 * 1. CONSENT BAR  (was JVNW_Consent::css)
 * ========================================================================= */

/*
 * Like-for-like with Branda: a bottom strip, #000 on #fff text, 5px radius.
 *
 * position:fixed with a z-index below the popup's, because the two can be on
 * screen together and the popup is the one the visitor is being asked to act
 * on. Nothing here uses a viewport unit or a transform: this element is
 * painted on first load on every page, and a cookie bar that animates in is
 * a cookie bar that contributes to Cumulative Layout Shift on the visit
 * Google measures.
 *
 * 1.8.2: measured again after the move to this stylesheet - fixed positioning
 * contributes zero CLS and the element must stay out of flow. Do not "tidy"
 * it into the document by making it static or sticky.
 */
#jvnw-consent{position:fixed;left:0;right:0;bottom:0;z-index:9998;background:#000;color:#fff;font-size:14px;line-height:1.5;padding:12px 16px;box-sizing:border-box}
#jvnw-consent .jvnw-consent-in{display:flex;align-items:center;justify-content:center;gap:16px;flex-wrap:wrap;max-width:1100px;margin:0 auto}
#jvnw-consent .jvnw-consent-msg{flex:1 1 320px}
#jvnw-consent a{color:#fff;text-decoration:underline}
#jvnw-consent .jvnw-consent-x{flex:0 0 auto;background:#fff;color:#000;border:0;border-radius:5px;padding:8px 18px;font-size:14px;line-height:1.2;cursor:pointer;font-family:inherit}
#jvnw-consent .jvnw-consent-x:focus-visible{outline:2px solid #fff;outline-offset:2px}
#jvnw-consent img{position:absolute;width:1px;height:1px;opacity:0;pointer-events:none}

/* =========================================================================
 * 2. POPUP  (was JVNW_Popup::css)
 * ========================================================================= */

.jvnw-pop[hidden]{display:none}
/*
 * 1.6.7. The other half of lock() in the popup script.
 *
 * padding-right replaces the scrollbar the overflow rule just took away, so
 * the page underneath does not jump sideways when the popup opens. The width
 * is measured in JS and arrives as the custom property; the 0px fallback is
 * what phones get, where the scrollbar is drawn over the content and takes up
 * no room to begin with.
 *
 * The selector is html.jvnw-pop-lock rather than the bare class, so it
 * outranks any plain html{} or body{} overflow rule the theme ships. Until
 * 1.8.2 this rule was printed in a <style> in the footer, after the theme's
 * stylesheets, so at equal specificity it would have won on order alone -
 * that is no longer true now the rule lives in an enqueued file, which is
 * exactly why the class was never the thing this leaned on. The popup
 * silently failing to lock the page was not a bug worth leaving to source
 * order then, and the move has not made it one.
 *
 * .jvnw-pop itself is position:fixed and so is measured against the viewport,
 * not against html - the padding moves the page behind the popup and never
 * the popup.
 */
html.jvnw-pop-lock{overflow:hidden;padding-right:var(--jvnw-pop-gut,0px)}
.jvnw-pop{position:fixed;inset:0;z-index:99999;display:flex;align-items:center;justify-content:center;padding:20px}
.jvnw-pop-bg{position:absolute;inset:0;background:rgba(0,0,0,.72)}
.jvnw-pop-box{position:relative;background:#fff;color:#222;max-width:860px;width:100%;max-height:90vh;overflow:auto;border-radius:4px;display:flex;flex-wrap:wrap}
.jvnw-pop-x{position:absolute;top:6px;right:10px;z-index:2;background:none;border:0;font-size:30px;line-height:1;cursor:pointer;color:#666;padding:4px 8px}
.jvnw-pop-x:hover{color:#000}
.jvnw-pop-img{flex:0 0 40%;min-width:220px}
.jvnw-pop-img img{display:block;width:100%;height:100%;object-fit:cover}
.jvnw-pop-txt{flex:1 1 320px;padding:32px 30px}
.jvnw-pop-sub{margin:0 0 6px;text-transform:uppercase;letter-spacing:.08em;font-size:12px;font-weight:700;color:#888}
.jvnw-pop-h{margin:0 0 14px;font-size:24px;line-height:1.25}
.jvnw-pop-body p{margin:0 0 12px;font-size:15px;line-height:1.55}
.jvnw-pop-cta{margin:16px 0 0}
/*
 * 1.6.5: the CTA had no rule of its own and rendered as an underlined text
 * link. The two .jvnw-btn rules in the plugin are both scoped away from here
 * - one is ".jvnw-form-wrap .jvnw-form p.jvnw-submit button.jvnw-btn", the
 * other ".jvnw-optin .jvnw-btn" - so a popup CTA matched neither and fell
 * through to the theme's default anchor. Same shape of bug as the honeypot
 * losing its display:none in 1.6.4: shared markup published across a module
 * boundary, its styling left behind in the module that defined it.
 *
 * The values match the site's standard button, which the signup form already
 * draws correctly. display:inline-block rather than the form's full-width
 * block: this is a call to action sitting in flowing text, not a form submit
 * that should span the field column.
 *
 * Kept scoped to .jvnw-pop-cta rather than widened to a shared .jvnw-btn
 * base. A base rule would have prevented both bugs, but it would also reach
 * the opt-in buttons that deliberately carry the theme's own Nectar classes
 * (see jvnw-btn-theme), and half-theme half-plugin is precisely what that
 * exclusion exists to stop.
 */
.jvnw-pop-cta a.jvnw-btn{display:inline-block;background:#000;color:#fff;border:0;border-radius:200px;padding:15px 35px;font-size:14px;line-height:20px;font-weight:600;font-family:inherit;text-transform:uppercase;letter-spacing:normal;text-decoration:none;text-align:center;cursor:pointer}
.jvnw-pop-cta a.jvnw-btn:hover,.jvnw-pop-cta a.jvnw-btn:focus{background:#222;color:#fff;text-decoration:none}
.jvnw-pop-never{margin:14px 0 0}
.jvnw-pop-never a{font-size:12px;color:#999;text-decoration:underline}
.jvnw-pop-whole{cursor:pointer}
/*
 * 1.6.6: the preview strip. flex-basis:100% because the box is a wrapping
 * flex row - anything less and it would sit in the image column beside the
 * text.
 */
.jvnw-pop-preview{flex:0 0 100%;margin:0;padding:9px 42px 9px 14px;background:#fcf0e4;border-bottom:1px solid #dba617;font-size:12px;line-height:1.4;color:#3c434a;text-align:center}
/*
 * 1.6.6: centre the text and the buttons on mobile.
 *
 * Below 640px .jvnw-pop-img goes flex-basis:100% and the box stops being two
 * columns, so the text column becomes the full width of the popup with a wide
 * image above it. Left-aligned text under a full-width image has nothing to
 * align to, and the CTA - which is display:inline-block since 1.6.5 -
 * shrink-wraps to its label and ends up a small black pill stranded in the
 * bottom-left corner.
 *
 * Inside the existing query rather than a second breakpoint, so the text
 * centres at exactly the moment the layout stops being two columns. The same
 * rules outside the query would centre the desktop layout, where the text is
 * aligned to the edge of the picture beside it and centring it looks like a
 * mistake.
 *
 * .jvnw-pop-never is in the list because it is the one thing that would
 * otherwise be left hanging on the left under a centred block.
 *
 * The opt-in form inside the popup is centred too, on Jeroen's 30 July
 * instruction ("do everything centered"). Two of the three rules need more
 * than text-align to land:
 *
 *   - .jvnw-check is display:flex, and text-align does nothing to the
 *     position of a flex item. Without justify-content the checkbox would
 *     stay hard left and only the words beside it would move, which is the
 *     half-centred row that looks like a bug rather than a decision. The two
 *     properties go together or neither goes in.
 *   - .jvnw-submit only needs text-align because the button is inline-block.
 *     The button itself is untouched: making it display:block;width:100% is a
 *     different design and was not what was asked for.
 *
 * The input boxes themselves stay full-width and left-aligned - what is
 * centred is the label above a field, never the text somebody is typing
 * into it.
 *
 * Every rule here is prefixed .jvnw-pop-form, so the same form drawn
 * standalone on a page by [jvnw_optin] is untouched. That prefix is the whole
 * safety property: this is the third release in which a popup style has gone
 * wrong by reaching further than intended.
 */
@media(max-width:640px){
.jvnw-pop-img{flex-basis:100%;max-height:180px}
.jvnw-pop-txt{padding:24px 20px}
.jvnw-pop-h{font-size:20px}
.jvnw-pop-sub,.jvnw-pop-h,.jvnw-pop-body,.jvnw-pop-cta,.jvnw-pop-never{text-align:center}
.jvnw-pop-form label,.jvnw-pop-form legend,.jvnw-pop-form .jvnw-note,.jvnw-pop-form .jvnw-submit,.jvnw-pop-form .jvnw-banner{text-align:center}
.jvnw-pop-form .jvnw-check{justify-content:center;text-align:center}
}

/* =========================================================================
 * 3. WORKSHOP BOOKING AND WAITLIST FORM  (was JVNW_Form::css)
 *
 * Bare .jvnw-form / .jvnw-check / .jvnw-note / .jvnw-sr rules live here. They
 * now reach opt-in forms on pages that never drew a workshop form. That is a
 * real scope change and it was made on purpose - see notes/1.8.2-scope.md.
 * ========================================================================= */

/* One muted-grey token for the whole form. #767676 is the lightest grey
   that still clears WCAG AA 4.5:1 on white, so helper text under 18.66px
   passes; the literal is repeated as a var() fallback so the colour
   survives even if the custom property never lands. Matches the same
   token on the other JVN forms - change it here, not per rule. */
:root{--jvn-text-muted:#767676}
.jvnw-form-wrap{max-width:none}
.jvnw-form-wrap .jvnw-title{font-size:30px;font-weight:600;color:#333;margin:0 0 14px}
.jvnw-form-head{display:flex;align-items:center;gap:14px;flex-wrap:wrap;margin:0 0 14px}
.jvnw-form-head .jvnw-title{margin:0}
.jvnw-form-head .jvnw-avail-chip{margin:0}
.jvnw-hold-claim{margin-top:18px;border-top:1px solid #e6e6e6;padding-top:14px}
.jvnw-hold-claim summary{cursor:pointer;font-weight:600;color:#333;font-size:15px}
.jvnw-hold-claim summary:hover{color:#000}
.jvnw-hold-claim > details > .jvnw-note{margin:10px 0 0}
.jvnw-hold-claim .jvnw-title{font-size:22px}
.jvnw-avail-chip{display:inline-block;padding:5px 14px;border-radius:99px;font-size:13px;font-weight:700;letter-spacing:.02em;margin:0 0 20px}
.jvnw-avail-chip.ok{background:#edfaef;color:#00801c}
.jvnw-avail-chip.few{background:#fcf9e8;color:#996800}
.jvnw-avail-note{font-size:13px;color:#996800;margin:0 0 16px;font-weight:600}
@media(max-width:600px){.jvnw-form-head{flex-direction:column;align-items:flex-start;gap:8px}}
.jvnw-form p{margin:0 0 20px}
.jvnw-form label{display:block;font-weight:400;font-size:14px;color:#333;margin-bottom:7px}
/* The grouped questions are real fieldsets now (so the tree gives the
   group a name); these strip the browser default box back to the plain
   div they replaced, leaving the look unchanged. */
.jvnw-form fieldset{border:0;margin:0;padding:0;min-width:0}
.jvnw-form legend{display:block;padding:0;width:100%;max-width:100%;float:none}
.jvnw-form legend.jvnw-grouplabel{font-weight:400;font-size:14px;color:#333;margin-bottom:7px}
/* Requirement carried as text for screen readers; the red * beside it is
   decorative and aria-hidden. */
.jvnw-sr{position:absolute !important;width:1px;height:1px;padding:0;margin:-1px;overflow:hidden;clip:rect(0 0 0 0);white-space:nowrap;border:0}
.jvnw-status:empty{display:none}
/* Per-field errors (1.7.0). The span is in the markup on every render,
   empty until there is something to say - the association has to exist
   in the served HTML, not be conjured up by script on failure - so the
   :empty rule is what keeps an unsubmitted form looking untouched.
   The colour is not the message: the sentence itself is the message,
   and it is tied to the field by aria-describedby. */
/* It carries its own background rather than only a red, because these
   forms are dropped into sections whose colour the plugin does not
   choose - the home-page newsletter block sits on near-black - and a
   red picked to read on white is a red that vanishes on dark. A tinted
   panel reads on both, and matches the failure banner it summarises. */
.jvnw-fielderr{display:block;margin-top:6px;padding:8px 11px;border-radius:4px;background:#fdeeee;color:#a00;font-size:13px;line-height:1.45;font-weight:400}
.jvnw-fielderr:empty{display:none;padding:0;margin:0}
/* A rejected field is outlined as well as described, for everybody who
   can see it and is not reading the sentence yet. Driven off the ARIA
   state rather than a class, so what is drawn and what is announced
   cannot come apart. */
.jvnw-form [aria-invalid="true"]{border-color:#a3231d}
.jvnw-form input[type=text],.jvnw-form input[type=tel],.jvnw-form input[type=email],.jvnw-form select,.jvnw-form textarea{width:100%;padding:11px 12px;border:2px solid transparent;border-radius:4px;font-size:14px;box-sizing:border-box;background:rgba(0,0,0,.04);color:#555;font-family:inherit;line-height:1.5;-webkit-appearance:none;appearance:none}
.jvnw-form select{background-image:url("data:image/svg+xml;charset=US-ASCII,%3Csvg%20xmlns%3D%27http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%27%20viewBox%3D%270%200%2010%206%27%3E%3Cpath%20fill%3D%27%23555%27%20d%3D%27M0%200l5%206%205-6z%27%2F%3E%3C%2Fsvg%3E");background-repeat:no-repeat;background-position:right 14px center;background-size:10px;padding-right:34px}
.jvnw-form textarea{min-height:120px;line-height:1.5}
.jvnw-form input:focus,.jvnw-form select:focus,.jvnw-form textarea:focus{outline:none;border-color:#333;background:#fff}
.jvnw-hint{font-size:13px;color:var(--jvn-text-muted,#767676);display:block;margin-top:6px;font-weight:400}
/* Wrapper blocks need their own bottom margin: the theme zeroes the bottom
   margin of a last-child <p>, so a question ending in a wrapper div sat
   flush against the next label while plain <p> questions kept their 20px. */
.jvnw-form .jvnw-rooming{margin:0 0 20px}
.jvnw-form .jvnw-rooming > p{margin:0 0 6px}
.jvnw-form .jvnw-rooming > p.jvnw-hint{margin:6px 0 0}
.jvnw-form .jvnw-rooming > p:last-child{margin-bottom:0}
.jvnw-form .jvnw-extra-people{margin:0 0 20px}
.jvnw-form .jvnw-extra-people > p:last-child{margin-bottom:0}
.jvnw-form .jvnw-extra-person > p:last-child{margin-bottom:0}
.jvnw-form .jvnw-extra-person > legend{font-size:14px;color:#333}
.jvnw-phone-row{display:flex;gap:8px}
.jvnw-cc{flex:0 0 44%;max-width:240px}
.jvnw-phone{flex:1}
.jvnw-req{color:#b32d2e}
.jvnw-check label{font-weight:400;display:inline;font-size:14px;color:#555}
.jvnw-check input{margin-right:8px}
.jvnw-form .jvnw-interests{margin:0 0 20px}
.jvnw-form .jvnw-interests-legend{display:block;font-size:14px;color:#333;margin-bottom:12px}
.jvnw-optnote{color:var(--jvn-text-muted,#767676);font-weight:400}
.jvnw-form .jvnw-interest-group{margin:0 0 12px}
.jvnw-form .jvnw-interest-grouplabel{display:block;font-size:13px;color:var(--jvn-text-muted,#767676);font-weight:400;margin-bottom:7px}
.jvnw-form .jvnw-interest-opts{display:flex;flex-wrap:wrap;gap:8px}
/* A chip is a <label>, so ".jvnw-form label" above (0,2,1) outranked a
   bare ".jvnw-interest" (0,1,0) and forced display:block - which
   silently killed both the flex gap and align-items, leaving the box
   jammed against its text. Two changes keep that from recurring: the
   selector now carries .jvnw-form so inline-flex actually holds, and
   the spacing is a margin on the input rather than flex gap, so it
   survives even if some later rule wins the display battle again.
   margin:0 also stops "label{margin-bottom:7px}" leaking in - chip
   spacing belongs to the gap on .jvnw-interest-opts alone. */
.jvnw-form .jvnw-interest{display:inline-flex;align-items:center;margin:0;padding:7px 13px;border:1px solid rgba(0,0,0,.15);border-radius:99px;font-size:14px;color:#444;cursor:pointer;background:#fff;line-height:1.2}
.jvnw-form .jvnw-interest input{margin:0 7px 0 0;flex:0 0 auto;width:auto;vertical-align:middle}
.jvnw-form .jvnw-interest:has(input:checked){border-color:#333;background:#fff;color:#222;font-weight:600}
/* Locked interests keep the normal checked colours on purpose - they are
   not "unavailable", they are already applied, so dimming them would
   only cost contrast. Just the pointer says it is not clickable. */
.jvnw-form .jvnw-interest-locked{cursor:default}
/* The Everything box and its collapse. No JavaScript on purpose - a
   sibling rule off :checked paints the right state on first render,
   which a delayed inline script cannot, and leaves a no-JS visitor
   able to open the list again. The input is a real focusable control
   parked off-screen rather than display:none, because a hidden input
   is not reachable by keyboard and the label would be dead. */
.jvnw-form .jvnw-interests .jvnw-interest-allbox{position:absolute;opacity:0;width:1px;height:1px;margin:0}
.jvnw-form .jvnw-interest-all{margin:0 0 12px}
.jvnw-form .jvnw-interest-all::before{content:"";flex:0 0 auto;width:14px;height:14px;margin:0 7px 0 0;border:1px solid rgba(0,0,0,.45);border-radius:3px;background:#fff}
.jvnw-form .jvnw-interest-allbox:checked+.jvnw-interest-all{border-color:#333;color:#222;font-weight:600}
.jvnw-form .jvnw-interest-allbox:checked+.jvnw-interest-all::before{background:#333;border-color:#333}
/* Focus has to be drawn on the label, since the box itself is invisible. */
.jvnw-form .jvnw-interest-allbox:focus-visible+.jvnw-interest-all{outline:2px solid #333;outline-offset:2px}
.jvnw-form .jvnw-interests .jvnw-interest-allnote{display:none;font-size:13px;margin:0 0 12px}
.jvnw-form .jvnw-interest-allbox:checked~.jvnw-interest-allnote{display:block}
.jvnw-form .jvnw-interest-allbox:checked~.jvnw-interest-rest{display:none}
.jvnw-note{font-size:13px;color:var(--jvn-text-muted,#767676);margin:0 0 20px}
.jvnw-hp{display:none !important}
.jvnw-disclaimer{color:#555;font-size:15px;margin:0 0 24px;line-height:1.6}
.jvnw-disclaimer p{margin:0 0 10px}
.jvnw-form-wrap .jvnw-form p.jvnw-submit button.jvnw-btn{display:block !important;width:100% !important;max-width:100% !important;box-sizing:border-box !important;background:#000 !important;color:#fff !important;border:0 !important;border-radius:200px !important;padding:15px 35px !important;font-size:14px !important;line-height:20px !important;font-weight:600 !important;font-family:inherit !important;text-transform:uppercase !important;letter-spacing:normal !important;cursor:pointer !important;text-align:center !important;margin:14px 0 0 !important;min-width:0 !important;height:auto !important;-webkit-appearance:none !important;appearance:none !important}
.jvnw-form-wrap .jvnw-form p.jvnw-submit button.jvnw-btn:hover{background:#222 !important;color:#fff !important}
.jvnw-form p.jvnw-submit{text-align:center;margin-top:8px}
/* Two classes, not one: .jvnw-form label above is (0,1,1) and would
   otherwise win on color and margin-bottom, same trap as the chips. */
.jvnw-form .jvnw-roomopt{display:block;font-weight:400;font-size:14px;color:var(--jvn-text-muted,#767676);margin:6px 0}
.jvnw-form .jvnw-roomopt input{margin-right:8px}
.jvnw-banner{padding:14px 18px;border-radius:6px;margin-bottom:18px}
.jvnw-ok{background:#eef7ee;border:1px solid #9ac79a}
.jvnw-err{background:#fdecea;border:1px solid #e2a49f}

/* =========================================================================
 * 4. OPT-IN, NEWSLETTER, WEBINAR AND CONTACT FORMS  (was JVNW_Optin::css)
 *
 * LAST ON PURPOSE. See "ORDER WITHIN THIS FILE IS LOAD-BEARING" above.
 * ========================================================================= */

.jvnw-optin{max-width:none}
/*
 * WHERE THE COLOUR OF THIS FORM ACTUALLY COMES FROM, 1.8.0.
 *
 * The rules below inherit rather than name a colour, and that fix was
 * only half of one, because inheriting is only as good as what is
 * being inherited FROM. Measured on the live home page, every ancestor
 * of the footer newsletter form - form, wrapper, column, row, body -
 * computes to #333. The white text all around it is not inherited at
 * all: Salient paints it with `.light p`, `.light h1` and friends,
 * element selectors that this plugin's markup was never going to
 * match. So `color:inherit` walked all the way up a chain that was
 * dark at every step and landed on #333 - the same near-black the
 * named colour gave, arrived at more politely.
 *
 * Three things follow, and all three are here rather than in one
 * clever rule:
 *
 * 1. THE PARAGRAPH RULE HAS TO SET A COLOUR TOO. The field label is a
 *    <label> inside a <p>, and the site's own CSS has a bare
 *    `p{color:var(--jvn-text-muted)}` - which beats inheritance,
 *    because inheritance loses to any rule at all. The label was
 *    obediently inheriting #767676 from the paragraph above it. That
 *    is the one that looked "nearly readable" in the screenshots and
 *    sent this round the loop twice.
 *
 * 2. THE THEME'S OWN LIGHT-TEXT SIGNAL IS WORTH READING. Salient
 *    marks a light-text column with `.light`, which is a real,
 *    documented statement that everything inside it is on something
 *    dark. Honouring it costs one selector and makes the plugin right
 *    by default in every correctly-configured section.
 *
 * 3. AND IT STILL NEEDS AN OVERRIDE, because on this site the signal
 *    is wrong: the column holding the footer form is set to `dark`
 *    while the background image behind it is a sunset. Nothing in CSS
 *    can see a background image's brightness, so the last word is a
 *    per-form `text` key and a `text="light|dark"` shortcode
 *    attribute. See shortcode() for the resolution order.
 *
 * The INPUTS are deliberately left out of all of this - they draw
 * their own box and have to stay legible inside it.
 */
.jvnw-optin .jvnw-form p{margin:0 0 16px;color:inherit}
.light .jvnw-optin{color:var(--nectar-font-light-color,#fff)}
.jvnw-optin.jvnw-text-light{color:#fff}
.jvnw-optin.jvnw-text-dark{color:#333}
/*
 * color:inherit, not #333.
 *
 * These three rules used to name a colour, and on a light page that
 * was invisible good luck rather than a decision. The newsletter
 * block sits in a dark full-width section on the home page, where
 * Salient sets the section text to white and every heading and
 * paragraph around the form obeys - and the form did not, so the
 * field label, the required marker and the words next to the tick
 * box came out near-black on near-black and could not be read at all.
 *
 * Inheriting is not just the fix, it is the only thing that keeps
 * working: these forms are dropped into the footer, into popups, into
 * page-builder rows and into whatever section colour the next one
 * uses, and the plugin cannot know which. The INPUTS keep an explicit
 * dark-on-white, because they draw their own white box and have to
 * stay legible inside it whatever the section around them is doing.
 */
.jvnw-optin label{display:block;font-weight:400;font-size:14px;color:inherit;margin-bottom:6px}
.jvnw-optin input[type=text],.jvnw-optin input[type=email],.jvnw-optin input[type=tel]{width:100%;padding:11px 13px;border:1px solid #d5d5d5;border-radius:4px;font-size:15px;background:#fff;color:#333}
.jvnw-optin input:focus{outline:2px solid #333;outline-offset:1px}
.jvnw-optin fieldset{border:0;margin:0 0 16px;padding:0;min-width:0}
.jvnw-optin legend{display:block;padding:0;width:100%;font-size:14px;color:inherit;margin-bottom:6px}
.jvnw-optin .jvnw-check{display:flex;align-items:flex-start;gap:9px;font-size:14px;color:inherit;font-weight:400;margin:0}
.jvnw-optin .jvnw-check input{margin-top:3px;flex:0 0 auto}
/*
 * THE TICKBOX ON A CENTRED FORM, 1.8.1.
 *
 * Reported on the drone webinar page and the volcano one: every
 * other line of the form is centred and the tickbox row sits hard
 * left. Nothing in this stylesheet centres anything - the page does,
 * with text-align:center on the column - and the rule above is the
 * reason the tickbox does not follow. A display:flex box is
 * block-level, so it fills the parent and lays its contents out at
 * flex-start; text-align is inherited but has nothing left to act
 * on. inline-flex makes the same box inline-level, so it shrinks to
 * its contents and the parent centres it like a word.
 *
 * text-align:left is not a contradiction: it governs the words
 * INSIDE the box, and a consent sentence that wraps should read as
 * a paragraph, not as centred poetry. max-width:100% is what stops
 * a long one overflowing the form now that it is shrink-to-fit.
 *
 * :only-of-type is the whole of the care here. Inline-level boxes
 * share a line when they fit, and a radio group - Yes/No,
 * Single/Twin - is several .jvnw-check labels as direct siblings
 * with nothing between them. Unconditional inline-flex would fold
 * those onto one line and call it a fix. Restricting it to the case
 * where the fieldset holds exactly one label means the single
 * consent tickbox this was reported about is centred, and every
 * group keeps stacking exactly as it did.
 */
.jvnw-optin fieldset .jvnw-check:only-of-type{display:inline-flex;max-width:100%;text-align:left}
.jvnw-optin textarea,.jvnw-optin select{width:100%;padding:11px 13px;border:1px solid #d5d5d5;border-radius:4px;font-size:15px;background:#fff;color:#333;font-family:inherit}
.jvnw-optin textarea{min-height:120px;resize:vertical}
.jvnw-optin textarea:focus,.jvnw-optin select:focus{outline:2px solid #333;outline-offset:1px}
.jvnw-optin .jvnw-extra-radio .jvnw-check{margin-bottom:8px}
.jvnw-optin .jvnw-notice{font-size:14px;line-height:1.5;margin:0 0 16px;padding:14px 16px;border-radius:4px;background:#f4f4f4;color:#333}
.jvnw-optin .jvnw-form .jvnw-notice p{margin:0}
.jvnw-optin .jvnw-notice a{color:inherit;text-decoration:underline}
.jvnw-optin [hidden]{display:none!important}
/*
 * The note goes the same way, by opacity rather than by a second
 * named colour. A fixed mid-grey is the classic thing that passes
 * contrast on the page it was designed against and fails on every
 * other one: #767676 is comfortably readable on white and about 2.9:1
 * on the dark home-page section, which is a fail. Inherit-and-fade
 * lands near the same grey on white and near a light grey on dark,
 * and cannot drift out of contrast when the section colour changes.
 */
.jvnw-optin .jvnw-form .jvnw-note{font-size:13px;color:inherit;opacity:.75;margin:18px 0 0}
/*
 * And lifted to .85 on a dark section only. The same grey-down that
 * reads as quiet small print on white is close to unreadable over a
 * photograph, which is the background this note is actually on.
 *
 * It sits HERE, directly under the rule it modifies, rather than up
 * with the other 1.8.0 colour rules. Two reasons, and the second is
 * the one that bit: an override belongs after what it overrides, and
 * optin-forms-164.php reads the first `.jvnw-note` rule in the sheet
 * to check the 18px gap under the tickbox - so a rule ending in the
 * same selector, placed earlier, is the one that test measures.
 */
.light .jvnw-optin .jvnw-form .jvnw-note,.jvnw-optin.jvnw-text-light .jvnw-form .jvnw-note{opacity:.85}
/*
 * The per-field error, 1.7.0. It carries its own background for the
 * same reason the banner does: it is the one string on the form that
 * has to be readable no matter what is behind it, and a red that
 * works on white is a red that disappears on the dark section.
 * :empty keeps it out of the layout entirely until it has something
 * to say - the span itself is always in the markup, because
 * aria-describedby has to point at a real element from first paint.
 */
.jvnw-optin .jvnw-fielderr{display:block;margin-top:6px;padding:8px 11px;border-radius:4px;background:#fdeeee;color:#a00;font-size:13px;line-height:1.45;font-weight:400}
.jvnw-optin .jvnw-fielderr:empty{display:none;padding:0;margin:0}
.jvnw-optin [aria-invalid="true"]{border-color:#a00}
.jvnw-optin .jvnw-note a{color:inherit;text-decoration:underline}
.jvnw-optin .jvnw-form .jvnw-submit{margin:0;text-align:center}
.jvnw-optin .jvnw-btn{cursor:pointer}
.jvnw-optin .jvnw-form p.jvnw-submit button.jvnw-btn:not(.jvnw-btn-theme){display:block !important;width:100% !important;max-width:100% !important;box-sizing:border-box !important;background:#000 !important;color:#fff !important;border:0 !important;border-radius:200px !important;padding:15px 35px !important;font-size:14px !important;line-height:20px !important;font-weight:600 !important;text-transform:uppercase !important;letter-spacing:normal !important;cursor:pointer !important;text-align:center !important;margin:0 !important;min-width:0 !important;height:auto !important;-webkit-appearance:none !important;appearance:none !important}
.jvnw-optin .jvnw-form p.jvnw-submit button.jvnw-btn:not(.jvnw-btn-theme):hover{background:#222 !important;color:#fff !important}
/*
 * THE THEMED BUTTON, 1.8.1. Full width, and a hairline of white.
 *
 * The rule above deliberately excludes the three forms that carry a
 * real Nectar class list - newsletter-footer, newsletter-popup and
 * ebook - because it repaints a button from background to letter
 * spacing and doing that to a theme button breaks what works. That
 * guard is still right and is not being dropped. What follows is a
 * different, much smaller rule: it sets layout and one border and
 * touches nothing else, so background, colour, radius, padding and
 * type all still come from Salient.
 *
 * Full width because everything above it already is. The inputs are
 * width:100%, the plain button is width:100%, and the footer form
 * was the one place where the button stopped short and left the
 * column looking ragged. This is the form agreeing with itself
 * rather than a new opinion about buttons.
 *
 * The border is 1px at a quarter opacity, which is chosen to be
 * nearly nothing. The footer form sits on a sunset photograph, and
 * a solid white outline there would read as a second, brighter
 * button; a hairline just separates the fill from the picture. At
 * 25% it also survives on a light background without becoming a box
 * around nothing, which is what the popup and the ebook form get.
 * box-sizing keeps the border inside the 100%, and the hover rule
 * exists only so the theme cannot take the border away again.
 */
.jvnw-optin .jvnw-form p.jvnw-submit button.jvnw-btn-theme{display:block !important;width:100% !important;max-width:100% !important;box-sizing:border-box !important;border:1px solid rgba(255,255,255,.25) !important}
.jvnw-optin .jvnw-form p.jvnw-submit button.jvnw-btn-theme:hover{border-color:rgba(255,255,255,.4) !important}
.jvnw-optin .jvnw-banner{padding:14px 16px;border-radius:4px;margin:0 0 16px;font-size:15px;line-height:1.5}
.jvnw-optin .jvnw-banner p{margin:0}
.jvnw-optin .jvnw-banner.jvnw-ok{background:#edfaef;color:#00801c}
.jvnw-optin .jvnw-banner.jvnw-err{background:#fdeeee;color:#a00}
