/**
 * Storefront fixes, both stores. ONE sheet, one request, loaded on every page - fold new small
 * fixes in here (as a new revision) rather than adding another render-blocking request.
 *   1. Arabic CMS heading alignment   - ClickUp 86d49xjg1 (CL038-DEV31 / REQ-86d49xjee), 2026-09-07
 *   2. Mobile CMS heading colour      - ClickUp 86d4a3c0f (CL038-DEV32 / REQ-86d4a38z6), 2026-09-08
 *   3. Arabic mobile menu-wrapper gap - requested 2026-09-08 (same session as 86d4a3c0f)
 *   4. Mobile CMS page top margin     - requested 2026-09-08 (same session as 86d4a3c0f); 30px in
 *                                       r4, changed to 0 in r5 the same morning
 *   5. Mobile CMS heading top margin  - requested 2026-09-08 (same session as 86d4a3c0f)
 *
 * FILENAME IS "-r5" ON PURPOSE (lineage: kwdup-cms-rtl.css -> kwdup-cms-rtl-r2.css ->
 * kwdup-cms-r3.css -> kwdup-storefront-r4.css -> this). Every revision so far went live and reached CloudFront and real
 * browsers before the next edit, and static is served max-age=31536000, so an in-place edit would
 * fix the edge and leave those browsers on the old bytes for a year. A new name has no cached
 * history. The superseded .min.css copies were deleted each time. Same rule for the NEXT edit:
 * ship -r6, do not overwrite. (r4's last two rules were the one exception: added within minutes of
 * r4 going live, overwritten in place + invalidated, because the log showed two edge fetches.)
 *
 * The "Content Heading" of every CMS page (privacy, warranty, about-us, shipping, ...) rendered
 * left-aligned on the Arabic store at >=768px while the page body sat correctly on the right.
 * Cause: styles-l.min.css carries `.cms-page-view .page-title-wrapper{text-align:left;padding:0 17px}`
 * (top-level, so it applies at every desktop width), and the RTL theme only sets `html{direction:rtl}`
 * in styles-m without overriding that explicit left. Mobile (<768px) never loads styles-l, so it was
 * already right-aligned - this sheet changes nothing there.
 *
 * WHY THIS LIVES IN kjest (the PARENT) AND IS SCOPED BY html[lang]:
 *   The obvious home is a layout file under kjestrtl, and that DOES NOT WORK on this install: the
 *   `theme` table has Magneto/kjestrtl registered as type=1 (VIRTUAL) even though it is a physical
 *   theme on disk with its own registration.php. The layout merger
 *   (framework/View/Model/Layout/Merge.php, _getPhysicalTheme) walks a virtual theme up to its nearest
 *   PHYSICAL ancestor and collects layout XML from that theme only, so any *.xml placed under
 *   kjestrtl/<Module>/layout/ is collected by the file collector and then silently ignored - which is
 *   why kjestrtl has never contained a single layout file. Templates, LESS and static files under
 *   kjestrtl are unaffected (normal fallback chain). Correcting the row (UPDATE theme SET type=0
 *   WHERE theme_id=5) was checked to be safe (the only other consumer, Config/FileResolver's view.xml
 *   merge, would add one unused image id) but was NOT applied in this ticket. Until it is, every
 *   store-specific layout change must live in kjest and be scoped like this one.
 *
 *   Magento emits <html lang="ar"> for the ar_SA locale (Page\Config::build() takes the part before
 *   "_") and <html lang="en"> for en_US, so `html[lang^="ar"]` selects the Arabic store and nothing
 *   else, with no dependency on which theme renders it.
 *
 * HAND-PLACED IN pub/static - THIS SOURCE FILE IS NEVER COMPILED OR DEPLOYED. Same regime as
 * kwdup-blog-r2.css next to it (read its header): Publisher::publish() returns early on an existing
 * target, so static-content:deploy neither overwrites nor regenerates the four deployed copies at
 *   pub/static/frontend/Magneto/{kjest,kjestrtl}/{ar_SA,en_US}/css/kwdup-storefront-r5.min.css
 * Only the .min name is ever requested (dev/css/minify_files=1). Minify with Magento's own lib:
 *   (new \tubalmartin\CssMin\Minifier())->run($src)
 * If this sheet ever needs editing after real traffic has cached it, ship it under a NEW name
 * (kwdup-storefront-r6.css) - static is max-age=31536000 and an in-place edit leaves returning
 * visitors on the old bytes for a year.
 *
 * WHY media="screen" ON THE <css> TAG (Magento_Theme/layout/default_head_blocks.xml): Magento buckets
 * head assets by their exact attribute set and renders the buckets in creation order
 * (View/Asset/GroupedCollection.php:108). "screen" is its own bucket, rendered AFTER styles-l
 * (media="screen and (min-width: 768px)"), so the rule below wins on plain source order with no
 * !important. Removing that attribute silently re-breaks the heading.
 *
 * Render-blocking on every page of both stores: keep it tiny, keep every selector anchored to a
 * body class.
 */

