/**
Theme Name: Astra Child
Author: Brainstorm Force
Author URI: http://wpastra.com/about/
Description: Astra is the fastest, fully customizable & beautiful theme suitable for blogs, personal portfolios and business websites. It is very lightweight (less than 50KB on frontend) and offers unparalleled speed. Built with SEO in mind, Astra comes with schema.org code integrated so search engines will love your site. Astra offers plenty of sidebar options and widget areas giving you a full control for customizations. Furthermore, we have included special features and templates so feel free to choose any of your favorite page builder plugin to create pages flexibly. Some of the other features: # WooCommerce Ready # Responsive # Compatible with major plugins # Translation Ready # Extendible with premium addons # Regularly updated # Designed, Developed, Maintained & Supported by Brainstorm Force. Looking for a perfect base theme? Look no further. Astra is fast, fully customizable and beautiful theme!
Version: 1.0.0
License: GNU General Public License v2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html
Text Domain: spliff
Template: astra
*/

/* =========================================================
   « Hot catégories » du header — badges New / Best-seller.
   Piloté depuis Outils → Hot catégories (option spliff_hot_menu_items).
   Badge injecté à droite du nom : L1 mobile, L2 mobile + desktop.
   Sélecteur global : .hot-badge est une classe propre au thème.
   ========================================================= */
.hot-badge {
    display: inline-block;
    margin-left: .5em;
    padding: 4px 7px;
    background: #f9f9f9;
    color: #1b1b1b;
    border-radius: 3px;
    font-size: 10px;
    font-weight: 700;
    line-height: 1;
    letter-spacing: .04em;
    text-transform: uppercase;
    white-space: nowrap;
    vertical-align: middle;
}

/* Voile animé « hot » — SUR LES LETTRES (background-clip: text).
   Le reflet est porté par .hot-shine-text, un span inline-block qui épouse le
   texte du libellé → rendu IDENTIQUE en desktop et en mobile (indépendant du
   fait que .menu-item-title soit une ligne flex pleine largeur en mobile).
   Base = couleur normale du texte (currentColor) ; le reflet --hot-shine-hi
   doit contraster (un blanc ne se verra pas sur du texte blanc). Gaté @supports
   pour ne jamais rendre le texte invisible sur navigateurs sans background-clip. */
@supports ((-webkit-background-clip: text) or (background-clip: text)) {
    .hot-shine-text {
        display: inline-block;
        background-image: linear-gradient(90deg,
            currentColor 18%,
            var(--hot-shine-hi, currentColor) 25%,
            currentColor 32%,
            currentColor 68%,
            var(--hot-shine-hi, currentColor) 75%,
            currentColor 82%);
        background-size: 200% auto;
        -webkit-background-clip: text;
        background-clip: text;
        -webkit-text-fill-color: transparent;
        animation: spliff-hot-shine 3s linear infinite;
    }
}
@keyframes spliff-hot-shine {
    from { background-position: 0 center; }
    to   { background-position: 200% center; }
}
@media (prefers-reduced-motion: reduce) {
    .hot-shine-text { animation: none; }
}

/* =========================================================
   Hero Elementor — répare les slides réécrites en <picture>.
   Un convertisseur WebP réécrit <img class="swiper-slide-image">
   en <picture class="swiper-slide-image"><source><img>. La classe qui
   porte width:100% (option « Étirer l'image ») atterrit alors sur le
   <picture> — inline, donc insensible à width — pendant que l'<img>
   réel la perd et retombe à sa largeur native (1920px).
   Sous 1920px de viewport, max-width:100% masque le problème ; au-delà
   l'image plafonne et laisse des bandes latérales + une hauteur réduite.
   Ne cible que les slides effectivement réécrites : une slide restée en
   <img> n'est pas concernée par ces deux règles.
   ========================================================= */
