﻿/* _Layout.cshtml's <head> only ever links ONE BaseTheme stylesheet (whatever
   TenantContext.Current.BaseTheme names) alongside the tenant's own Theme.css - since
   Template3 tenants set BaseTheme to "Template3" (not "DefaultTemplate"), DefaultTemplate.css
   itself would never load for them at all. Importing its source here (SCSS @import
   inlines it into the compiled Template3.css) keeps every tenant-agnostic rule it
   defines (.sliderContainer/.sliderImage/.news-ticker/#content/etc., all needed by the
   shared partials Template3 tenants use too) without touching the shared _Layout.cshtml
   head or duplicating those rules by hand. */
a, a:hover {
  text-decoration: none;
}

.navbar-header {
  max-width: 225px;
}
.navbar-header img {
  max-width: 100%;
}

i.material-icons, i.material-icons-outlined {
  vertical-align: middle;
}

.footer-column {
  margin-bottom: 20px;
}

#page {
  overflow: auto;
  padding-bottom: 15px;
}

html, body {
  height: 100%;
}

body {
  display: flex;
  flex-direction: column;
  min-height: 100vh;
}

main {
  display: flex;
  flex-direction: column;
  flex: 1 0 auto;
}

#page {
  flex: 1 0 auto;
  width: 100%;
}

#content {
  padding: 20px;
  background-color: var(--surface);
  margin-bottom: 100px;
}

/* Opt-in full-width mode (see _Layout.cshtml's own ViewData["FullWidthContent"]
   comment) - #content.container-fluid beats the plain #content rule above on
   specificity (id+class > id alone) regardless of source order, so no !important
   needed. Drops ALL padding, not just left/right - confirmed live against the real
   Spoho site that #content there has zero padding on every side (top/bottom
   included), and with the outer container gone anyway, a lingering top/bottom gap
   here isn't earning its keep either; individual sections already manage their own
   vertical spacing (hero carousel's own mb-4, the product grid/banner's own
   margins) same as the real site's per-section spacers. background/margin-bottom
   are unrelated to width and stay as-is. */
#content.container-fluid {
  padding: 0;
}

footer {
  flex-shrink: 0;
}

.carousel-control-next, .carousel-control-prev {
  opacity: 1;
}

.carousel-control-prev i, .carousel-control-next i {
  font-size: 80px;
  color: black;
}

.nav-link, .nav-link:hover, .nav-link:active {
  color: var(--accent);
}

.category-slider-container {
  border: 1px solid #dadae5;
  padding: 20px;
  border-radius: 4px;
}
.category-slider-container h2 {
  padding-bottom: 10px;
  margin-bottom: 20px;
  border-bottom: 1px solid #dadae5;
}

.landing-slider-container {
  position: relative;
  margin-bottom: 20px;
}

.landing-slide {
  position: relative;
  padding: 10px;
  text-align: center;
  height: 200px;
}
.landing-slide .sliderImage {
  max-height: 70%;
  max-width: 100%;
  margin-bottom: 15px;
}
.landing-slide .landing-slide-title {
  margin: 0;
  font-weight: bold;
  color: var(--text-dark);
}
.landing-slide .landing-slide-title a {
  color: inherit;
  text-decoration: none;
}

button.landing-prev,
button.landing-next {
  position: absolute;
  top: 50%;
  transform: translateY(-50%);
  z-index: 2;
  display: flex;
  align-items: center;
  justify-content: center;
  padding: 5px;
  border: none;
  border-radius: 4px;
  color: var(--surface);
  background: var(--accent);
}
button.landing-prev:hover, button.landing-prev:focus,
button.landing-next:hover,
button.landing-next:focus {
  background: var(--accent-hover);
}

button.landing-prev {
  left: -10px;
}

button.landing-next {
  right: -10px;
}

/* Real legacy .sliderContainer/.sliderImage (css/templates/2/style.scss) - used by
   _HomeFeaturedItemsCarousel.cshtml's larger product cards (image/name/description/
   "view details" button), a DIFFERENT markup shape from the small-tile
   .landing-slide/_ProductTileMini.cshtml carousel above, so it needs its own rule -
   .sliderImage has no .landing-slide ancestor there and was rendering at full native
   image resolution (e.g. 1400px wide) with no size constraint at all before this was
   added, breaking the homepage layout. Tenant-agnostic (var(--surface)/var(--accent)
   only), so lives here rather than any one tenant's stylesheet - same reasoning as the
   .landing-slide block above. */
