/*
 * ROAR Training Solutions — hand-written layout rules.
 *
 * This file is for the small number of rules the generated utilities cannot express, because
 * they depend on how MUCH content an element has rather than on which classes it carries.
 * Everything else belongs in utilities.css (generated from the static build by
 * build/make-utilities-css.js) or in Bricks' own theme styles and global classes.
 *
 * Keep it small. A rule here is a rule that is not visible in the builder, so each one needs
 * to earn its place and say why it exists.
 */

/*
 * The course hero's stat strip, when a course has three stats instead of four.
 *
 * ROAR's 2026-08-21 review removed the fourth stat from four courses — Arc Flash ("Support"),
 * Hazardous Areas Awareness ("Best for"), Electrical Testing Safety and Isolation & Lockout
 * (both "Extra: Optional practical assessment"). The strip is a fixed four-column grid, so
 * those pages rendered three bordered panels and a quarter of empty space, which reads as a
 * panel that failed to load rather than as a course with three stats.
 *
 * Matching on the child count rather than adding a class keeps this correct by itself: give a
 * course its fourth stat back in the WordPress editor and the strip returns to four columns
 * with nothing to remember.
 *
 * Only above the large breakpoint. Below it the grid is already one or two columns, where an
 * odd number of items is normal and needs no help.
 */
@media (min-width: 1024px) {
	#brxe-swafca:has(> :nth-child(3):last-child) {
		grid-template-columns: repeat(3, minmax(0, 1fr));
	}
}

/*
 * `self-start` is written into the archive sidebar's markup (roar_course_sidebar_shortcode())
 * but Tailwind never generated it: the static build never used the class, and the utilities are
 * compiled from that build. Needed for the rule below to have any effect — see there for why.
 *
 * Moved here 2026-08-25 from assets/css/fonts.css, which is regenerated by build/fetch-fonts.js
 * and silently discards anything hand-written in it.
 */
.self-start {
	align-self: flex-start;
}

/*
 * The category rail gets its own scrollbar instead of pushing the page.
 *
 * `position: sticky` does nothing on an element that already fills its scroll container — the
 * rail is a flex child of the archive row, and a flex child stretches to the row's full height
 * by default. `self-start` (above) fixes that by letting the rail size to its own content, and
 * an earlier session left it there: at the time the rail held one nav — a heading, five buttons
 * and a prompt — which fit any screen it was shown on, so a second, inner scrollbar would only
 * ever have sat uselessly next to the page's own.
 *
 * Session 18 (2026-08-21) added a second nav below it, "Browse by Booking Type", roughly
 * doubling the content. On anything shorter than a tall desktop the rail now runs past the
 * bottom of the viewport — and because it is `sticky`, once it scrolls out of view at the top
 * there is no way to reach its own bottom (the "Contact Us" prompt) except scrolling the whole
 * page another screen down. Capping it to the viewport and scrolling inside it is what the
 * design specified from the start; it just was not needed until the rail had two navs in it.
 *
 * `top-24` (96px) is the rail's own sticky offset — see roar_course_sidebar_shortcode(). The
 * extra 24px keeps a breath of space at the bottom of the viewport rather than letting the rail
 * touch the very edge.
 */
#course-sidebar-rail {
	max-height: calc(100vh - 120px);
	overflow-y: auto;
}

/*
 * A themed scrollbar, not the OS default, for the one element on the site that scrolls inside
 * itself rather than the page. Thin, and coloured from the design tokens Bricks already defines
 * at :root, so it reads as part of the rail rather than a browser chrome element sitting on it.
 */
#course-sidebar-rail {
	scrollbar-width: thin;
	scrollbar-color: var( --roar-outline-variant ) transparent;
}

#course-sidebar-rail::-webkit-scrollbar {
	width: 6px;
}

#course-sidebar-rail::-webkit-scrollbar-track {
	background: transparent;
}

#course-sidebar-rail::-webkit-scrollbar-thumb {
	background-color: var( --roar-outline-variant );
	border-radius: 999px;
}

#course-sidebar-rail::-webkit-scrollbar-thumb:hover {
	background-color: var( --roar-primary );
}

/*
 * The newsletter consent checkbox.
 *
 * Bricks renders a checkbox field as <li><input><label>...</label></li>, and both halves inherit
 * styling meant for something else:
 *
 *   - the enquiry forms stretch their inputs to full width, so a checkbox rendered 111px wide
 *   - the option's <label> picks up the *field label* treatment (14px, uppercase, weight 600, in
 *     the peach accent), which shouts at exactly the moment consent should be quiet
 *
 * Consent must be legible and unmissable, but it is not a call to action and should not compete
 * with the submit button. This makes it read as an ordinary sentence beside an ordinary checkbox.
 *
 * Matching on `:has( input[type="checkbox"] )` rather than adding a class keeps it correct if the
 * field is ever moved, renamed or added to the other form — there is nothing to remember.
 */
.roar-enquiry-form li:has( input[type="checkbox"] ),
.roar-enquiry-modal-form li:has( input[type="checkbox"] ) {
	display: flex;
	align-items: flex-start;
	gap: var( --roar-space-xs );
}

