/* LILASp overrides for the DIPAS Vue frontend.
   Loaded from index.html AFTER /drupal/dipas/design/styles.css, which is
   generated from the per-proceeding dipas_design colours — so anything here
   wins. Upstream frontend assets are never modified. */

/* Landing hero, per proceeding.
   Upstream centres the background image (50% 50%). The frontend sets the image
   as an INLINE style whose URL carries the proceeding's host, so each hero can
   be targeted individually — a global shift is wrong, because the artwork
   differs per proceeding (Northeim's figure loses her head if nudged).

   Lüneburg: the headline sits in the upper third and the welcome card covered
   it. Anchoring lower crops the top of the image and lifts the headline clear. */
.componentInnerContainer.backgroundImage[style*="//lueneburg."] {
  background-position: 50% 72% !important;
}

/* The scroll-to-top control takes its background from --DipasColorsPrimary2
   but hard-code white text (Contributions-*.css). With a light primary2 that
   is unreadable. Point the text at the token that is *defined* to pair with
   the background, so every proceeding stays correct: the ones with a dark
   primary2 keep white text, Rotenburg's light blue gets the dark slate. */
button.DipasButton.scrollToTop,
[class*="scrollToTop"] {
  color: var(--DipasColorsPrimary2TextColor) !important;
}

/* Button hover, general case.
   The hover background comes from --DipasColorsPrimaryButtonHover, which is a
   dark shade in every proceeding (Rotenburg #c4211c, Northeim #e8318a,
   Offenbach #1e2b50, Limburg/Lüneburg #06707e). The label colour, however, is
   whatever the resting state set — on Rotenburg that is the dark slate paired
   with the light-blue primary2, so the text vanished into the red on hover.
   White reads correctly on all of those hover shades.

   Targets span too, same reason as the two CTA buttons below: upstream sets
   colour directly on span.dps-button__text/span.icon for .isMobile/.isTablet,
   and that beats an inherited value from the button regardless of
   !important. Confirmed on the wizard's Weiter/Zurück buttons at tablet
   width - rest stays dark-on-light-blue (correct, left alone), hover was
   still dark-on-red until the span was targeted directly.

   :not(.secondary) - the plain/link-style buttons (Nein-weiter-bearbeiten,
   the X close buttons, the burger menu) don't get a background change on
   hover, so forcing white here made them vanish against the light modal
   background. Only the filled/pill buttons (Weiter, Zurück, Hier
   teilnehmen!, Ja-abbrechen) get a dark hover background and need this. */
.DipasButton:not(.secondary):hover,
.DipasButton:not(.secondary):hover span,
.DipasButton:not(.secondary):focus,
.DipasButton:not(.secondary):focus span,
button.DipasButton:not(.secondary):hover,
button.DipasButton:not(.secondary):hover span,
button.DipasButton:not(.secondary):focus,
button.DipasButton:not(.secondary):focus span {
  color: #fff !important;
}

/* "Hier teilnehmen!" — Rotenburg's homepage hero CTA (main.HomePage >
   ... > .welcomeButtonContainer > button.DipasButton.primary). Deliberately
   its own colours, independent of --DipasColorsPrimary2/PrimaryButtonHover.
   Scoped to Rotenburg the same way as the Lüneburg hero rule above: via the
   hero's own inline background-image URL, since the DOM carries no other
   per-proceeding hook. Red at rest with white text; on hover/focus it becomes
   the light-blue/dark-slate pair — i.e. what it used to look like at rest,
   before this request. */
/* Both rules below also target span.dps-button__text and span.icon directly,
   not just the button. Upstream sets colour on those spans by name for
   .isMobile/.isTablet (Contributions-*.css: "button.DipasButton.isTablet
   span.dps-button__text { color: var(--DipasColorsPrimary2TextColor) }") -
   .isDesktop has no such rule, which is why this only ever showed up at
   phone/tablet widths. A direct rule on the span always wins over an
   inherited value from the parent button, !important or not — inheritance
   is the fallback used only when nothing targets the element itself, so the
   button's own color could never have overridden it. Setting colour on the
   spans too closes that gap in every state. */
.componentInnerContainer.backgroundImage[style*="//rotenburg."] button.DipasButton.primary,
.componentInnerContainer.backgroundImage[style*="//rotenburg."] button.DipasButton.primary span {
  background-color: #E52822 !important;
  color: #fff !important;
}
.componentInnerContainer.backgroundImage[style*="//rotenburg."] button.DipasButton.primary:hover,
.componentInnerContainer.backgroundImage[style*="//rotenburg."] button.DipasButton.primary:hover span,
.componentInnerContainer.backgroundImage[style*="//rotenburg."] button.DipasButton.primary:focus,
.componentInnerContainer.backgroundImage[style*="//rotenburg."] button.DipasButton.primary:focus span {
  background-color: #ABCBED !important;
  color: #3C4F58 !important;
}

/* Same "Hier teilnehmen!" treatment, second occurrence: the contributions-map
   page (main.Contributions > .headerInfoContainer) has its own create button,
   independent of the homepage hero one above. No inline-URL hook exists here,
   so this one is scoped through the html class lilasp-frontend.js sets. */
html.lilasp-rotenburg main.Contributions div.headerInfoContainer button.DipasButton,
html.lilasp-rotenburg main.Contributions div.headerInfoContainer button.DipasButton span {
  background-color: #E52822 !important;
  color: #fff !important;
}
html.lilasp-rotenburg main.Contributions div.headerInfoContainer button.DipasButton:hover,
html.lilasp-rotenburg main.Contributions div.headerInfoContainer button.DipasButton:hover span,
html.lilasp-rotenburg main.Contributions div.headerInfoContainer button.DipasButton:focus,
html.lilasp-rotenburg main.Contributions div.headerInfoContainer button.DipasButton:focus span {
  background-color: #ABCBED !important;
  color: #3C4F58 !important;
}