.elementor-element .swiper .swiper-image-stretch .swiper-slide picture.swiper-slide-image {
    display: block;
}
.elementor-element .swiper .swiper-image-stretch .swiper-slide picture.swiper-slide-image > img {
    width: 100%;
}
/* =========================================================
   Menu BLOG — répartition desktop / mobile (chantier SEO FR, 24/08/2026).
   Le header Astra rend le MÊME menu (39) sur desktop et mobile.
   Décision produit : BLOG au niveau 1 sur desktop (entrée 25815, avec
   son sous-menu de sections), mais sur mobile il reste rangé dans
   AUTRES (entrée 100088637, simple lien). Astra pose la classe
   .ast-header-break-point sur <body> quand le header mobile est actif :
   on s'appuie dessus plutôt que sur un breakpoint en dur, pour suivre
   automatiquement le réglage du thème.
   ========================================================= */
.ast-header-break-point #menu-item-25815 {
    display: none;
}
body:not(.ast-header-break-point) #menu-item-100088637 {
    display: none;
}

/* =========================================================
   Bloc « Guides CBD » du footer — FR UNIQUEMENT (chantier SEO FR, 25/08/2026).
   Le gabarit de footer (Elementor 7) est servi sur les SIX domaines, et ses
   menus sont traduits par WPML. Ce bloc-ci pointe vers des guides qui n'existent
   qu'en français : l'afficher ailleurs enverrait un lecteur allemand ou espagnol
   sur du contenu FR, et brouillerait le maillage entre versions linguistiques.
   On se cale sur le `lang` de <html> (fr-FR / de-DE / es-ES…) plutôt que sur
   l'URL : c'est WPML qui le pose, il suit donc la langue réellement servie.
   La liste est stylée à la main pour tomber d'aplomb avec les widgets de menu
   des colonnes voisines (pas de puce, même interligne, mêmes couleurs).
   ========================================================= */
html:not([lang^="fr"]) .spliff-footer-guides {
    display: none !important;
}
.spliff-footer-guides__list {
    list-style: none;
    margin: 0;
    padding: 0;
}
.spliff-footer-guides__list li {
    padding: 6px 0;
}
.spliff-footer-guides__list a {
    color: #AFAFAF;
    text-decoration: none;
}
.spliff-footer-guides__list a:hover,
.spliff-footer-guides__list a:focus {
    color: #FFFFFF;
    text-decoration: underline;
}

/* =========================================================
   L'encre de la maison, partout : #1b1b1b, jamais le navy global.
   Astra teinte `body` et les titres avec sa couleur globale n°3 (#374c6c) —
   c'est le réglage « Couleur du texte » du personnalisateur. Tout ce qui n'a
   pas de couleur propre en hérite : articles écrits dans WordPress, pages,
   fiches produit, tunnel. Le blog, lui, est noir : le bleu détonnait partout.
   Ce bloc remplace un correctif plus étroit (24/08/2026) qui ne visait que
   `body.single-post .elementor-location-single .elementor-widget-theme-post-content` — même intention,
   mais il laissait le bleu sur tout le reste du site.

   Deux garde-fous, à ne pas perdre si on retouche ce bloc :
   · On reprend le sélecteur d'Astra MOT POUR MOT. Même spécificité, mais
     cette feuille dépend de `astra-theme-css` (app/Theme/Assets.php) donc
     elle passe après le CSS dynamique du thème parent : c'est l'ordre, pas
     un `!important`, qui tranche.
   · On ne change QUE la couleur HÉRITÉE, jamais celle d'un conteneur
     intermédiaire. Toute couleur posée explicitement ailleurs reste
     prioritaire — en particulier le BLANC des blocs à fond noir, qui
     redeviendrait illisible si on descendait cette règle d'un cran.

   ⚠️ Le personnalisateur continue d'afficher #374c6c : la valeur stockée
   n'est pas touchée, c'est bien cette feuille qui a le dernier mot.

   30/08/2026 — LE PRÉFIXE `html` N'EST PAS DÉCORATIF, NE PAS LE RETIRER.
   Le garde-fou « c'est l'ordre qui tranche » ci-dessus est MORT le jour où la
   combinaison CSS de LiteSpeed a été activée (PR #1331). La combinaison fond
   toutes les feuilles LIÉES en un seul fichier, posé à la place de la première
   — donc AVANT les blocs `<style>` inline, qui eux ne sont jamais combinés.
   `astra-theme-css-inline-css` (77 ko, `color:var(--ast-global-color-3)`, même
   sélecteur mot pour mot, spécificité identique) repassait donc APRÈS nous, et
   le navy était revenu sur tout le site — mesuré sur article et fiche produit.
   `html` monte à 0-0-2 : la spécificité tranche, l'ordre ne compte plus, et on
   reste sans `!important`. Vérifié à la position réelle de la feuille (injection
   juste avant l'inline Astra) sur `/products/big-buddha-thcx` : 250 éléments
   changent, TOUS de rgb(55,76,108) vers rgb(27,27,27) — aucune autre couleur
   déplacée, en particulier aucun blanc de bloc à fond sombre.
   ========================================================= */