/*
 * The `html:root` prefix is not decoration. fonts.css carries
 * `html:root .roar-enquiry-form .form-group input { width: 100% }` (0,3,2) to stretch text
 * inputs to the field width; without matching that escalation the checkbox stays 292px wide and
 * only the height below applies, which is worse than doing nothing.
 */
html:root .roar-enquiry-form .form-group input[type="checkbox"],
html:root .roar-enquiry-modal-form .form-group input[type="checkbox"] {
	flex: 0 0 auto;
	width: 16px;
	min-width: 16px;
	height: 16px;
	margin-top: .15em;
	accent-color: var( --roar-primary );
}

.roar-enquiry-form input[type="checkbox"] + label,
.roar-enquiry-modal-form input[type="checkbox"] + label {
	font-size: 13px;
	font-weight: 400;
	line-height: 1.45;
	letter-spacing: normal;
	text-transform: none;
	color: inherit;
	opacity: .8;
}

/*
 * The field label above the checkbox ("NEWSLETTER") is redundant — the option text beside the box
 * already says what ticking it means, and a shouted heading over a one-line opt-in is the bulk
 * this rule exists to remove. Hidden visually rather than deleted so screen readers still announce
 * the group, and so the label stays editable in the builder.
 */
.roar-enquiry-form .form-group:has( input[type="checkbox"] ) > label,
.roar-enquiry-modal-form .form-group:has( input[type="checkbox"] ) > label {
	position: absolute;
	width: 1px;
	height: 1px;
	padding: 0;
	margin: -1px;
	overflow: hidden;
	clip: rect( 0 0 0 0 );
	white-space: nowrap;
	border: 0;
}

/*
 * The consent field spans the modal's full width.
 *
 * The popup form is a two-column grid. `course`, `message` and the submit button span both columns
 * because their Bricks field width is set to 100%; the checkbox field's is not, so it took a single
 * 300px column and the opt-in sentence wrapped onto two lines.
 *
 * This is expressible in the builder (Fields > Newsletter > Width: 100%) and would normally belong
 * there rather than here. It is in CSS because the same field has now been rebuilt twice, and a
 * width that has to be remembered each time is a width that will be forgotten.
 */
html:root .roar-enquiry-modal-form .form-group:has( input[type="checkbox"] ) {
	grid-column: 1 / -1;
}

/*
 * Keep the popup's dim over the whole viewport.
 *
 * Bricks renders `.brx-popup-backdrop` as a child of the popup, and the popup is a fixed-position
 * scroll box (`inset: 32px 0 0 0`). Whenever the form is taller than that box — which it is once
 * the admin bar takes 32px, and will be on any short viewport — the popup scrolls internally and
 * the backdrop scrolls away with it, leaving the bottom of the page undimmed. The result reads as
 * a page that is half greyed out and half not, which looks like a rendering fault rather than a
 * modal.
 *
 * Pinning the backdrop to the viewport makes the tint independent of that internal scroll.
 */
html:root .brxe-popup-267 .brx-popup-backdrop {
	position: fixed;
	inset: 0;
}

/*
 * The course sidebar keeps its own scroll. (PRE-LAUNCH C4)
 *
 * ROAR asked on 2026-09-03 for the original behaviour back: the sidebar pinned to the viewport with
 * Course Snapshot and Ask a Question scrolling inside it, so the enquiry form stays on screen while
 * the reader works down the page. That is exactly what the design's own utilities already do
 * (`lg:sticky lg:top-28 lg:max-h-[calc(100vh-8rem)] lg:overflow-y-auto`), so this file no longer
 * overrides them. The earlier override, which removed the cap, has been withdrawn.
 *
 * WHY THE SCROLLBAR HAS TO BE OBVIOUS
 *
 * The sidebar is about 1142px against a 639px viewport, so half of it is below the fold at any
 * moment, Send Enquiry included. Everything is reachable, because the panel scrolls - but the
 * scrolling happens INSIDE a panel and nothing announced it. That is not a hypothetical: ROAR could
 * not send a test enquiry on 2026-09-02 for this exact reason, and a tester earlier reported the
 * button "going to the Contact page" when they were in fact clicking what was painted beneath it.
 *
 * So the affordance is the fix, not the cap. An always-visible scrollbar instead of the overlay one
 * the OS hides until you move, and a reserved gutter so nothing shifts when it appears.
 */
html:root aside:has( .roar-enquiry-form ) {
	scrollbar-width: thin;
	scrollbar-color: var( --roar-outline-variant ) transparent;
	scrollbar-gutter: stable;
	overscroll-behavior: contain;
}

html:root aside:has( .roar-enquiry-form )::-webkit-scrollbar {
	width: 10px;
}

html:root aside:has( .roar-enquiry-form )::-webkit-scrollbar-track {
	background: transparent;
}

html:root aside:has( .roar-enquiry-form )::-webkit-scrollbar-thumb {
	background-color: var( --roar-outline-variant );
	border-radius: 999px;
}

html:root aside:has( .roar-enquiry-form )::-webkit-scrollbar-thumb:hover {
	background-color: var( --roar-primary );
}

