/**
 * Couleur du texte de la fiche produit : rendre au contenu du back-office la
 * mise en forme qu'il porte lui-meme.
 *
 * Meme raison d'etre que home-cta.css et checkout-back.css : le fichier vit
 * dans le module parce que le theme ne se met a jour que par un reimport
 * complet, indisponible sur la preprod (back-office uniquement).
 *
 * ── Le defaut ────────────────────────────────────────────────────────────
 * Ticket : « on m'a remonte que parfois le mot FLAASH apparait en gris ».
 *
 * Le nom de la revue est SYSTEMATIQUEMENT balise <em>FLAASH</em> dans les
 * descriptions saisies en back-office. Or le theme imposait une couleur aux
 * balises de ce contenu :
 *
 *     main.css           .offer-copy em     { color: #7d7d7d }
 *     main.css           .offer-copy strong { color: #282828 }
 *     live-overrides.css body#product .offer-copy em { color: #5c5c5c }
 *
 * La production, elle, n'impose RIEN : <strong> et <em> heritent de la couleur
 * du HTML colle depuis Word. Sur le pack anniversaire ce HTML porte un
 * `color:#000000` en style inline — le texte est donc noir, mais la regle du
 * theme, qui vise directement la balise, gagnait sur cet heritage et isolait le
 * seul mot FLAASH en gris au milieu du paragraphe.
 *
 * D'ou le « parfois » du ticket : sur les fiches dont la description est deja
 * grise (les numeros), le defaut est invisible ; il n'apparait que sur celles
 * dont le texte est noir.
 *
 * `color: inherit` reproduit exactement le comportement de la production : la
 * balise suit la couleur du texte qui l'entoure, quelle qu'elle soit.
 *
 * Mesures relevees sur boutique.flaash.fr (viewport 1440), le mot FLAASH de
 * /common/product-article/38 :
 *   prod rgb(0, 0, 0) · avant correction rgb(92, 92, 92) · apres rgb(0, 0, 0)
 *
 * ── Le second gris ───────────────────────────────────────────────────────
 * Les cartes « vous aimerez aussi » de la fiche produit n'etaient stylees que
 * sous `body#category` : sur `body#product`, leurs titres ne recevaient aucune
 * couleur et heritaient du gris du corps de page. Les titres « FLAASH N°xx » y
 * sortaient donc en #5c5c5c au lieu du #282828 de la production.
 *
 * Le listing de categorie, lui, affichait #181818 la ou la production affiche
 * #282828 : meme teinte de reference pour les deux contextes.
 *
 * ── Cascade : pourquoi les classes sont doublees ─────────────────────────
 * Contrairement aux autres feuilles du module, la priorite de chargement ne
 * suffit PAS ici. Le theme injecte live-overrides.css en dur a la fin de
 * _partials/head.tpl :
 *
 *     {block name='stylesheets'}...{/block}
 *     <link rel="stylesheet" href="{$urls.theme_assets}css/live-overrides.css?v=...">
 *
 * soit APRES le bloc qui rend les feuilles enregistrees par les modules. Aucune
 * valeur de `priority` ne peut donc passer derriere elle : a specificite egale,
 * c'est toujours le theme qui gagne.
 *
 * La classe est donc redoublee (`.offer-copy.offer-copy`) pour porter la
 * specificite a 0,1,2,2 contre 0,1,1,2 pour les regles du theme. Le selecteur
 * vise exactement les memes elements — redoubler une classe ne change pas ce
 * qui est selectionne, seulement son poids dans la cascade.
 *
 * Ce detour evite `!important`, qui aurait fige la couleur : le jour ou le
 * theme sera rebundle sans ces regles, `inherit` restera le comportement juste
 * et cette feuille deviendra simplement redondante, jamais genante.
 */

body#product .offer-copy.offer-copy strong,
body#product .offer-copy.offer-copy em {
  color: inherit;
}

body#product .catalog-card__title.catalog-card__title a,
body#category .catalog-card__title.catalog-card__title a {
  color: #282828;
}