html body,
html h1, html h2, html h3, html h4, html h5, html h6,
html .entry-title a,
html .entry-content :where(h1, h2, h3, h4, h5, h6) {
    color: #1b1b1b;
}


/* =========================================================
   LIENS D'ARTICLE — encre noire ET soulignes, sur TOUT le blog.
   Demande Oliver (29/08/2026) : « le lecteur ne comprend pas que c'est un
   lien ». Constate en prod sur /quest-ce-que-le-thcx… : 25 liens de prose
   noirs, zero souligne.

   Pourquoi ici et pas dans le plugin : le blog a DEUX familles d'articles.
   · Les articles du Creator portent `.spliff-article` et leur propre CSS,
     emis au rendu (spliff-seo/RenderTemplates.php) — deja soulignes.
   · Les articles historiques sont montes en widgets Elementor
     (text-editor, html, theme-post-content). Aucune de ces regles ne les
     touche, et ils sont la majorite du corpus. Cette feuille-ci est le seul
     toit commun.

   Deux garde-fous :
   · `.elementor a{text-decoration:none}` (custom-frontend.min.css) est a
     0-1-1 et chargee tard. On monte a 0-3-2 : c'est la specificite qui
     tranche, pas un `!important`.
   · Les liens qui n'enveloppent qu'une IMAGE sont re-exclus plus bas
     (regle separee : si `:has()` n'est pas supporte, on ne perd que cette
     exclusion, pas le souligne).

   · Perimetre borne a `.elementor-location-single` : sans lui, les widgets
     du PIED DE PAGE (bloc « Guides CBD ») se retrouvaient soulignes sur les
     pages d'article et nulle part ailleurs. `body.single-post` en plus, pour
     ne pas deborder sur les fiches produit, qui partagent la meme location.

   Hors perimetre volontaire, parce que ce ne sont pas des liens de lecture :
   boutons, cartes d'articles lies (toute la carte est cliquable) et chips de
   meta (date, tags) du widget post-info.
   ========================================================= */
body.single-post .elementor-location-single .elementor-widget-text-editor a[href],
body.single-post .elementor-location-single .elementor-widget-html a[href],
body.single-post .elementor-location-single .elementor-widget-theme-post-content a[href],
body.single-post .entry-content a[href] {
    color: #1b1b1b;
    text-decoration: underline;
    text-decoration-color: currentColor;
}

/* Le bouton reste un bouton : il se lit deja comme cliquable. */
body.single-post .elementor-location-single .elementor-widget-text-editor a.elementor-button[href],
body.single-post .elementor-location-single .elementor-widget-html a.elementor-button[href],
body.single-post .elementor-location-single .elementor-widget-theme-post-content a.elementor-button[href],
body.single-post .entry-content a.elementor-button[href],
body.single-post .entry-content a.wp-block-button__link[href] {
    text-decoration: none;
}