/*
 * The shop card's quantity stepper.
 *
 * Only the parts the utilities cannot express: the number input's width, the browser's own spinner
 * arrows (redundant next to our own -/+ and cramped at this size), and the steppers not selecting
 * their own glyph when clicked repeatedly — `select-none` is not in the generated utilities.
 *
 * Sized to match the Add to Cart button beside it so the row reads as one control, not two.
 */
.roar-qty-input {
	width: 2.75rem;
	padding: 0;
	background: none;
	border: 0;
	color: inherit;
	-moz-appearance: textfield;
	appearance: textfield;
}

.roar-qty-input::-webkit-outer-spin-button,
.roar-qty-input::-webkit-inner-spin-button {
	margin: 0;
	-webkit-appearance: none;
	appearance: none;
}

.roar-qty-step {
	padding: 0 .6rem;
	background: none;
	border: 0;
	color: inherit;
	font-size: 1rem;
	line-height: 1;
	cursor: pointer;
	align-self: stretch;
	-webkit-user-select: none;
	user-select: none;
}

.roar-qty-step:hover {
	color: var( --roar-primary );
}

/*
 * Bullet lists inside a course's Additional Information panels.
 *
 * fonts.css strips markers from every list in the design (`[class*="brxe-"] ul { list-style: none }`),
 * which is right for navigation and card lists but wrong here: these panels hold ROAR's own prose,
 * and a recommended-experience list reads as three orphaned lines without markers.
 *
 * This cannot be solved in the content itself. WordPress sanitises inline `style` attributes against
 * an allowed-property list, and `list-style` is not on it — `margin` and `padding-left` survive and
 * `list-style` is silently dropped, so a list authored with inline styles loses exactly the property
 * it needed. It has to live in a stylesheet.
 *
 * Scoped to the Additional Information tab so nothing else on the course page is affected.
 */
html:root #panel-additional ul {
	list-style: disc;
	margin: .5rem 0 0;
	padding-left: 1.25rem;
}

html:root #panel-additional ol {
	list-style: decimal;
	margin: .5rem 0 0;
	padding-left: 1.25rem;
}

html:root #panel-additional li {
	display: list-item;
	margin-bottom: .25rem;
}

/*
 * The two EEM courses open their Entry Requirements with a sentence, not a requirement.
 *
 * Every line in that list gets a green check-circle, which is right for an actual requirement
 * ("Current unrestricted Electrical Licence") and wrong for a lead-in that says the opposite:
 *
 *   EEM Surface      "While there are no mandatory prerequisites ... it is highly recommended that
 *                     participants have:"
 *   EEM Underground  "No mandatory prerequisites, but an electrical trade or engineering background
 *                     is strongly recommended"
 *
 * A tick against "there are no prerequisites" reads as though the absence of prerequisites is
 * itself something the student must satisfy. ROAR asked for it removed on these two (2026-09-03).
 *
 * Scoped by post id because it is genuinely per-course: the other 13 courses open with a real
 * requirement and must keep their tick. Checked against all 15 before writing this. If another
 * course is ever given a lead-in sentence, add its id here — post ids survive the move to the live
 * domain, since the site is moved rather than rebuilt.
 */
html:root body.postid-62 .brxe-heruyn:first-child > .material-symbols-outlined,
html:root body.postid-64 .brxe-heruyn:first-child > .material-symbols-outlined {
	display: none;
}

/*
 * "Courses for Group Bookings" split into two menu items on mobile.
 *
 * Bricks gives every mobile menu link `line-height: 60px` to make a 60px tap target. That works
 * until a label wraps: the second line then sits a full 60px below the first, exactly the spacing
 * between two separate menu items, so "Courses for Group" and "Bookings" read as two links rather
 * than one. ROAR reported it as two items, which is the giveaway.
 *
 * It misses fitting by 5px. The label needs 215px and the submenu leaves 210px inside a 300px panel
 * with 45px of padding each side.
 *
 * Two fixes, because the near-miss and the wrapping behaviour are separate problems:
 *
 *   1. Trim the submenu's RIGHT padding to 24px, giving 231px. The 45px left padding is the indent
 *      that marks a sub-item, so it stays.
 *   2. Move the 60px row height off `line-height` and onto padding. A wrapped label then sets as a
 *      normal two-line block instead of two 60px rows. Measured before and after: every one of the
 *      12 rows is 60px either way, so nothing else in the menu moves.
 *
 * Specificity is deliberate: Bricks sets these at (0,2,2) and (0,3,2), so the `html:root` prefix is
 * what makes these win.
 *
 * Values are in px, not rem, on purpose: this site sets a 10px root font size, so 1rem is 10px
 * here and rem values silently come out at five-eighths of what you would expect. The 60px row
 * height these have to preserve is a px value from Bricks, so px keeps the arithmetic checkable.
 */
html:root .brxe-nav-menu .bricks-mobile-menu-wrapper li a {
	line-height: 1.4;
	padding-top: 18.8px;
	padding-bottom: 18.8px;
}

html:root .brxe-nav-menu .bricks-mobile-menu-wrapper .sub-menu li > a {
	padding-right: 24px;
}