.sliderContainer {
  background-color: var(--surface);
  border-radius: 4px;
  padding: 10px;
  width: 100%;
  height: 100%;
  display: flex;
  flex-direction: column;
}

.sliderImage {
  max-width: 100%;
  max-height: 220px;
  object-fit: contain;
  margin: 0 auto 15px;
  display: block;
}

.sliderCaption {
  margin: 0;
}

.sliderLink {
  margin-top: auto;
  align-self: center;
}

.news-ticker {
  width: 100%;
  overflow: hidden;
  position: relative;
  height: 25px;
}

.news-ticker p {
  position: absolute;
  left: 100%;
  white-space: nowrap;
  animation: ticker 15s linear infinite;
  display: inline-block;
  margin: 0;
  padding-right: 10em;
}

@keyframes ticker {
  0% {
    transform: translateX(0);
  }
  100% {
    transform: translateX(calc(-100vw - 100%));
  }
}
/* Generic default for the shared _HomeInfoBanner.cshtml partial (see
   HomepageSectionOptions' "InfoBanner" section type) - a plain bordered box in the
   tenant's own brand color, matching HNO's real legacy homepage box
   (`border: 2px solid #FE5000; border-radius: 4px; padding: 30px`) exactly. Template3
   tenants (e.g. Spoho) override this with their own solid-color-band look further down
   the cascade (Template3.scss @imports this file, then redeclares the same selector -
   later source order wins), so this stays the DefaultTemplate-tenant default only. */
.homepage-info-banner {
  border: 2px solid var(--brand-primary);
  border-radius: 4px;
  padding: 30px;
  margin-bottom: 20px;
}

/* Template3 BaseTheme CSS: the reusable visual identity for any tenant on the legacy
   "Template 3" engine (SpoHo today) - deliberately uses var(--brand-primary)/
   var(--brand-secondary) (from _BrandingStyles.cshtml, driven by each tenant's own
   TenantOptions.Branding) everywhere the real legacy style.scss uses its own
   per-tenant-copied $accent-color-light/$light-background-color, so a FUTURE
   Template3 tenant with different brand colors gets this whole look for free - no
   per-tenant CSS needed, only its own Branding.PrimaryColor/SecondaryColor. */
/* Real legacy site: every heading is upper-cased (confirmed live: "T-Shirts" category
   title renders "T-SHIRTS", "Aktionsartikel" renders "AKTIONSARTIKEL") - a real
   `h1,h2,h3,h4,h5 { text-transform: uppercase }` rule in the real style.scss, applied
   site-wide, not per-element. Product NAMES on the category grid are NOT uppercase
   (confirmed live: "Adidas Graphic Tee 2.0" stays mixed-case there) - because the real
   markup renders them as a plain <div>, not a heading; only the homepage slider caption
   uses an actual <h4>, which already picks up this rule automatically. */
h1, h2, h3, h4, h5 {
  text-transform: uppercase;
}

/* Real legacy #main-menu is "sticky" while scrolling (confirmed live via a real scroll
   test: it stays pinned at the top of the viewport once scrolled past #meta-nav's own
   height, while #meta-nav itself scrolls away normally) - a plain CSS sticky position
   reproduces the same visual result as the legacy site's own fixed-position + jQuery
   scroll-handler hack, with no JS needed. */
#main-menu {
  position: sticky;
  top: 0;
  z-index: 1030;
  background-color: #fff;
}

/* Real bug hit and fixed while building this for Spoho, applies to any Template3
   tenant: DefaultTemplate.scss's shared `#page { overflow: auto; }` rule makes #page
   the sticky positioning's reference ancestor per the CSS spec, but #page itself isn't
   what actually scrolls (the window is) - so a naive `position: sticky` on #main-menu
   never actually stuck. */
#page {
  overflow: visible;
}

/* Real bug #2: `position: sticky` is also constrained to stay within its own
   CONTAINING BLOCK - the shared <nav> wrapper around #meta-nav/#main-menu/
   #categoryWrapper is only as tall as those three rows stacked (~130px), nowhere near
   enough room for #main-menu to stay stuck for the rest of a real page. `display:
   contents` removes <nav> from the box tree (its children become #page's direct
   box-model children instead - #page spans the whole scrollable page), fixing the
   stick range with no JavaScript. Scoped to only the OUTER nav (`#page > nav`), not the
   inner `.navbar` used by #categoryWrapper's own toggler/collapse mechanism, which
   would break if it lost its box. Known trade-off: some older screen readers drop
   `display: contents` elements from the accessibility tree, though <nav>'s landmark
   role is preserved in current ones. */
#page > nav {
  display: contents;
}

