/**
 * Corrections to Salient's own CSS.
 *
 * Not the plugin's own look -- that lives in base.css and beside each module.
 * These are things the theme does that this site needs done differently, kept
 * here rather than in the theme's Custom CSS box so that they travel with a
 * deploy, show up in a diff, and survive a theme update.
 *
 * Each one says what it overrides and where, so the next person can check
 * whether the theme still does it before deciding the rule is dead.
 */

/* ---------------------------------------------------------------------------
 * Horizontal Scrolling sections: less wheel per card
 *
 * The element is driven by scroll rather than by time: the script builds an
 * anime.js timeline with `autoplay:false` and `duration = offsetHeight`, then
 * seeks it from the page's scroll position (nectar-sticky-media-sections.js).
 * So the element's height IS the length of the scroll, and Salient sets it to
 * the total width of the cards -- one pixel of wheel per pixel of travel.
 *
 * With twelve cards 1429px wide that is 1429px of scrolling each, some fourteen
 * notches of a wheel, a hundred and seventy for the set. The height below is a
 * quarter of the viewport per card instead.
 *
 * The travel itself does not change (maxTranslation = lane - viewport), so the
 * lane simply moves further per pixel scrolled. Lower this too far and it
 * skips: the ratio is what to watch, not the number.
 *
 * !important because the height is not set by any stylesheet we can find --
 * neither inline nor in the theme's CSS -- so there is nothing to outrank.
 * ------------------------------------------------------------------------- */

@media (min-width: 1000px) {
	.nectar-sticky-media-sections.type--horizontal-scrolling {
		height: calc(var(--section-count, 12) * 25vh) !important;
	}
}

/* ---------------------------------------------------------------------------
 * Dropdown menus: as wide as they need to be
 *
 * Salient fixes every submenu at twenty ems -- `.sf-menu>li ul{padding:20px;
 * width:20em}` in css/build/style.css -- which leaves short menus padded out
 * with empty space.
 *
 * `body` in front only to outrank that rule (0,1,3 against its 0,1,2); no
 * !important, so the theme stays overridable the normal way. The submenus are
 * absolutely positioned, so `auto` is shrink-to-fit: as wide as the longest
 * item, wrapping rather than overflowing if one is very long. If wrapping is
 * the wrong trade here, `max-content` is the other half of that choice.
 * ------------------------------------------------------------------------- */

body .sf-menu > li ul {
	width: auto;
}

/* ---------------------------------------------------------------------------
 * Centred menu on a narrow desktop
 *
 * The centred header lays the menu column out at full width --
 * `#header-outer[data-format=centered-menu] #top .span_9{...width:100%}` in
 * css/build/header/header-layout-centered-menu.css, with no upper bound. On a
 * wide screen there is room to spare; between the mobile header and a full
 * desktop there is not, and a column claiming the whole row leaves the menu
 * nowhere to go.
 *
 * `auto` lets it take what it needs and no more; the theme's own `flex-grow: 1`
 * on the same element still lets it fill what is left.
 *
 * 1000-1300px is the theme's own band for this size (see responsive.css), so
 * the fix begins exactly where its mobile header ends and stops where the
 * layout has room again.
 *
 * `body` in front only to outrank the original: same selector otherwise, so
 * without it the winner would be whichever stylesheet happened to load last.
 * ------------------------------------------------------------------------- */

@media only screen and (min-width: 1000px) and (max-width: 1300px) {
	body #header-outer[data-format="centered-menu"] #top .span_9,
	body #header-outer[data-format="centered-menu"] #top .span_9 .sf-menu:not(.buttons) {
		width: auto;
	}
}