/* Un lien qui n'entoure qu'une image n'a pas de texte a souligner. */
body.single-post .elementor-location-single .elementor-widget-text-editor a[href]:has(> img:only-child),
body.single-post .elementor-location-single .elementor-widget-html a[href]:has(> img:only-child),
body.single-post .elementor-location-single .elementor-widget-theme-post-content a[href]:has(> img:only-child),
body.single-post .entry-content a[href]:has(> img:only-child) {
    text-decoration: none;
}

/* Sommaire Elementor de l'article : meme signature que le reste du texte,
   et il gagne son encre noire au passage (il etait en gris #7a7a7a). */
body.single-post .elementor-location-single .elementor-widget-table-of-contents a[href] {
    color: #1b1b1b;
    text-decoration: underline;
    text-decoration-color: currentColor;
}


/* =========================================================
   IMAGES D'ARTICLE — bornees, centrees, ratio intact.
   Demande Oliver (30/08/2026) sur /vape-thcx-la-revolution-sensorielle :
   « les images sont trop grandes, en desktop c'est immense ».

   Mesure avant correctif, viewport 1440 (colonne de texte : 1140 px) :
   trois `figure.wp-block-image` rendues a 1000x1000, 1080x1080, 1080x1080 —
   la taille NATURELLE du fichier. Rien ne les bornait : les attributs
   width/height du `<img>` valent largeur utilisee, et le seul garde-fou en
   place (`max-width:100%` inline) ne mord qu'a partir de 1140 px.

   Pourquoi ici et pas dans spliff-seo : c'est la deuxieme famille d'articles.
   · Articles Creator : `.spliff-article`, deja bornes par RenderTemplates
     (`--inline` : max-width min(420px,100%), max-height 340px). Verifie sur
     /thcx-vs-thc — ce bloc n'y change RIEN (0 diff sur 157 elements, et zero
     `figure.wp-block-image` dans ce corpus).
   · Articles historiques montes en widgets Elementor : aucune regle du plugin
     ne les atteint, cette feuille est le seul toit commun.

   On borne la LARGEUR de la figure, pas la hauteur de l'image :
   · `max-height` seul ECRASE l'image. Mesure : la largeur vient de l'attribut
     `width` (valeur utilisee, pas `auto`), donc l'algorithme de conservation du
     ratio de CSS 2.1 §10.4 ne s'applique pas et on obtient 420x340 sur un
     carre. Il faudrait `width:auto` en plus — mais alors le placeholder du
     lazy-load (GIF 1x1, `data-lazyloaded`) s'effondre a 1x1 avant chargement,
     et on echange une image trop grande contre un saut de mise en page.
   · Borner la figure evite les deux : le placeholder ET l'image finale
     occupent la meme boite, ratio d'origine conserve, zero CLS, et ca tient
     sans JavaScript.

   Mobile INCHANGE et c'est voulu : a 390 px la colonne fait 322 px, donc
   min(420px,100%) vaut deja 100 %. Une photo pleine colonne est la norme du
   corpus (meme rendu que la famille Creator). Le correctif ne joue qu'a partir
   de ~420 px de colonne, la ou l'ecart etait de 1000 px a 420 px (-58 %).
   ========================================================= */
body.single-post .elementor-location-single .elementor-widget-theme-post-content figure.wp-block-image,
body.single-post .elementor-location-single .elementor-widget-text-editor figure.wp-block-image,
body.single-post .elementor-location-single .elementor-widget-html figure.wp-block-image,
body.single-post .entry-content figure.wp-block-image {
    max-width: min(420px, 100%);
    margin-inline: auto;
}

body.single-post .elementor-location-single .elementor-widget-theme-post-content figure.wp-block-image img,
body.single-post .elementor-location-single .elementor-widget-text-editor figure.wp-block-image img,
body.single-post .elementor-location-single .elementor-widget-html figure.wp-block-image img,
body.single-post .entry-content figure.wp-block-image img {
    max-width: 100%;
    height: auto;
}