/* Real legacy category links sit INSIDE #main-menu itself (confirmed live: #center-menu
   is a direct child of #main-menu, not of a separate #categoryWrapper row) -
   #template3MainMenuCategories fills DefaultTemplate's opt-in "MainMenuCategories"
   section (see Template3/_Layout.cshtml) with the same shared CategoryNav component
   every tenant's #categoryWrapper already uses. Its <ul class="navbar-nav"> defaults to
   a column layout outside of a real Bootstrap `.navbar` ancestor (which #main-menu here
   isn't, to avoid touching the shared skeleton's own classes) - forced back to a row. */
#template3MainMenuCategories .navbar-nav {
  flex-direction: row;
  margin: 0;
}

/* Real legacy category-link hover effect, ported from the real style.scss
   (#center-menu a.nav-link:hover::before) - a small dot appears centered below the
   link on hover. The real site's own offset (bottom: -23px) was tuned for its own
   taller nav; retuned smaller here to match this app's own (shorter) merged nav
   proportions rather than copying the pixel value verbatim - same "adapt the offset,
   don't blindly copy it" lesson as the KVB badge/ticker work.

   Real legacy spacing is `margin-left/right: 25px` PER LINK (confirmed in the real
   style.scss's `#center-menu a.nav-link`), not a flex `gap` on the container - fixed
   after a real report that the spacing looked wrong (a flat `gap: 0.5rem` was much
   tighter than the real ~50px between links). */
#template3MainMenuCategories .nav-link {
  position: relative;
  margin-left: 25px;
  margin-right: 25px;
}

#template3MainMenuCategories .nav-link:hover::before {
  content: "";
  position: absolute;
  bottom: -8px;
  left: calc(50% - 3px);
  width: 6px;
  height: 6px;
  border-radius: 50%;
  background: var(--brand-primary);
}

/* Real legacy full-width search dropdown (`.custom-dropdown` in the real style.scss) -
   spans the whole nav width instead of a small anchored Bootstrap dropdown. Scoped to
   only the search panel (not the profile dropdown next to it, which has no equivalent
   in the real site at all - see Template3/_Layout.cshtml's own comment on why it's a
   deliberate .NET-side addition, so it keeps Bootstrap's normal small anchored-dropdown
   style instead).

   Real bug hit and fixed: Bootstrap's own bundled CSS has `.navbar-nav .dropdown-menu {
   position: static }` (meant for the standard collapsed-navbar-on-mobile case) -
   #right-menu used to carry the `.navbar-nav` class too, so that TWO-CLASS selector
   (specificity 0-2-0) beat this single-class `.template3-search-dropdown` rule
   (0-1-0) and silently forced the dropdown back into normal document flow, pushing
   the profile/cart icons down onto a new line instead of floating the search panel
   over the page (confirmed live via getComputedStyle - computed `position` was
   `static` despite this rule, and `data-bs-popper="static"` on the element, not a
   missing attribute). Fixed at the root by dropping the unneeded `.navbar-nav` class
   from #right-menu itself (see Template3/_Layout.cshtml) - it added no real behavior
   there anyway (#right-menu isn't nested in an actual `.navbar`) - and using the
   element's own id here for a defensively-unambiguous specificity margin. */
#searchWrapper.template3-search-dropdown {
  position: absolute;
  top: 100%;
  left: 0;
  right: 0;
  margin-top: 0;
  border-radius: 0;
  border: none;
  padding: 20px;
  box-shadow: 0 14px 12px -9px rgba(0, 0, 0, 0.175);
}

/* Real bug #2 hit and fixed: even after the position:static fix above, the dropdown
   only stretched to match its OWN immediate `.dropdown` wrapper's width (~160px,
   confirmed live via getBoundingClientRect - it does NOT reach the page's left edge),
   not the full nav width - because Bootstrap's own `.dropdown { position: relative }`
   rule makes THAT small wrapper the CSS containing block for an absolutely-positioned
   child, not #main-menu. Resetting it to `position: static` here removes it from
   being a containing-block candidate at all, so the search dropdown's `left:0;right:0`
   resolves against the next positioned ancestor up the tree instead - #main-menu
   (position: sticky) - giving the real full-width mega-panel span. Bootstrap's dropdown
   JS toggle (.show class) doesn't depend on this wrapper's own position, so this is
   purely a positioning fix, not a functional one. */
#right-menu .dropdown {
  position: static;
}

#searchResults {
  max-height: 60vh;
  overflow-y: auto;
}

