/* Not part of the legacy theme -- added to fix a measured PageSpeed Insights CLS regression
   (1.261, should be well under 0.1). Cause: the legacy theme never reserves space for card
   images (no width/height/aspect-ratio anywhere), so every image shifts the layout as it loads.
   Source photos are arbitrary editor uploads with no known dimensions ahead of time, so a fixed
   width/height per image isn't possible -- reserving a fixed aspect-ratio box per card type and
   cropping into it with object-fit is the standard, deterministic fix recommended for this exact
   Lighthouse diagnostic. Loaded after style.css so these rules win. */

.blog-image img,
.single-default-news > img,
.single-fashion-news > img,
.single-popular-news .news-image img,
.single-more-news > img,
.article-img img {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
  object-fit: cover;
}

.single-default-inner-news .news-image img,
.single-gallery-box img {
  aspect-ratio: 4 / 3;
  width: 100%;
  height: auto;
  object-fit: cover;
}

/* Legacy generated a purpose-sized "thumbnail1" variant for this narrow-column row layout
   (measured 126x80 = ~1.575 ratio, a wide rectangle) -- we don't have an equivalent thumbnail
   pipeline, so this renders the original full-size image cropped into that same box via
   object-fit instead. Was guessed as a 1:1 square without checking the legacy thumbnail's actual
   proportions, which visibly cropped photos wrong (portraits/faces especially) compared to the
   original site. Corrected to match. */
.category-news-image img {
  aspect-ratio: 126 / 80;
  width: 100%;
  height: auto;
  object-fit: cover;
}

/* Owl Carousel's own CSS sets ".owl-carousel { display: none }" until JS adds "owl-loaded" -- and
   that JS only runs after hydration (deliberately, to avoid a hydration-mismatch bug), i.e. after
   first paint. So the carousel goes from occupying zero space to full space right after the page
   is visible, which is a huge, unavoidable-by-image-sizing-alone layout shift (this is the actual
   dominant CLS source, not image sizing, which is why fixing image aspect-ratio alone wasn't
   enough). Fix: show the natural, un-stacked first slide before JS runs, closely approximating
   final size, instead of reserving zero space.
   IMPORTANT: every rule below that hides/sizes the original slide elements MUST be scoped with
   ":not(.owl-loaded)" on the carousel root. An earlier version assumed owl-carousel's DOM
   restructuring on init would naturally stop these selectors from matching once loaded -- wrong:
   it left the carousel permanently stuck showing only one slide in production, because whatever
   owl actually does with the DOM, the original ":not(:first-child)" selector kept matching.
   Gating on ".owl-loaded" (the class owl-carousel itself adds on successful init, confirmed in
   owl.carousel.min.css) is the same technique owl's own CSS uses and doesn't depend on any
   assumption about internal DOM structure -- once that class is present, every rule below stops
   applying and owl's own styling fully takes over. */
.blog-home-slides.owl-carousel,
.popular-news-slides.owl-carousel,
.more-news-slides.owl-carousel {
  display: block;
  overflow: hidden;
}
.blog-home-slides.owl-carousel:not(.owl-loaded) > *:not(:first-child),
.popular-news-slides.owl-carousel:not(.owl-loaded) > *:not(:first-child),
.more-news-slides.owl-carousel:not(.owl-loaded) > *:not(:first-child) {
  display: none;
}

/* The above alone still left a large shift: none of these slide elements carry a width rule of
   their own (they normally rely entirely on owl-carousel's JS to size them), so showing the first
   one pre-init made it render at 100% of the container's width -- e.g. a full ~1200px-wide, tall
   16:9 box -- and then it visibly shrank down to owl's actual per-item width (1/2 or 1/3 of the
   container, per the "responsive" breakpoints in ThemeReinit.tsx) the moment JS initialized. That
   100%-to-33% width collapse (and the height collapse that comes with it, since the image inside
   keeps a fixed aspect-ratio) was the dominant remaining shift. Constraining the visible first
   item to the same width owl will use at each breakpoint makes the pre- and post-init sizes match,
   so there's nothing left to visibly shift. (Specificity note: for more-news-slides the direct
   child is a Bootstrap ".col-lg-12" div -- this 4-class-selector rule outweighs that 1-class rule,
   so it wins without needing !important.) */
.blog-home-slides.owl-carousel:not(.owl-loaded) > *:first-child,
.popular-news-slides.owl-carousel:not(.owl-loaded) > *:first-child,
.more-news-slides.owl-carousel:not(.owl-loaded) > *:first-child {
  width: 100%;
}
@media (min-width: 576px) {
  .blog-home-slides.owl-carousel:not(.owl-loaded) > *:first-child {
    width: 50%;
  }
}
@media (min-width: 768px) {
  .popular-news-slides.owl-carousel:not(.owl-loaded) > *:first-child,
  .more-news-slides.owl-carousel:not(.owl-loaded) > *:first-child {
    width: 50%;
  }
}
@media (min-width: 1200px) {
  .blog-home-slides.owl-carousel:not(.owl-loaded) > *:first-child,
  .popular-news-slides.owl-carousel:not(.owl-loaded) > *:first-child,
  .more-news-slides.owl-carousel:not(.owl-loaded) > *:first-child {
    width: 33.3333%;
  }
}

/* PageSpeed's "touch targets" audit: the header social icons had no explicit hit area, just a
   small icon glyph with 7px between links. Expand the tappable area via padding (not changing
   the icon's visual size) and enough spacing to meet the ~24px minimum + no overlap. */