/* ------------------------------------------------------------------ *
 * 1. Arabic heading alignment (86d49xjg1).
 * ------------------------------------------------------------------ */
/* Heading follows the page direction again on the Arabic store. `right` rather than `start` so the
   intent is explicit. `padding: 0` (r2, requested by the client) drops the 17px side padding styles-l
   adds, so the heading sits flush with the page body, whose container has no padding either.
   Specificity (0,3,1) beats styles-l's (0,2,0) as well as winning on source order. */
html[lang^="ar"] .cms-page-view .page-title-wrapper {
    text-align: right;
    padding: 0;
}

/* ------------------------------------------------------------------ *
 * 2. Mobile heading colour, both stores (86d4a3c0f).
 *
 * The green comes from styles-l only:
 *   .cms-page-view .page-title-wrapper h1.page-title span{color:#8cc63f;...font-weight:600;...}
 * and styles-l carries media="screen and (min-width: 768px)", so below 768px nothing sets a colour
 * and the span inherits the body's #333. Desktop is untouched by this block (it already computes
 * #8cc63f there); the media query keeps the desktop cascade exactly as styles-l defines it.
 * Only the colour was requested - the mobile heading keeps its 19px / weight 300.
 * ------------------------------------------------------------------ */
@media only screen and (max-width: 767px) {
    .cms-page-view .page-title-wrapper h1.page-title span {
        color: #8cc63f;
    }
}

/* ------------------------------------------------------------------ *
 * 3. Arabic mobile: no gap above the (empty) mega-menu wrapper.
 *
 * The Arabic store gives section.ammenu-menu-wrapper `margin-top: 2em` (mena.css, and a
 * `html[lang=ar]` rule in styles-l for desktop). On mobile the wrapper is a 0-height block - the
 * menu lives behind the hamburger - so the 28px margin is nothing but a gap that pushes the whole
 * page down 27px further than the English store (177px vs 150px to the first content row).
 * Desktop keeps its 2em: the wrapper has real height there and the spacing is part of the layout.
 * `html[lang^="ar"]` (0,1,2) beats mena's bare `section.ammenu-menu-wrapper` (0,0,2) as well as
 * winning on source order.
 * ------------------------------------------------------------------ */
@media only screen and (max-width: 767px) {
    html[lang^="ar"] section.ammenu-menu-wrapper {
        margin-top: 0;
    }
}

/* ------------------------------------------------------------------ *
 * 4. Mobile: no space above CMS page content, both stores.
 *
 * styles-m has `.cms-page-view main#maincontent, ... { margin-top: 50px }` at every width. On
 * phones that is a 50px blank band between the header and the heading. r4 cut it to 30px; r5
 * removes it (section 5's 20px on the h1 is now the only spacing). Same selector and
 * specificity (1,1,1) as the styles-m rule - this sheet is later in the cascade, so source order
 * decides. Desktop is not touched (media query).
 * ------------------------------------------------------------------ */
@media only screen and (max-width: 767px) {
    .cms-page-view main#maincontent {
        margin-top: 0;
    }
}

/* ------------------------------------------------------------------ *
 * 5. Mobile: space between the header area and the CMS heading, both stores.
 *
 * On desktop styles-l gives `.cms-page-view h1.page-title` a padding-top (58px, then 12px); on
 * mobile the h1 has no top spacing of its own and sits directly on the 30px main margin
 * (section 4). 20px of margin on the h1 was requested. Specificity (0,3,1) beats styles-l's
 * `.cms-page-view h1.page-title` (0,2,1) - irrelevant on mobile anyway since styles-l does not load.
 * ------------------------------------------------------------------ */
@media only screen and (max-width: 767px) {
    .cms-page-view .page-title-wrapper h1.page-title {
        margin-top: 20px;
    }
}