/* front.css — theme identity layer for the default site.
 *
 * The front site ran a purchased Bootstrap 4 theme compiled into theme.css,
 * whose Sass overrode 104 Bootstrap variables. This file re-creates that
 * identity on top of stock Bootstrap 5.3.8. It has one job, so it can be
 * reviewed as a unit and deleted wholesale if the stock look is ever accepted.
 *
 * Load order matters: bootstrap.min.css -> front.css -> custom.css.
 * custom.css must stay last; it already overrides theme rules.
 */

/* ---- 1. Tokens ---------------------------------------------------------- */
:root {
  --bs-blue: #0099FF;
  --bs-primary: #0099FF;
  --bs-primary-rgb: 0, 153, 255;
  --bs-dark: #152a49;
  --bs-dark-rgb: 21, 42, 73;

  --bs-body-font-family: 'Nunito', -apple-system, BlinkMacSystemFont, "Segoe UI",
      Roboto, "Helvetica Neue", Arial, sans-serif, "Apple Color Emoji",
      "Segoe UI Emoji", "Segoe UI Symbol";
  --bs-body-bg: #e9ecef;          /* theme set $body-bg: $gray-200 */
  --bs-body-color: #6c757d;       /* theme set $body-color: $gray-600 */
  --bs-emphasis-color: #152a49;   /* $headings-color: $gray-900 (#152a49) */
  --bs-heading-color: #152a49;
  /* Same story as --bs-link-color-rgb below: several stock BS5.3 rules read
     the -rgb custom property through rgba(), not the scalar above, and fall
     back to Bootstrap's own stock rgb triplet when it's unset. Measured
     effect: table.table-striped row tint (--bs-table-striped-bg) rendered
     rgba(0,0,0,.05) -- Bootstrap's stock --bs-emphasis-color-rgb -- instead
     of a navy-tinted rgba(21,42,73,.05) (content/zorunlu-trafik-sigortasi,
     all 7 languages). Same dependency reaches table hover/active tints,
     .navbar's derived link/brand colours, and .link-body-emphasis. */
  --bs-body-color-rgb: 108, 117, 125;
  --bs-emphasis-color-rgb: 21, 42, 73;
  --bs-border-color: #e9ecef;     /* $border-color: $gray-200 */

  --bs-border-radius: .375rem;
  --bs-border-radius-sm: .25rem;
  --bs-border-radius-lg: .5rem;

  --bs-link-color: #0099FF;
  --bs-link-hover-color: #0099FF;
  /* Bootstrap 5.3's `a` rule reads --bs-link-color-rgb (via rgba()), not
     --bs-link-color -- the scalar above is otherwise dead weight and every
     bare link rendered stock Bootstrap blue (#0d6efd) instead of the theme
     colour. Same story on hover: `a:hover` copies --bs-link-hover-color-rgb
     into --bs-link-color-rgb. */
  --bs-link-color-rgb: 0, 153, 255;
  --bs-link-hover-color-rgb: 0, 153, 255;
}

/* theme.css styled these as bare element/type selectors, so front.css's
   class-name survey never picked them up. */
section { position: relative; padding: 4.5rem 0; }   /* .bg-image below
   anchors to position:relative. The padding is theme.css's bare `section`
   default -- restored because content/19-*.html (hero banners, all 7
   languages) and two grouping <section>s in purchase_ys-step-1.tpl.php carry
   no p-, py-, pt- or pb- utility of their own and so relied on it entirely.
   Every <section> that does carry a spacing utility is unaffected: the utility
   rules below are !important and win regardless of source order. */

img { max-width: 100%; }          /* CMS-authored <img> tags carry no
   Bootstrap sizing class and overflowed their column without this. */

/* Text nested in a link (e.g. the home-page blog-card title/date, both
   wrapped in one <a>) must not pick up the link colour. */