/* #categoryWrapper's own separate row would otherwise duplicate the category list a
   second time at desktop widths (rendered inline in #main-menu instead, see above) -
   and is no longer needed at all below lg either now that a real #mobile-menu block
   exists (see Template3/_Layout.cshtml's own MobileMenu section) - so it's hidden at
   every width, unlike the earlier "reuse the collapse as a mobile fallback"
   simplification this replaced. */
#categoryWrapper {
  display: none;
}

/* Real legacy #main-menu is `d-none d-lg-block` (desktop-only) with a completely
   separate `#mobile-menu` block below lg - matched here via the lg breakpoint media
   query instead of adding Bootstrap's display utility classes directly to the shared
   DefaultTemplate markup (which Koelnshop/KVB/Bridge also render, unaffected by this
   Template3-only rule). */
@media (max-width: 991.98px) {
  #main-menu {
    display: none;
  }
}
/* Real legacy `#mobile-menu` styling, read directly from the real style.scss
   (`#mobile-menu { ... }`) - a plain stacked collapse menu, not styled to match the
   desktop nav at all. */
#mobile-menu {
  padding: 10px 5px;
}

#mobile-menu ul {
  padding-left: 0;
  list-style: none;
}

#mobile-menu ul li {
  margin-bottom: 10px;
}

#mobile-menu a {
  color: var(--brand-primary);
  padding-left: 0;
}

#mobile-menu .btn-primary {
  padding-right: 0;
  text-align: center;
  width: 100px;
  display: flex;
  justify-content: center;
}

#mobile-menu .btn-primary i,
#mobile-menu .btn-primary span {
  color: #fff;
}

#mobileActionWrapper {
  display: flex;
  justify-content: space-between;
}

/* Real legacy #mobile-menu's own toggler is a solid brand-color button (not
   Bootstrap's default transparent-with-border look) with a white hamburger icon -
   confirmed live via getComputedStyle/the real style.scss's own
   `#mobile-menu .navbar-toggler-icon` rule. Scoped to #mobile-menu specifically so it
   doesn't affect any other toggler elsewhere in the app.

   Real bug caught and fixed: the button was missing its padding/border-radius (and the
   icon was rendering a bit small) entirely (confirmed live on the real site:
   `padding: 4px 12px`, `border-radius: 4px`, button `font-size: 1.25rem` giving a 30px
   icon - all Bootstrap defaults, not custom SpoHo rules). Root cause: Bootstrap's own
   `.navbar-toggler`/`.navbar-toggler-icon` CSS reads `padding`/`border-radius`/
   `font-size` from `--bs-navbar-toggler-*` custom properties, which are only ever
   DEFINED (given real values) on an actual `.navbar` element - this toggler is a plain
   `<button>` with no `.navbar` ancestor (deliberately,
   to avoid pulling in Bootstrap's other navbar behaviors), so those variables were
   simply undefined and the padding/radius silently collapsed to nothing. Fixed by
   setting the values directly instead of relying on the variable indirection. */
#mobile-menu .navbar-toggler {
  background-color: var(--brand-primary);
  padding: 4px 12px;
  border-radius: 4px;
  font-size: 1.25rem;
}

#mobile-menu .navbar-toggler-icon {
  background-image: url("data:image/svg+xml;charset=utf8,%3Csvg viewBox='0 0 32 32' xmlns='http://www.w3.org/2000/svg'%3E%3Cpath stroke='rgba(255, 255, 255, 1)' stroke-width='2' stroke-linecap='round' stroke-miterlimit='10' d='M4 8h24M4 16h24M4 24h24'/%3E%3C/svg%3E");
}

/* #collapseMenu reuses the same shared CategoryNav component the desktop merged nav
   already uses (DRY - see #template3MainMenuCategories above) instead of a second
   category-rendering partial just for mobile; restyled here to match the real
   mobile menu's plain vertical list look (real markup is actually a flat
   `.item-fancy`/`.item-fancy-link` list, but the real CSS for those classes only
   applies inside the desktop "Shop" mega-menu's `.shop-col` wrapper - confirmed live
   via getComputedStyle that the mobile list itself just falls back to `#mobile-menu`'s
   own plain `a`/`ul li` rules above, so no extra `.item-fancy`-specific CSS is needed
   here at all). */
#collapseMenu .navbar-nav {
  flex-direction: column;
}

/* Real legacy meta-nav/main-menu link colors, confirmed live via getComputedStyle:
   #meta-nav's own links are always white (readable against its brand-primary
   background), #main-menu/#categoryWrapper's are always plain black (readable against
   the white main-menu bar) - both override DefaultTemplate.scss's shared
   `.nav-link { color: var(--accent) }` rule, which would otherwise paint every nav
   link the tenant's own primary color regardless of what it's sitting on. */
