/**
 * Keep a theme's article styling out of the plugin's own markup.
 *
 * WHY THIS FILE EXISTS. WordPress renders every shortcode inside the theme's
 * content wrapper, so a theme that styles prose styles the plugin too. It does
 * so through descendant selectors like `.entry-content ul` — specificity
 * (0,1,1) — while the plugin styles itself with single classes at (0,1,0). The
 * theme wins, and it wins on markup the theme has never seen.
 *
 * Measured on Wolf rather than guessed. Its content rules reach every one of
 * these, and each produced a visible defect:
 *
 *   .entry-content ul          list-style: disc   a bullet beside every gear card
 *   .entry-content ul, ol      padding-left       and an indent to match
 *   .entry-content a           underline, accent  a button rendered as a link
 *   button[type="submit"]      accent background  every button the same orange
 *
 * THE FIX IS ORDER, NOT ESCALATION. The plugin's stylesheets are enqueued after
 * the theme's, so a rule here only has to MATCH the theme's specificity to win —
 * it does not have to exceed it. `[class*="srs-"] ul` is (0,1,1), the same as
 * `.entry-content ul`, and later. That is why nothing below uses !important and
 * nothing below names a theme.
 *
 * IT COVERS THE CATEGORIES, NOT THE INSTANCES. An attribute selector matching
 * any srs- class reaches every plugin subtree on every screen, including ones
 * not written yet. Adding a component does not mean remembering to add a line
 * here.
 *
 * WHAT IT DELIBERATELY DOES NOT DO. It sets nothing a plugin component might
 * reasonably want to differ on. Anything at (0,1,1) here would outrank an
 * ordinary component rule at (0,1,0) and become the thing that has to be fought
 * — the problem this file exists to end, reintroduced from the other side. So
 * it is limited to what the plugin never wants: prose bullets, prose indents,
 * and prose underlines on things that are not prose. Buttons and inputs are
 * settled in their own files, where the component and its defence are one rule.
 *
 * @package Upvising\SkiRental
 */

/*
 * The plugin's lists are grids of cards, rows of facts and sets of choices.
 * None of them is a bulleted list, and none of them has ever wanted the indent
 * a bullet needs.
 */
[class*="srs-"] ul,
[class*="srs-"] ol {
	padding-left: 0;
	list-style: none;
}

/*
 * A link inside plugin markup is a button, a tab or a row action — chrome the
 * plugin styles itself. The exceptions are the places the plugin writes real
 * prose to a customer and links out of it: a policy link in the consent
 * sentence, a document link in a notice. Those keep the theme's underline,
 * because there they are prose and the theme is right.
 */
[class*="srs-"] a:not(.srs-prose a):not(.srs-consent a):not(.srs-note a) {
	text-decoration: none;
}

/*
 * Headings inside the plugin are card titles and section labels sized by the
 * component, not article headings.
 *
 * THE FONT IS NOW RESET TOO, and the earlier note here — that "the theme's font
 * and colour are the site's, and the plugin has no business overriding those" —
 * was wrong about the font. It read as restraint and was actually a hole: the
 * plugin defines `--srs-display` as an ALIAS OF `--srs-sans`, so there is no
 * plugin heading anywhere that wants a display face. Every one of them was
 * getting Wolf's `termina` regardless, because `.entry-content h2` is (0,1,1)
 * and a component's `.srs-card__title` is (0,1,0). "Total Rental Amount" came
 * out as a page heading sitting above its own card.
 *
 * `inherit` RATHER THAN A TOKEN, because `--srs-sans` is scoped to `.srs-entry`
 * and `.srs-account` and would resolve to nothing on the payment and claim
 * pages. Both containers set `font-family: var( --srs-sans )` on themselves, so
 * inheriting gives the plugin's own stack wherever the plugin has one and the
 * site's body face everywhere else — which is the right answer in both places
 * and needs no token to be in scope.
 *
 * SIZE, WEIGHT AND COLOUR ARE NOT HERE, and must not be: those genuinely differ
 * per component, so each states its own and defends it at (0,2,0) in its own
 * file. That is the line this file draws — categories here, values there.
 */
[class*="srs-"] h1,
[class*="srs-"] h2,
[class*="srs-"] h3,
[class*="srs-"] h4,
[class*="srs-"] h5,
[class*="srs-"] h6 {
	margin-top: 0;
	font-family: inherit;
}

/*
 * PROSE PUTS AIR BETWEEN LIST ITEMS AND THE PLUGIN'S LISTS ARE NOT PROSE. Wolf's
 * `.entry-content li + li { margin-top: 0.4em }` is (0,1,2) and outran
 * `.srs-gear__item { margin: 0 }` at (0,1,0), so every gear card except the
 * first in its row dropped 6px. In a grid that also changed the row's height,
 * and the stretched siblings ended up different heights with their tops out of
 * line — one prose rule presenting as two separate layout bugs.
 *
 * MATCHED AT (0,1,2), not raised above it: `li + li` is the same shape as the
 * rule it answers, and this file loads later. The plugin's lists space
 * themselves with `gap` and padding, so there is nothing here to take away.
 */
[class*="srs-"] li + li {
	margin-top: 0;
}