a p, a span, a ul, a ol { font-weight: 400; color: #6c757d; }

a { text-decoration: none; }      /* $link-hover-decoration: none */
a:hover { text-decoration: none; }

h1, h2, h3, h4, h5, h6,
.h1, .h2, .h3, .h4, .h5, .h6 {
  color: var(--bs-heading-color);
  font-weight: 600;               /* $headings-font-weight: 600 */
  margin-bottom: 1rem;            /* $headings-margin-bottom: 1rem */
}

.lead { font-weight: 400; }       /* $lead-font-weight: 400 */
.small, small { font-size: .875rem; }   /* $small-font-size: 0.875rem */

/* theme.css: label { display: inline-block; margin-bottom: .5rem }. Bootstrap
   5.3's reboot dropped the margin (bare label{display:inline-block} only) --
   it now comes only from the .form-label utility class, which most labels
   here don't carry (template/default/widget-form-ik.tpl.php,
   purchase_to-step-1.tpl.php and siblings all use bare <label>). Measured on
   /purchase_to/step1: label sat flush against its field wrapper, 0px gap,
   where theme.css gives 8px. Low specificity (element selector) by design --
   .form-check-label and .large-checkbox label already get their own
   margin-bottom from custom.css at higher specificity and are unaffected
   (verified: hero checkbox row screenshot is pixel-identical with and
   without this rule). */
label { margin-bottom: .5rem; }

/* theme.css: article h3, article h4, article h5 { margin: 2.25rem 0 }, and
   article blockquote / article figure with their own margins -- scoped to
   template/default/blog.tpl.php's <article> wrapper around CMS-authored post
   bodies. blockquote/figure never occur in any of the 53 live posts
   (checked), so only the heading rule is restored. Measured on a live post:
   article h3 had margin-top: 0 (only the generic h1..h6 rule's 1rem
   margin-bottom applied), so headings ran straight into the preceding
   paragraph with no breathing room above. */
article h3, article h4, article h5 { margin: 2.25rem 0; }

/* theme.css set this on every page (html { -webkit-font-smoothing:
   antialiased; -moz-osx-font-smoothing: grayscale }); stock Bootstrap 5
   doesn't touch it, so glyphs fell back to the OS default (subpixel/
   grayscale AA on most engines), rendering visibly thinner and softer --
   most noticeable as white text on the hero's dark overlay, which is
   exactly what the owner reported as "reduced opacity" even though colour
   and opacity both measured correct. Restored verbatim. */
html {
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
}

/* Theme shrunk the root font size below 768px, so every rem-based size and
   spacing value on the page scaled down with it. Its absence made mobile
   pages measurably taller (~16% on the home page) than the baseline. */
@media (max-width: 767.98px) {
  html { font-size: .875rem; }
}

/* ---- 2. Spacing scale ($spacer was 1.5rem, Bootstrap 5 stock is 1rem) ---- */
/* .m-1 = .25 * 1.5rem = .375rem, .m-2 = .75rem, .m-3 = 1.5rem,
   .m-4 = 2.25rem, .m-5 = 4.5rem.
   41 non-zero utilities in use are listed (re-derived 2026-08-05 against the
   post-markup-conversion tree -- the original 28-rule survey predated
   ml-1->ms-1, mr-1->me-1 and form-group->mb-3/mb-lg-3, and missed them). The
   `-0` variants (mt-0, mb-0, my-0, p-0, pt-0, pb-0, py-0, mt-md-0, mb-lg-0,
   mb-md-0) are omitted deliberately: zero is zero on both scales, so
   overriding them is a no-op. */
.mt-1 { margin-top: .375rem !important; }   .mb-1 { margin-bottom: .375rem !important; }
.mx-1 { margin-left: .375rem !important; margin-right: .375rem !important; }
.ms-1 { margin-left: .375rem !important; }  .me-1 { margin-right: .375rem !important; }
.mt-2 { margin-top: .75rem !important; }    .mb-2 { margin-bottom: .75rem !important; }
.my-2 { margin-top: .75rem !important; margin-bottom: .75rem !important; }
.mt-3 { margin-top: 1.5rem !important; }    .mb-3 { margin-bottom: 1.5rem !important; }
.my-3 { margin-top: 1.5rem !important; margin-bottom: 1.5rem !important; }
.mt-4 { margin-top: 2.25rem !important; }   .mb-4 { margin-bottom: 2.25rem !important; }
.my-4 { margin-top: 2.25rem !important; margin-bottom: 2.25rem !important; }
.mt-5 { margin-top: 4.5rem !important; }    .mb-5 { margin-bottom: 4.5rem !important; }
.my-5 { margin-top: 4.5rem !important; margin-bottom: 4.5rem !important; }

.p-1  { padding: .375rem !important; }
.p-2  { padding: .75rem !important; }       .p-3  { padding: 1.5rem !important; }
.p-4  { padding: 2.25rem !important; }
.pt-2 { padding-top: .75rem !important; }   .pb-1 { padding-bottom: .375rem !important; }
.pb-2 { padding-bottom: .75rem !important; }
.pt-3 { padding-top: 1.5rem !important; }   .pb-3 { padding-bottom: 1.5rem !important; }
.pt-4 { padding-top: 2.25rem !important; }  .pb-4 { padding-bottom: 2.25rem !important; }
.pb-5 { padding-bottom: 4.5rem !important; }
.py-1 { padding-top: .375rem !important; padding-bottom: .375rem !important; }
.py-2 { padding-top: .75rem !important; padding-bottom: .75rem !important; }
.py-3 { padding-top: 1.5rem !important; padding-bottom: 1.5rem !important; }
.py-4 { padding-top: 2.25rem !important; padding-bottom: 2.25rem !important; }
.py-5 { padding-top: 4.5rem !important; padding-bottom: 4.5rem !important; }
.px-2 { padding-left: .75rem !important; padding-right: .75rem !important; }
.px-3 { padding-left: 1.5rem !important; padding-right: 1.5rem !important; }

@media (min-width: 768px) {
  .mt-md-4  { margin-top: 2.25rem !important; }
  .py-md-1  { padding-top: .375rem !important; padding-bottom: .375rem !important; }
}

@media (min-width: 992px) {
  .pt-lg-4  { padding-top: 2.25rem !important; }
  .my-lg-3  { margin-top: 1.5rem !important; margin-bottom: 1.5rem !important; }
  .mb-lg-3  { margin-bottom: 1.5rem !important; }
}

/* ---- 3. Components ------------------------------------------------------ */
.btn {
  --bs-btn-font-weight: 700;              /* $btn-font-weight: 700 */
  --bs-btn-border-radius: .25rem;         /* (2/3) * $border-radius */
  --bs-btn-padding-x: 1rem;               /* $input-btn-padding-x */
  --bs-btn-padding-y: .3125rem;           /* $input-btn-padding-y */
}
.btn-lg { --bs-btn-border-radius: .25rem; }
.btn-sm { --bs-btn-border-radius: .25rem; --bs-btn-padding-y: .125rem; }

.card {
  --bs-card-border-width: 0;              /* $card-border-width: 0px */
  --bs-card-spacer-x: 1.5rem;             /* $card-spacer-x: $spacer */
  --bs-card-spacer-y: 1rem;               /* $card-spacer-y: 1rem */
  --bs-card-bg: #fff;                     /* $card-bg: $white; BS5 derives this
     from --bs-body-bg (#e9ecef) otherwise, greying every card on the page */
}

/* Bootstrap 5.3 derives these twelve component backgrounds from
   --bs-body-bg, which front.css correctly points at the page background
   (#e9ecef). Bootstrap 4's theme kept each of these white independently, so
   without an explicit override every one of them silently turned grey. */
.accordion { --bs-accordion-bg: #fff; }   /* no BS4 var; content accordions
   were .card, whose $card-bg was $white */
.popover { --bs-popover-bg: #fff; }       /* $popover-bg: $white */
.table { --bs-table-bg: transparent; }    /* $table-bg: transparent */

.form-control, .form-select {
  --bs-border-radius: .25rem;
  /* Bootstrap 5.3 derives these from --bs-body-bg/--bs-border-color, which
     front.css correctly points at the page background (#e9ecef) -- but the
     theme's $input-bg/$input-border-color were independent of $body-bg, so
     inputs need their own explicit values here rather than a --bs-body-bg
     change (that would also repaint the page background). Bootstrap 5.3 has
     no per-component custom property for this, so this must be a literal. */
  background-color: #fff;                 /* $input-bg: $white */
  border-color: #ced4da;                  /* $input-border-color: $gray-400 */
  box-shadow: none;                       /* $input-box-shadow: none */
  color: #152a49;                         /* $input-color: $headings-color */
  padding: .3125rem 1rem;
}
.form-control:focus, .form-select:focus {
  background-color: #fff;                 /* $input-focus-bg: $white */
  box-shadow: none;                       /* $input-focus-box-shadow: none */
}
.form-control::placeholder { color: rgba(21, 42, 73, .5); }

.input-group-text {
  background-color: #fff;                 /* $input-group-addon-bg: $input-bg */
  border-color: #ced4da;                  /* same border as .form-control; it
     also reads --bs-border-color, which is not white-input-appropriate */
}

.dropdown-menu {
  --bs-dropdown-bg: #fff;                 /* $dropdown-bg: $white */
  --bs-dropdown-border-color: #e9ecef;
  --bs-dropdown-item-padding-x: 1rem;
  --bs-dropdown-item-padding-y: .375rem;
  --bs-dropdown-link-color: rgba(21, 42, 73, .5);
  --bs-dropdown-link-hover-color: #152a49;
  --bs-dropdown-link-hover-bg: transparent;
  --bs-dropdown-link-active-color: #0099FF;
  --bs-dropdown-link-active-bg: transparent;
  --bs-dropdown-divider-bg: #e9ecef;
}

/* nav-tabs: transparent borders with a 3px primary underline on the active
   tab. Bootstrap 5 has no runtime hook for the active border colour, so these
   are explicit rules rather than custom properties. */
.nav-tabs {
  --bs-nav-tabs-border-width: .1875rem;
  --bs-nav-tabs-border-color: transparent;
  --bs-nav-tabs-border-radius: 0;
  --bs-nav-tabs-link-hover-border-color: transparent;
  --bs-nav-tabs-link-active-color: #152a49;
  --bs-nav-tabs-link-active-bg: transparent;
  --bs-nav-tabs-link-active-border-color: transparent transparent #0099FF;
}

/* Bootstrap 4 put the border-compensating negative margin on .nav-item (the
   <li>), leaving a heading's own margin-bottom (1rem, set above in section 1)
   free to contribute to the row's flex cross-size. Bootstrap 5.3 moves that
   negative margin onto .nav-link itself (.nav-tabs .nav-link { margin-bottom:
   calc(-1 * var(--bs-nav-tabs-border-width)) }) -- two classes, so it outranks
   the heading rule's single-class selector and overwrites margin-bottom to
   -3px instead of stacking with it. The red menu bar's links are both
   .nav-link and .h6 (template/default/inc.header.tpl.php), so this silently
   shaved ~13px off its height.
   A first fix cancelled that with margin-bottom: .625rem !important, but a
   bottom-only margin isn't centring: it pads the bar's content out to 50px
   from below only, so the text sits flush against the top (measured gap
   above 0px, gap below 10px). Cancel the negative margin back to zero
   instead -- our selector already has three classes against Bootstrap's two,
   so it wins without !important -- and give the bar its 50px height with
   min-height on the navbar itself. The navbar carries py-0 (no vertical
   padding to lean on) but already has align-items: center at every level
   down to the <ul> (template/default/inc.header.tpl.php), so once the navbar
   has height to spare, that existing centering distributes it evenly above
   and below the link instead of only below. Measured: 50px bar, gap above
   4.88px == gap below 4.89px.
   min-height must be scoped to >= 992px (navbar-expand-lg, where the links
   are actually visible). Applied unscoped it also hit the collapsed mobile
   bar: below lg .navbar-collapse is display:none (0 height), so an unscoped
   min-height rendered as 50px of bare red with nothing in it. Below lg the
   bar should carry no height of its own -- template/default/inc.header.tpl.php
   already has a separate .bdr-btm-red.d-lg-none div right after this nav for
   exactly that width range, a 3px solid #dc3545 bottom border (custom.css)
   that is the pre-migration "thin red line" and was rendering correctly the
   whole time, just hidden under the 50px bug above it. */
.nav-tabs .nav-link.h6 { margin-bottom: 0; }
@media (min-width: 992px) {
  .navbar.bg-danger { min-height: 50px; }
}

.nav-pills {
  --bs-nav-pills-link-active-bg: #fff;
  --bs-nav-pills-link-active-color: #0099FF;
}

.navbar { --bs-navbar-nav-link-padding-x: 1.125rem; }
/* At the narrow end of navbar-expand-lg (992-1199px) the six menu links plus
   the "Indirimli Fiyatlari Gor" sticky button no longer fit the available
   width on one line each with the 1.125rem side padding above: the two
   longest link labels and the button wrap to a second line, inflating the
   bar to ~58px and making the row look broken (measured and screenshotted at
   1024px). 1.125rem is not a new value -- it is the exact pre-migration
   theme.css rule for .navbar-expand-lg .navbar-nav .nav-link at this same
   992px breakpoint -- so this narrowness likely predates the migration too;
   it is fixed here regardless because it visibly looks wrong today. Falling
   back to Bootstrap's stock 0.5rem only in this band frees enough width
   (measured: fits with margin to spare) without touching the 1.125rem
   spacing at 1200px and up, where there is room and no wrap occurs. */
@media (min-width: 992px) and (max-width: 1199.98px) {
  .navbar { --bs-navbar-nav-link-padding-x: 0.5rem; }
}

.list-group {
  --bs-list-group-bg: #fff;               /* $list-group-bg: $white */
  --bs-list-group-border-color: #e9ecef;
}

/* .list-social-links (footer social icon row, inc.footer.tpl.php) was only
   ever fully styled in theme.css. custom.css augments it -- icon size,
   margin-bottom reset, a background override for the li.text-white variant
   the footer actually uses -- but never supplied the structural rules, so
   the survey that built this file (list classes theme.css styled, minus
   anything custom.css also mentions) wrongly treated it as fully replaced
   and dropped the <ul>/<li> layout entirely.
   Only what's genuinely missing is ported below:
     - display:flex/list-style/padding: the <ul> rendered as a bulleted
       vertical list without them.
     - li margins: horizontal spacing between icons.
     - li.text-white a color: theme.css sets #fff here too (a sub-rule this
       migration's source quote omitted); without it the icon falls back to
       the plain link colour (#0099FF), unreadable on the dark footer.
   Dropped as noise -- already fully handled by custom.css, some with
   !important, so re-declaring here would either do nothing or mislead:
     - the base `a` chip look (display/padding/background/color/radius/
       transition) and its :hover -- every real li carries text-white, whose
       higher-specificity color/!important background always win, so the
       chip is never seen.
     - `i { font-size: .75rem }` -- custom.css forces 2rem !important.
     - li.text-white a's background and :hover background -- custom.css
       forces `background: none !important` on this exact selector. */
.list-social-links {
  padding: 0;
  list-style: none;
  display: flex;
}
.list-social-links > li {
  margin-right: 0.375rem;
}
.list-social-links > li:last-child {
  margin: 0 0.1875rem;
}
.list-social-links > li.text-white a {
  color: #fff;
}

.modal {
  --bs-modal-bg: #e9ecef;                 /* $modal-content-bg: $body-bg */
  --bs-modal-border-width: 0;
  --bs-modal-padding: 1.5rem;
  --bs-modal-header-padding: 1.5rem;
}

.pagination {
  --bs-pagination-bg: #fff;               /* $pagination-bg: $white */
  --bs-pagination-border-color: #e9ecef;
  --bs-pagination-hover-bg: #dee2e6;
  --bs-pagination-disabled-border-color: #e9ecef;
}

/* --bs-form-check-bg defaults to var(--bs-body-bg) on .form-check-input
   itself (Bootstrap 5.3), which front.css correctly points at the page grey
   (#e9ecef) -- but so does --bs-border-color, so the unchecked box's fill
   and border both resolved to the same #e9ecef as the page behind it and
   the box became invisible. $custom-control-indicator-bg: $gray-400 in the
   theme's Sass restores a visible, theme-correct fill. */
.form-check-input {
  --bs-form-check-bg: #ced4da;            /* $custom-control-indicator-bg: $gray-400 */
}

/* Bootstrap 5 hardcodes the checked state as literal colour values, not
   custom properties, so $custom-control-indicator-checked-bg: theme-color
   ("success") needs its own rule rather than a variable override. Used by
   the purchase-flow consent checkboxes (.large-checkbox). */
.form-check-input:checked {
  background-color: #28a745;
  border-color: #28a745;
}

.badge { --bs-badge-border-radius: .25rem; font-weight: 700; }

.progress {
  --bs-progress-bg: #ced4da;
  --bs-progress-border-radius: 200rem;
  height: auto;
}

.text-muted { color: rgba(108, 117, 125, .85) !important; }

/* ---- 4. Theme classes --------------------------------------------------- */
.bg-image { top: 0; left: 0; width: 100%; height: 100%; z-index: 0; }
.bg-image:not([class*='absolute']) { position: absolute; }
/* theme.css paired .bg-image with a sibling .card-body to lift it above the
   background image's paint order. Every hero/banner section in this codebase
   (template/default/home.tpl.php, widget-form-*.tpl.php, purchase_*-step-1,
   content/*.html) instead follows .bg-image with .container or
   .container-wide, which the theme selector never matched -- so the pairing
   was dead on arrival and every one of these sections has always painted its
   absolutely-positioned, z-index:0 .bg-image *above* the static, non-
   positioned .container next to it (CSS2.1 painting order: in-flow
   non-positioned content paints before positioned descendants at the same
   stack level, regardless of source order). That silently tinted all hero
   text with the background image's colour at its .opacity-* value --
   measured on /tr's hero heading: rendered pixel (255,181,184) pink instead
   of the true (255,255,255) white the text's own color/opacity computed to.
   This reads as "softer/lighter text" and is the real cause of that
   regression, not font smoothing (restored separately above, but confirmed
   to have zero visible effect on its own). Extending the pairing to the
   classes actually used restores true white: verified pixel-for-pixel
   against baseline/shots-head/home-tr-1440.png. */
.bg-image + .card-body,
.bg-image + .container,
.bg-image + .container-wide { position: relative; z-index: 1; }
img.bg-image { object-fit: cover; }

.height-60 { min-height: 60vh; }
.opacity-40 { opacity: .4; }
.opacity-60 { opacity: .6; }
.bg-dark2 { background-color: #000 !important; }
.o-hidden { overflow: hidden; }
.text-small { font-size: .875rem; }

.btn-image { height: 1.5rem; margin-right: .25rem; }
.btn-image + span { position: relative; top: 1px; }

.card.bg-dark.hover-effect:hover { background: #152a49 !important; }

[data-flickity].controls-inside .flickity-page-dots { position: absolute; bottom: 1.5rem; }
[data-flickity].controls-light .flickity-page-dots .dot { background: #fff; }

@media (min-width: 768px) {
  .position-md-absolute { position: absolute; }
  .height-md-30 { min-height: 30vh; }
}

@media (min-width: 992px) {
  .dropdown-menu-wide { width: 30rem; }
}