#meta-nav {
  background-color: var(--brand-primary);
  color: #fff;
}

#meta-nav .nav-link {
  color: #fff;
}

#meta-nav .nav-link:hover {
  color: #fff;
  text-decoration: underline;
}

#main-menu .nav-link,
#categoryWrapper .nav-link {
  color: #000;
}

/* Real legacy footer/product-image background (`$light-background-color: #f5f6f6` in
   the real style.scss, confirmed live via getComputedStyle on the footer) - a
   template-level convention, not a tenant-specific color, so hardcoded here rather than
   made configurable (no Template3 tenant so far has needed a different footer shade). */
.footer {
  background-color: #f5f6f6;
  color: #212529;
}

.footer-link {
  color: var(--brand-primary);
  font-weight: 700;
}

/* Real legacy product-card (confirmed live via BaseTemplate3::GetIconviewRow, the
   actual category-grid rendering function - NOT the homepage slider's product-card,
   which looks similar but is a different function and was wrongly used as the
   reference the first time this was built): a light-gray image box with a
   hover-reveal "add to cart" button overlaid on it, name and price on one row below
   (price right-aligned), then the in-stock/sold-out status line.
   See Template3/Shared/_ProductTile.cshtml for the matching markup. */
.template3-product-card {
  display: block;
  color: #212529;
  text-decoration: none;
}

.template3-product-card:hover {
  color: #212529;
}

.template3-product-image-wrapper {
  position: relative;
  padding: 20px;
  background-color: #f5f6f6;
  margin-bottom: 0.75rem;
}

.template3-product-image-wrapper img {
  width: 100%;
}

/* Real legacy "add to cart" button overlaid on the product image, hidden until the
   whole tile is hovered - ported directly from the real style.scss's own
   `.product-image-wrapper .add-to-cart` rule (position/spacing/uppercase/
   letter-spacing all copied verbatim) and the real `opacity-0` / `.show-AddCart:hover`
   mechanism (reimplemented here as plain CSS `:hover`, no JS needed, since the button
   is a sibling within the same tile rather than needing a class toggled by jQuery). */
.template3-product-tile .add-to-cart-form {
  position: absolute;
  bottom: 20px;
  left: 20px;
  right: 20px;
  opacity: 0;
  transition: opacity 0.2s ease;
}

.template3-product-tile:hover .add-to-cart-form {
  opacity: 1;
}

.template3-product-tile .add-to-cart-form .btn {
  width: 100%;
  border-radius: 0;
  text-transform: uppercase;
  letter-spacing: 0.1rem;
}

/* Real legacy category grid is a fixed 3-per-row (`col-md-4`, confirmed in
   BaseTemplate3::GetIconviewRow) at every width from `md` up - it never grows to 4
   columns on wider desktop screens the way the shared `Catalog/Index.cshtml`'s own
   generic `row-cols-2 row-cols-md-3 row-cols-lg-4` grid does for every other tenant.
   Overriding just the `lg` step back to 3 (33.3333%) here reproduces the real fixed
   3-column behavior without changing the shared view - real bug reported directly by
   the user ("das Layout ... ist dreispaltig" as a mismatch, not a compliment) after
   comparing this app's desktop-width rendering (4 columns) against the real site's own
   (always 3). */
@media (min-width: 992px) {
  #content .row-cols-lg-4 > * {
    width: 33.3333%;
  }
}
/* Real legacy `.banner` styling (confirmed in the real style.scss): solid brand-color
   background, white centered uppercase text, ported here as `.homepage-info-banner`
   (the generic, theme-agnostic section - see _HomeInfoBanner.cshtml) since the
   uppercase heading already comes for free from this file's own `h1-h5{text-transform:
   uppercase}` rule above. */
.homepage-info-banner {
  background-color: var(--brand-primary);
  color: #fff;
  text-align: center;
  padding: 20px 0;
  /* Explicitly cancel DefaultTemplate.scss's own bordered-box default (ported for
     HNO's real bordered info box) - this rule only overrode background/color/padding
     before, silently leaking border/border-radius through onto every Template3
     tenant's solid-color band. Only harmless-by-coincidence for Spoho today because
     its border color happens to match its own background. */
  border: none;
  border-radius: 0;
}

.homepage-info-banner a {
  color: #fff;
  text-decoration: underline;
}

@media (max-width: 767.98px) {
  .homepage-info-banner {
    padding: 20px;
  }
}
