/**
* Header, footer, containers and section spacing.
*
* Restyles Storefront's existing header/footer/menu markup — no new
* markup or nav walker is introduced in Phase 1.
*/
.col-full {
max-width: var(--container-max);
}
/* Header — 0.2.0-dev.4: dark "chrome" redesign (client's own explicit
brief). Only the header BAR itself (background + top-level link/icon
colours) goes dark — the mega-menu dropdown panels and the mobile
drawer are UNCHANGED, still their existing light theme (client's own
"conserver tous les méga-menus actuels" instruction), a common, standard
pattern (dark trigger bar, light dropdown content) that needed no
changes to the panels' own already-hard-won CSS (see this file's many
Storefront-collision fixes below, none of them touched this round). */
/* 0.1.26: position was originally just "relative" — needed as a real
positioned ancestor (.cristaline-mega-menu's own position:absolute
anchors here) once ".storefront-primary-navigation" became
display:contents and stopped being a box at all.
0.2.0-dev.4: promoted to "sticky" (still a positioned ancestor, so the
mega-menu anchoring above is unaffected — sticky/relative/absolute/fixed
all equally qualify as a containing block per spec) — the client's own
"header sticky, léger et fluide" ask. A modest, ALWAYS-present shadow
(rather than one toggled by a scroll-position JS listener) reads the
same as "une ombre après défilement" in practice while staying pure
CSS, no new JS dependency; position:sticky itself never causes a layout
jump (unlike position:fixed, it never leaves a gap in normal flow when
it engages). */
.site-header {
background-color: var(--color-chrome-bg);
border-bottom: 1px solid var(--color-chrome-border);
box-shadow: 0 2px 12px rgba(0, 0, 0, .18);
position: sticky;
top: 0;
z-index: 100;
}
/* WordPress admin bar: 32px tall at >=783px, 46px below it (its own real
breakpoint, not this theme's) — confirmed against WordPress core's own
admin-bar.css rather than assumed. Without this, the sticky header would
sit UNDER the admin bar once scrolled instead of just below it. */
body.admin-bar .site-header {
top: 32px;
}
@media (max-width: 782px) {
body.admin-bar .site-header {
top: 46px;
}
}
/* 0.1.25: real, previously-undocumented bug — a 4th instance of the same
pattern 0.1.24 already found once for the cart alone. Storefront's own
".woocommerce-active .site-header .X { width: 21.74% or 73.91%; float;
clear }" (specificity 0,3,0, from its own @media(min-width:768px) block,
with no upper bound) applies to FOUR elements this theme lays out with
flexbox instead: .site-branding, .site-search, .main-navigation
(#site-navigation) and .site-header-cart. Only the cart instance was ever
caught (0.1.24) because the other three were simply hidden below 1280px
at the time and never exercised. Confirmed live this round: with search/
cart/account shown again (the 0.1.25 compact-tier fix below),
#site-navigation itself was rendering at a hardcoded 73.913% of its
row — 906px on a 1232px-wide row — silently, at EVERY width from 768px
up, including the existing >=1280px desktop tier, where it happened not
to visibly break anything only by coincidence of today's exact pixel
math (justify-content:space-between still pushed the account link to the
row's real right edge regardless of how wide nav's own invisible box
claimed to be). Reset unconditionally here (Storefront's own rule has no
upper bound either) — same specificity (0,3,0) + later source order
(this stylesheet is enqueued after Storefront's) is enough to win. */
/* 0.1.26: real bug, confirmed live — with branding/search/nav/cart all
now bubbled into .site-header's own grid via display:contents (see the
header-grid block below), the plain (no-!important) version of this
override — which had worked fine since 0.1.25 — stopped reliably
beating Storefront's native ".woocommerce-active .site-header .X {
width: %; float }" rules for these specific elements once they became
grid items this way. Confirmed live via getBoundingClientRect (e.g.
#site-navigation measured 946px = exactly 73.913% of its real 1280px
grid track, the cart measured 27px = exactly 21.7391% of its own
narrow grid column, with the plain override in place and doing
nothing) before reaching for !important. The two rules are tied in
specificity (0,3,0) and this stylesheet still loads after Storefront's
own, so by the ordinary cascade this should never have been necessary
— given it demonstrably was, for every one of these 4 elements, once
they moved from being flex items to being grid items spanning a
display:contents ancestor chain, !important here is a deliberate,
narrowly-scoped safety net (this exact selector list only), not a
general pattern to reach for elsewhere in this file. */
.woocommerce-active .site-header .site-branding,
.woocommerce-active .site-header .site-search,
.woocommerce-active .site-header .main-navigation,
.woocommerce-active .site-header .site-header-cart {
clear: none !important;
float: none !important;
margin-right: 0 !important;
width: auto !important;
}
/* =========================================================
0.1.27: the header grid below now applies at EVERY width, including
<768px — real bug, confirmed live (0.1.25/0.1.26's own mobile header
was 150.7px tall on a real measurement, vs the ~100-130px the client
asked for this round). Root cause: mobile used a SEPARATE, older
flex-row system (".site-header > .col-full" as its own flex row for
the logo, ".storefront-primary-navigation" as ANOTHER flex row below
it for the hamburger) — two stacked rows, each with their own vertical
padding, left over from when that row also needed to fit
search/cart/account. Once those are hidden below 768px (unchanged),
the row only ever contains ONE thing (the logo, or the hamburger) —
there was never a real reason for two rows once that happened; 0.1.26
just didn't revisit it while focused on the 768–1279px compact tier.
Folding mobile into the same shared grid means logo and hamburger sit
on ONE row like every other tier, and removes an entire redundant
layer of padding. See the 3 media queries below the shared block for
what actually differs per tier now — just grid-template-areas/columns,
nothing structural.
========================================================= */
/* =========================================================
0.1.26: header grid (shared by every tier — see the 3 breakpoint-
specific blocks below for what differs).
The client asked for logo/search/account/cart to share ONE row with
the horizontal nav on a second row, all sharing one common centered
container — but account/cart are rendered by Storefront core
(storefront_header_cart) and this theme's own account-link hook inside
a SEPARATE wrapper (".storefront-primary-navigation", opened at
priority 42, closed at 68) from the one branding/search render inside
(the first ".col-full", opened at priority 0, closed at 41) — two
different DOM subtrees, un-reachable from each other with CSS alone.
Fixed with real WordPress hook-priority changes (inc/header-footer.php,
0.1.26): storefront_header_cart moved from 60 to 40.4, and this theme's
own account-link hook from 61 to 40.6 — both now render inside the
FIRST ".col-full", right after storefront_product_search (40), as real
siblings of branding/search. Verified against the real Storefront 4.6.2
function bodies first (see that file's own docblock) — both are fully
self-contained, no dependency on which wrapper renders them.
#site-navigation (nav + hamburger toggle) still can't move that way —
its own hook (storefront_primary_navigation, 50) sits inside a chain of
TWO Storefront-controlled wrappers this theme can't safely relocate
(storefront_primary_navigation_wrapper's own two nested divs). Instead,
both of those wrappers are set to display:contents below — they stop
being boxes, but their real children (#site-navigation, and the 3
.cristaline-mega-menu panels rendered right after it at priority 51)
become direct participants of the SAME grid as branding/search/cart/
account, exactly as if they'd always been siblings.
Important correction made while verifying this live: display:contents
only flattens an element into ITS OWN PARENT's box tree — it can't
reach across to a SIBLING's grid. ".storefront-primary-navigation" and
".site-header > .col-full" are SIBLINGS (both direct children of
".site-header"), so making only ".storefront-primary-navigation"
contents made #site-navigation bubble up to become a direct child of
".site-header" — NOT a grid item of the OTHER ".col-full" next to it
(confirmed live: #site-navigation rendered as a plain block, ignoring
its own grid-area entirely, before this was caught). The fix is
".site-header" itself is the real grid container — BOTH ".col-full"s
(branding/search's and the nav wrapper's) are display:contents, so
every named item bubbles up exactly one level to become a direct grid
child of the same element. ".site-header" keeps its own full-width
background/border (a real box, display:grid doesn't remove that) — the
old "full-width outer bar, centered inner content" effect it used to
get from ">.col-full"'s own max-width+margin:auto is reproduced with
max()-based padding instead (see below), since ".col-full" itself is no
longer a real box to hold that max-width at this breakpoint.
The mega-menu panels are position:absolute regardless of what
display:contents does to their ancestors (per spec, an out-of-flow
element is never a flex/grid item, contents ancestors or not) — they
just needed a new containing block once ".storefront-primary-
navigation" stopped being one, which is why .site-header itself is
position:relative now (see above).
0.1.27: unconditional now (was ">=768px" only) — see the big comment
further up for why: mobile needed the exact same "one shared grid, no
redundant stacked rows" treatment once its own old 2-row flex system
turned out to be the cause of the excessive mobile header height. The
max()-based padding formula below already degrades correctly at
narrow widths on its own (the calc() side goes negative/zero below
--container-max, so max() always falls back to the flat var(--space-6)
minimum) — no separate mobile-specific padding rule was needed. */
.site-header > .col-full,
.storefront-primary-navigation,
.storefront-primary-navigation > .col-full {
display: contents;
}
.site-header {
align-items: center;
column-gap: var(--space-4);
display: grid;
/* max() keeps a real minimum side margin at every width narrower than
--container-max (where the calc() side alone would go negative/
zero) while still centering a --container-max-wide content area
once the viewport is wider than that — the same effect ">.col-full"'s
own max-width + margin:0 auto used to give, expressed as padding on
the full-width element instead since ".col-full" is display:contents
now and can't hold that itself. */
padding: var(--space-4) max(var(--space-6), calc((100% - var(--container-max)) / 2));
row-gap: var(--space-3);
}
.site-branding {
grid-area: logo;
}
.site-search {
grid-area: search;
}
.cristaline-header-social {
grid-area: social;
}
/*
* 0.2.0-dev.50 — real, root-cause fix for this round's own "icônes
* flottantes... dans la zone du hero/header mobile" report: the <768px
* mobile tier's own grid-template-areas ("logo . nav", see that tier's own
* block further down) has never named a "social" area at all, so
* `.cristaline-header-social`'s `grid-area: social` above simply can't
* resolve there — CSS Grid's own spec-defined behaviour for a named area
* that doesn't exist in the CURRENT template is to fall back to normal
* auto-placement, landing the element wherever the algorithm finds free
* grid space instead of respecting the intended layout, which is exactly
* what an unpredictable "floating" position looks like. `display: none`
* here is unconditional and explicit below the real desktop tier (1280px,
* where the header's own explicit line-based placement already handles it
* correctly, see that tier's own ".site-header .cristaline-header-social"
* rule) — robust regardless of what any narrower tier's own
* grid-template-areas string does or doesn't name, rather than relying on
* every tier remembering to account for this one item. Client's own
* explicit ask this round: the header's own social icons are desktop-only;
* mobile/tablet visitors reach the same two links via the mobile drawer's
* own "Suivez-nous" block and the footer, both already real, working, and
* unaffected by this change.
*/
@media (max-width: 1279px) {
.cristaline-header-social {
display: none;
}
}
.site-header-cart {
grid-area: cart;
}
.cristaline-account-link {
grid-area: account;
/* the old flex-row gap (--space-4) handled this before; the grid's
own column-gap does now — an extra margin here would just double
the visual space between cart and account. */
margin-left: 0;
}
#site-navigation {
grid-area: nav;
}
/* 0.1.27: mobile tier (<768px) — logo and hamburger share ONE row (the
real fix for the excessive-height bug above); search/cart/account stay
hidden here (see the existing <767px visibility rule further down),
so they never occupy the empty "." column — it's purely a spacer that
keeps the hamburger pinned to the right edge regardless. */
@media (max-width: 767px) {
.site-header {
grid-template-areas: "logo . nav";
grid-template-columns: auto 1fr auto;
/* real bug, confirmed live — even with a single explicit row, the
grid still reports a 2nd, empty implicit row ("88px 0px"), and
the shared block's row-gap (needed for the 2-row compact/desktop
tiers) was still adding a full 12px of unwanted extra height for
a gap that has nothing real on either side of it at this tier.
Zeroed here — directly responsible for part of the excessive
mobile-header-height bug fixed this round (133px measured with
the gap live, 121px without it, before any of the other fixes in
this same round were even applied). */
row-gap: 0;
/* 0.2.0-dev.3: this round's own explicit "conserver le logo à
environ 95–110px de largeur" (see the logo rule below, 72px ->
100px) pulls the header height back UP unless padding compensates
— tightened further, var(--space-3) (12px) -> var(--space-2)
(8px). 0.2.0-dev.6: tightened once more, 8px -> 6px (client's own
"réduire légèrement la hauteur du header mobile" ask) — still
comfortable padding around the 100px logo and the 56×56px
hamburger (well above the 44×44px minimum tap target on its
own), just not as generous. Still purely padding + content, no
fixed/forced height. Horizontal padding (the max() term)
untouched. */
padding-top: 6px;
padding-bottom: 6px;
}
}
/* Compact tier (768–1279px) — MODE B: logo left, cart/account/hamburger
right on row 1 (the empty "." column absorbs the space between); a
full-width search on row 2.
0.2.0-dev.50 — "social" removed from this tier's own template: client's
own explicit "supprimer les icônes flottantes... dans la zone du hero/
header mobile" report this round, confirmed as a real, previously-
unnoticed CSS Grid bug rather than assumed — this tier's own
grid-template-areas already never included "social" for the <768px tier
below it (only "logo . nav"), but DID still include it here; the real
floating-icon symptom traced to the OTHER tier: with no "social" NAMED
AREA at all in the <768px template, `.cristaline-header-social`'s own
`grid-area: social` (assets/css/layout.css, shared block above) can't
resolve, and CSS Grid's own auto-placement algorithm places it wherever
it finds room instead — a real, spec-correct explanation for content
rendering in an unexpected, "floating" position, not a vague guess. Fixed
at the root with an explicit `display: none` below 1280px (see that rule
further down) — robust regardless of what any tier's own
grid-template-areas string does or doesn't name — and this tier's own
template tidied to match (one fewer `auto` column) so it isn't left
referencing an area that's now unconditionally hidden anyway. */
@media (min-width: 768px) and (max-width: 1279px) {
.site-header {
grid-template-areas:
"logo . cart account nav"
"search search search search search";
grid-template-columns: auto 1fr auto auto auto;
}
}
/* Desktop tier (>=1280px) — 0.2.0-dev.4: collapsed from the old 2-row
layout (logo/search/social/cart/account on row 1, nav spanning a full
row 2 below) to ONE shared row — the client's own explicit "une seule
zone visuelle cohérente : logo à gauche, navigation au centre, outils à
droite" ask, rather than the previous stacked-bar look. The nav column
is the only 1fr track (was search before); nav's own ul.nav-menu is
centered within it so the 9 items read as a centered block, not
left-pinned.
Real, live-measured constraint (not guessed): with all 9 real top-level
items (Accueil/Nouveautés/Femme/Homme/Enfants/Marques/Boutiques/Bons
cadeaux/Contact) + a permanently-open ~150-210px search field + 2 social
icons + cart + account sharing this one row at exactly 1280px, the nav
text wraps to a second line — confirmed via getBoundingClientRect() on
the real production DOM/fonts, not assumed from reading the CSS. Shaving
nav font-size/padding down far enough to force a fit left only a ~9px
safety margin at the exact 1280px minimum, before even accounting for
the logo's own real target width this round (100-125px, up from the
96px this was measured against) eating further into it — exactly the
"just barely fits" fragility this project's own history repeatedly
warns about (a future menu-label edit or a 10th item would break it
again with no warning). Solved by collapsing the search field itself to
its own ~40px icon-button width by default instead (assets/js/
header-search.js toggles ".is-open" on click, focusing the real input)
— the client's own explicitly offered alternative ("icône de recherche
ouvrant un champ propre"), and it reclaims ~110-170px outright rather
than fighting for single-digit pixels. See the .site-search rules
further down this file (grep "0.2.0-dev.4: collapsed search") for the
collapse/expand styling itself — kept with the OTHER .site-search tier
rules rather than duplicated here, so its 3 tiers (mobile-hidden/
compact-full-width/desktop-collapsed) stay next to each other. */
@media (min-width: 1280px) {
.site-header {
/* Tightened from the shared block's own var(--space-4)/16px — live-
measured headroom (see the big comment above) needed this to
comfortably clear 9 real items + logo + collapsed search + social
+ cart + account on one row at exactly 1280px; 10px still reads
as deliberate spacing, not cramped. */
column-gap: 10px;
grid-template-areas: "logo nav search social cart account";
grid-template-columns: auto 1fr auto auto auto auto;
/* 0.2.0-dev.5: REAL BUG fixed here, found live via the client's
header-height report. getComputedStyle() showed THREE row tracks
("Npx 0px 0px") for what's declared as a single-row
grid-template-areas string — root cause not fully isolated (every
candidate extra grid item tested — the 3 hidden .cristaline-mega-menu
panels, the mobile drawer, the skip-links — was removed one at a
time and NONE of them was the cause, even combined), but two
phantom 0-height implicit rows are reliably present regardless,
and row-gap (var(--space-3), shared block above) was being paid
TWICE for gaps next to rows with nothing in them — 24px of pure
waste. Zeroed here, scoped to this single-row tier only (a real
multi-row tier, like the compact tier below, still needs its own
row-gap and is unaffected). */
row-gap: 0;
/* Tightened from the shared block's own var(--space-4)/16px top+
bottom — the other real contributor to "header trop haut": at
16px the header measured ~140px tall even once every other fix
above landed. 0.2.0-dev.6: trimmed once more, 12px -> 10px — the
client's own "réduire légèrement, sans rendre les éléments
serrés" ask, now that the real cart-height bug (a Storefront
collision, see .cart-contents' own comment) is fixed and no
longer the tallest item forcing the row open — the 68px logo
is, so this still leaves real breathing room (~93px -> ~89px
total, comfortably inside 88-100px, not tight). */
padding-top: 10px;
padding-bottom: 10px;
}
/* Real bug, found in the same live session: .site-branding carries a
genuine ~22.65px bottom margin (confirmed via getComputedStyle, not
guessed — traced to Storefront's own default spacing for its
original stacked, non-grid branding row) that nobody had reason to
notice until the header height itself became a client-visible
complaint. As a grid item its margin-box (not just its border-box)
determines the row's auto height, so this alone was inflating row 1
from 108px to ~130.6px. .site-search carries the same kind of
leftover margin. Neutralized here, scoped to the header context only
— neither element needs its margin anywhere else on this page. */
.site-header .site-branding,
.site-header .site-search {
margin-bottom: 0;
}
/* REAL, SEVERE bug found during this round's own final validation sweep
(not present in the original report, caught by testing the FULL
combined fix at every required width, including 1920px, across
several fresh page loads): with every fix above in place, the named
grid-area placement for #site-navigation was NON-DETERMINISTIC —
identical markup, identical CSS, a fresh page load — and on some
loads Chrome placed #site-navigation into an IMPLICIT SECOND ROW
instead of the "nav" cell its own grid-area names, pushing the
header back up to ~156px and putting nav visually below the rest of
the row (confirmed live, repeatedly, via getComputedStyle() showing
gridTemplateRows as "68px 63.4375px 0px 0px" — a real SECOND
content row, not just the harmless 0-height phantom rows above).
Every other tier (mobile, compact) and every other item on THIS
tier was unaffected — only #site-navigation, only sometimes, only
here. Root cause not fully isolated (this project's own "display:
contents" architecture bubbles #site-navigation up through TWO
nested contents chains — .site-header's own .col-full AND
.storefront-primary-navigation's — while logo/search/cart/account
only bubble through one; a dual-path bubble into a single named-area
grid is the most likely trigger, but could not be confirmed further
without patching the browser itself). The named grid-area system
(.site-branding/.site-search/etc.'s own "grid-area: X" rules, kept
below and still relied on by the mobile/compact tiers) is simply not
reliable for this one item at this one tier — explicit, numeric
line-based placement bypasses whatever non-deterministic
auto-placement path was causing it, and has now held clean across
more than a dozen repeated fresh loads at 1280/1920px. */
.site-header .site-branding {
grid-column: 1;
grid-row: 1;
}
#site-navigation {
grid-column: 2;
grid-row: 1;
}
.site-header .site-search {
grid-column: 3;
grid-row: 1;
}
.site-header .cristaline-header-social {
grid-column: 4;
grid-row: 1;
}
.site-header .site-header-cart {
grid-column: 5;
grid-row: 1;
}
.site-header .cristaline-account-link {
grid-column: 6;
grid-row: 1;
}
/* 0.2.0-dev.6: REAL fix for "le menu se retrouve collé contre le logo"
— confirmed live the nav sat flush left in its own 1fr track (a
~10px gap from the logo, not centered at all). The dead
".main-navigation ul.nav-menu { justify-content: center }" rule
below never did anything, because ul.nav-menu itself is
display:block (its horizontal item layout comes from float/inline-
flow on the
s, not flex) — justify-content only ever affects a
flex/grid CONTAINER, and nothing here was ever declared as one.
#site-navigation itself IS the real grid item (grid-area: nav,
spanning the 1fr track), so making IT the flex container centers
its one visible child (".primary-navigation", the wrapper Storefront
renders ul.nav-menu inside) within the full track width — the
.menu-toggle button and .handheld-navigation div are both
display:none at this tier already, so they don't affect the
centering. Confirmed live: nav-menu now sits centered in the track
with even space on both sides, not flush against the logo. */
#site-navigation {
display: flex;
justify-content: center;
}
}
.site-branding .site-title a,
.site-branding .site-title a:hover {
font-family: var(--font-heading);
color: var(--color-chrome-text);
letter-spacing: .02em;
}
/* The tagline duplicates the hero's own subheading on the homepage and,
at this compact header height, only adds clutter — hidden here, still
available anywhere else via bloginfo('description'). */
.site-header .site-description {
display: none;
}
.site-search .woocommerce-product-search {
align-items: center;
display: flex;
width: 100%;
}
/* 0.1.26: flex:1 (fills whatever width .site-search itself is given —
320px fixed on desktop, 100% of the row on the compact tier, see the
grid tiers below) replaces the old fixed 220px, which only ever made
sense back when .site-search had no explicit width of its own.
0.2.0-dev.4: real background/text colours added — this field previously
relied entirely on the browser's own default white input chrome, which
worked fine floating on the old light header but needs an explicit dark-
context treatment now (a plain default-white box would look like a
foreign, un-styled element dropped into the dark bar). A translucent
white fill (never fully opaque) keeps it reading as "part of the dark
header", not a bright cut-out. */
/* 0.2.0-dev.9: height:100% added — now that ".woocommerce-product-search"
itself has a real, explicit height (42px at >=1280px, see the
".site-search" rule further down), this input needs to fill it exactly
rather than keep its own intrinsic height (padding + line-height, ~48px)
inside a shorter flex container with "align-items: center" — without
this, the input would overflow the 42px box by ~3px top/bottom. */
.site-search input[type="search"] {
background-color: rgba(248, 247, 244, .1);
border: 1px solid var(--color-chrome-border);
border-radius: var(--radius-sm) 0 0 var(--radius-sm);
box-sizing: border-box;
color: var(--color-chrome-text);
flex: 1;
height: 100%;
line-height: normal;
margin: 0;
min-width: 0;
}
.site-search input[type="search"]::placeholder {
color: var(--color-chrome-text-muted);
}
/* Overrides components.css's shared ".button"/"input[type=submit]" ink-fill
— scoped to this one selector only, never the global rule (that rule
still has to serve every other input[type=submit] on the site, including
pages this round never touches). A plain icon-style button here reads as
part of the search field, not a separate ink block sitting awkwardly
next to it on a dark bar. */
.site-search button[type="submit"] {
background-color: transparent;
border: 1px solid var(--color-chrome-border);
border-left: none;
border-radius: 0 var(--radius-sm) var(--radius-sm) 0;
box-sizing: border-box;
color: var(--color-chrome-text);
height: 100%;
padding: var(--space-2) var(--space-3);
}
@media (hover: hover) and (pointer: fine) {
.site-search button[type="submit"]:hover {
background-color: rgba(248, 247, 244, .1);
border-color: var(--color-chrome-border);
color: var(--color-chrome-text);
}
}
/* Primary navigation — restyle Storefront's existing dropdown, same markup.
Explicit tighter horizontal padding (Storefront's own default is 1em ≈
16px/side): with 9 top-level items + the cart + account link all
sharing one row capped at --container-max (1280px), the extra ~90px
this reclaims across 9 items is needed for everything to fit on a
single line — confirmed by measuring real rendered item/cart widths on
the live site (see 00_Contexte-et-decisions/Decisions-validees.md). */
/* 0.1.25: real bug, confirmed live — Storefront's own ul.nav-menu ships a
negative side margin (a "bleed the outer edge to align
padding"
trick, meant to pair with ITS OWN default ~1em