/*
Theme Name: Sway Child
Template: sway
Theme URI: https://www.swaytheme.com/
Author: Key-Design
Author URI: http://themeforest.net/user/Key-Design
Description: Multi-Purpose WordPress Theme with Block Builder
Version: 1.0
Tags: one-column, two-columns, three-columns, four-columns, left-sidebar, right-sidebar, custom-menu, featured-images, flexible-header, post-formats, sticky-post, translation-ready

/* Below you can write your style */

/* ------------------------------------------------------------------
   Persian body font: IRANSansWeb, the font the theme itself bundles
   (themes/sway/fonts/) — client confirmed the marketplace license
   covers commercial use. Bound here directly instead of relying on
   themes/sway/rtl.css, which defines the same font but is never
   enqueued (confirmed: zero effect on the live site) and also binds
   a second, different font ("Yekan Bakh") under the identical family
   name at the same weight — a vendor bug that would silently replace
   normal-weight text with the wrong typeface. Not repeated here.
   See docs/decisions.md#d11 for the full history of this decision.
   ------------------------------------------------------------------ */
@font-face {
  font-family: 'IRANSansWeb';
  src: url('../sway/fonts/woff2/IRANSansWeb(FaNum)_UltraLight.woff2') format('woff2'),
       url('../sway/fonts/woff/IRANSansWeb(FaNum)_UltraLight.woff') format('woff');
  font-weight: 200;
  font-style: normal;
  font-display: swap;
}
@font-face {
  font-family: 'IRANSansWeb';
  src: url('../sway/fonts/woff2/IRANSansWeb(FaNum)_Light.woff2') format('woff2'),
       url('../sway/fonts/woff/IRANSansWeb(FaNum)_Light.woff') format('woff');
  font-weight: 300;
  font-style: normal;
  font-display: swap;
}
@font-face {
  font-family: 'IRANSansWeb';
  src: url('../sway/fonts/woff2/IRANSansWeb(FaNum).woff2') format('woff2'),
       url('../sway/fonts/woff/IRANSansWeb(FaNum).woff') format('woff');
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}
@font-face {
  font-family: 'IRANSansWeb';
  src: url('../sway/fonts/woff2/IRANSansWeb(FaNum)_Medium.woff2') format('woff2'),
       url('../sway/fonts/woff/IRANSansWeb(FaNum)_Medium.woff') format('woff');
  font-weight: 500;
  font-style: normal;
  font-display: swap;
}
@font-face {
  font-family: 'IRANSansWeb';
  src: url('../sway/fonts/woff2/IRANSansWeb(FaNum)_Bold.woff2') format('woff2'),
       url('../sway/fonts/woff/IRANSansWeb(FaNum)_Bold.woff') format('woff');
  font-weight: 700;
  font-style: normal;
  font-display: swap;
}
@font-face {
  font-family: 'IRANSansWeb';
  src: url('../sway/fonts/woff2/IRANSansWeb(FaNum)_Black.woff2') format('woff2'),
       url('../sway/fonts/woff/IRANSansWeb(FaNum)_Black.woff') format('woff');
  font-weight: 900;
  font-style: normal;
  font-display: swap;
}

body, p, a, button, input, textarea, select,
h1, h2, h3, h4, h5, h6,
.navbar, .menubar, #logo .logo, .topbar {
  font-family: 'IRANSansWeb', -apple-system, BlinkMacSystemFont, 'Segoe UI', 'Helvetica Neue', sans-serif !important;
}

/* ------------------------------------------------------------------
   Page title bar / breadcrumb: default alignment.
   Was "right" (an RTL fix copied from the dead themes/sway/rtl.css,
   see docs/decisions.md#d11) — corrected to "center" per
   docs/decisions.md#d17: the site's real convention (confirmed via
   the Contact and About pages' own keydesign_page_title_align meta,
   both explicitly "center") is centered, not right-aligned. This
   default now makes any page WITHOUT that meta set (e.g. a newly
   created one) match automatically, instead of needing the meta set
   by hand on every page. Still safe unconditionally: a page with its
   own explicit alignment (.blog-title-center / .blog-title-left) sets
   text-align directly on its own inner element, which always wins
   over this ancestor's value regardless of !important.
   ------------------------------------------------------------------ */
.entry-header {
  text-align: center !important;
}

/* ------------------------------------------------------------------
   Consistent spacing between stacked page sections (not blog posts/
   archives — scoped to body.page). Adds space only; never removes an
   existing row's own padding, so the failure mode is "slightly more
   breathing room," not overlap. Excludes inner rows (.vc_inner, e.g.
   icon-box grids) so it doesn't touch nested layouts.
   See docs/decisions.md#d16.
   ------------------------------------------------------------------ */
body.page .vc_row:not(.vc_inner) + .vc_row:not(.vc_inner) {
  margin-top: 30px;
}

/* ------------------------------------------------------------------
   Equal-height cards in an icon-box row. WPBakery's native
   equal_height="yes" row option (already used on these rows — see
   docs/decisions.md#d18) makes the invisible column heights match
   via its own .vc_row-flex CSS (already shipped in js_composer, not
   added here). It stops one level too early for this theme's
   tek_iconbox output though: the visible bordered box (.key-icon-box)
   is nested two wrappers deeper and doesn't inherit that stretch on
   its own. This fills the gap so the actual card border — not just
   the invisible column — stretches to match its tallest sibling.
   ------------------------------------------------------------------ */
.vc_row-flex .wpb_wrapper {
  display: flex;
  flex-direction: column;
  height: 100%;
}
.vc_row-flex .wpb_wrapper .key-icon-box {
  flex: 1;
}