.top-header .top-social li {
  margin-right: 2px;
}
.top-header .top-social li a {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  min-width: 28px;
  min-height: 28px;
  padding: 4px;
}

/* The breaking-news marquee's star separator was a legacy <a href="#"> (accessibility issue --
   see BreakingNewsMarquee.tsx); swapped to a <span>, which needs the same color explicitly since
   style.css's ".breaking-news-right ul li a" rule only targets anchors. */
.breaking-news-right ul li span {
  color: #fff;
}

/* Found the real bug behind the whole "mobile background missing" saga: our ported style.css's
   ".header-area" rule (the outer wrapper around the whole header, used on every viewport) was
   missing its "background: url(...headbg.png)" line -- only "padding-bottom: 25px" survived the
   port. Restored directly in style.css to match the legacy source exactly, which covers mobile
   and desktop uniformly with no per-breakpoint override needed here at all. */

/* Complaint Redressal (src/app/complaint-redressal/page.tsx) was originally its own standalone
   HTML file with a page-specific <style> block for the grievance-cell table and text -- that CSS
   was never part of the shared theme. Ported here scoped to ".contact-area" (this page's own
   wrapper) rather than the original's bare "table"/"p"/"h3" selectors, which would have overridden
   those elements site-wide. */
.contact-area .table table th {
  border: 1px solid #dcdcdc;
  background: #f6f6f6;
  padding: 20px;
  text-align: left;
}
.contact-area .table table td {
  border: 1px solid #dcdcdc;
  padding: 10px 20px;
}
.contact-area .text-wrap p {
  font-family: Roboto, sans-serif;
  font-size: 18px;
  line-height: 28px;
  padding-bottom: 18px;
}
.contact-area .text-wrap h3 {
  margin-bottom: 20px;
  font-size: 24px;
  line-height: 32px;
  text-transform: uppercase;
}

/* Redesign of the shared contact form (ContactForm.tsx, used on both Contact Us and Complaint
   Redressal): the legacy inputs were plain bordered boxes with no spacing, focus state, or card
   framing, and the submit button was a flat rectangle with no hover feedback. */
.contact-form {
  background: #fff;
  padding: 30px;
  border-radius: 12px;
  box-shadow: 0 4px 24px rgba(0, 0, 0, 0.08);
}
.contact-form .form-group {
  margin-bottom: 22px;
}
.contact-form .form-control {
  height: auto;
  padding: 13px 18px;
  font-size: 15px;
  border: 1px solid #e4e4e4;
  border-radius: 8px;
  background: #fafafa;
  transition: border-color 0.2s ease, box-shadow 0.2s ease, background 0.2s ease;
}
.contact-form .form-control:focus {
  border-color: #d72924;
  background: #fff;
  box-shadow: 0 0 0 3px rgba(215, 41, 36, 0.12);
  outline: none;
}
.contact-form textarea.form-control {
  min-height: 160px;
  resize: vertical;
}
.contact-form .btn-primary {
  padding: 13px 42px;
  border-radius: 8px;
  border: none;
  font-weight: 600;
  letter-spacing: 0.4px;
  transition: background-color 0.2s ease, transform 0.15s ease, box-shadow 0.2s ease;
}
.contact-form .btn-primary:hover:not(:disabled) {
  background-color: #b81f1b;
  transform: translateY(-1px);
  box-shadow: 0 6px 16px rgba(215, 41, 36, 0.25);
}
.contact-form .btn-primary:disabled {
  opacity: 0.65;
}

/* Desktop's nav is a plain LTR flex row (verified via computed styles -- no RTL flip involved).
   "Home" is deliberately the LAST item in the DOM so it lands in the rightmost slot, which is the
   FIRST thing an Urdu (right-to-left) reader's eye hits. That trick only works for a horizontal
   row -- it has no equivalent in a vertical list, so meanmenu's mobile menu (which floats each <li>
   at 100% width, stacking in literal DOM order) was showing Home at the very bottom instead of a
   prominent first position. Converting the top-level mobile list to a flex column reproduces the
   same full-width vertical stacking the float layout gave it, but lets "order" pull Home back to
   the front -- without touching the DOM order that desktop's layout correctly depends on. Scoped
   to ONLY the top-level list ("> ul", not "ul") so nested dropdown submenus are untouched. */
.mean-container .mean-nav > ul {
  display: flex;
  flex-direction: column;
}
.mean-container .mean-nav > ul > li:has(> a[href="/"]) {
  order: -1;
}

/* Home page's ".single-default-inner-news" cards (the pair shown under the featured top story)
   were just given a "col-6" so the two sit side by side on mobile instead of stacking full-width
   -- but responsive.css's mobile ".news_left"/".news_right" split (25%/75%, designed for the
   text+thumbnail list rows that share these class names, e.g. ".single-category-news") was still
   active, so each already-halved card's image was squeezed into just 25% of that half (12.5% of
   the row) next to a big blank 75% gap. This card type has no text at all (see
   DefaultInnerNewsCard in PostCard.tsx -- ".news_right" is always an empty div), so on mobile the
   image should simply fill the whole card, same as it already does on desktop. */
@media only screen and (max-width: 768px) {
  .single-default-inner-news .news_left {
    width: 100%;
    float: none;
  }
  .single-default-inner-news .news_right {
    display: none;
  }
}