/* ------------------------------------------------------------------
   Main nav: item order/dropdown position was still LTR (float:left,
   copied from Bootstrap's own default, since themes/sway/rtl.css —
   which has a float:right fix for this exact thing — is dead code,
   see docs/decisions.md#d11). Client caught it via screenshot: the
   "مقالات" dropdown opened toward the left with a visible gap between
   it and its own trigger, instead of hugging it and opening into the
   page (client's own words: "the sub menu is left side").
   Confirmed via source: bootstrap.min.css sets BOTH
   `.navbar-nav{float:left}` and `.navbar-nav>li{float:left}` at the
   1270px desktop breakpoint (Bootstrap 3, not flexbox — no flex
   ancestor found, so float direction is what actually controls this).
   rtl.css only ever had a fix for the second one; this mirrors both,
   so the whole item row - and each dropdown anchored to its own
   trigger via the theme's own `right:-16px` rule - reads right-to-left
   consistently. See docs/decisions.md#d27.
   ------------------------------------------------------------------ */
@media (min-width: 1270px) {
  .navbar-nav {
    float: right;
  }
  .navbar-nav > li {
    float: right;
  }
}

/* ------------------------------------------------------------------
   Same nav, second half of the report (D27 fixed item order). D28/D30/
   D31 chased the dropdown BOX's position (right:-16px -> left:-16px ->
   left:0 -> centered) across 3 rounds and never actually nailed it —
   because the box's position was never the real bug. Client found the
   actual cause via DevTools: the dropdown's own `<li>` items inherit
   `text-align:left` (Bootstrap's `.dropdown-menu` base rule), so the
   Persian item text renders flush against the box's LEFT edge — which
   reads as "the whole menu is stuck on the left" even when the box
   itself is positioned fine, because the visible text is what your eye
   actually tracks, not the (unstyled, same-color-as-page) box edge.
   Reverted all 3 rounds of box-position guessing back to the theme's
   own untouched default (right:-16px) and fixed the actual cause
   instead. See docs/decisions.md#d32.
   ------------------------------------------------------------------ */
#main-menu .navbar-nav .dropdown-menu li {
  text-align: right;
}

/* ------------------------------------------------------------------
   Standing rule (client's explicit instruction, 2026-09-11, revised
   2026-09-15): text inputs/textareas stay right-aligned always.
   Originally (D40) this used `unicode-bidi: plaintext` to auto-switch
   a field to LTR alignment the moment someone typed LTR content (an
   email address, a phone number) — client reviewed that behavior live
   and asked for every input to stay right-aligned all the time
   instead, including email/phone once something's typed into them.
   `direction: rtl` alone (no `unicode-bidi: plaintext`) does that: form
   controls don't reliably inherit `direction` from the page the way
   ordinary elements do, so it has to be set directly here rather than
   relying on inheritance, but once set directly it holds regardless of
   what's typed — a mixed-content run (e.g. a Latin email address) still
   reads left-to-right correctly within itself via normal bidi character
   reordering, it just no longer flips the whole field's alignment. See
   docs/decisions.md#d40 (original) and #d44 (this revision).

   Two rule blocks, not one — two separate vendor sources fight this,
   found one at a time (decisions.md#d44):
   1. The **parent Sway theme**'s style.css ships `.wpcf7 .wpcf7-text,
      .wpcf7 .wpcf7-email, ...{text-align:left}` (2 class selectors,
      specificity 0,2,0).
   2. The **Contact Form 7 plugin**'s own styles.css (a THIRD file,
      separate from the theme entirely) ships `.wpcf7 input[type="url"],
      .wpcf7 input[type="email"], .wpcf7 input[type="tel"]
      {direction:ltr}` (.wpcf7 class + input element + [type] attribute
      = specificity 0,2,1) — missed on the first pass because that pass
      only searched for `text-align` conflicts, not `direction` ones;
      re-checked both properties together, across every enqueued
      stylesheet, before trusting this was complete the second time.
   A selector matching either vendor rule's exact shape would only tie,
   and CF7's plugin CSS is enqueued AFTER child-style.css (functions.php
   only controls load order relative to the PARENT theme, not plugins),
   so a tie there would go to CF7, not here. Rather than depend on load
   order at all, the second block below uses a strictly MORE specific
   selector — `.wpcf7` ancestor + the two real classes CF7 puts directly
   on the field (`wpcf7-form-control` + the type-specific class, e.g.
   `wpcf7-email`) = 3 class-equivalents (0,3,0) — which beats both
   vendor rules (0,2,0 and 0,2,1) outright, regardless of file load
   order, since specificity is compared class-level before element-level
   and 3 > 2 settles it there. No `!important` needed. The first block
   still covers any non-CF7 input on the site (e.g. the header search
   box) that the second block's `.wpcf7` scope doesn't reach.
   ------------------------------------------------------------------ */
input[type="text"],
input[type="email"],
input[type="tel"],
input[type="number"],
input[type="search"],
input[type="url"],
textarea {
  direction: rtl;
  text-align: right;
}
.wpcf7 .wpcf7-form-control.wpcf7-text,
.wpcf7 .wpcf7-form-control.wpcf7-email,
.wpcf7 .wpcf7-form-control.wpcf7-tel,
.wpcf7 .wpcf7-form-control.wpcf7-number,
.wpcf7 .wpcf7-form-control.wpcf7-url,
.wpcf7 .wpcf7-form-control.wpcf7-textarea,
.wpcf7 .wpcf7-form-control.wpcf7-select {
  direction: rtl;
  text-align: right;
}