/** * Higher-contrast hyperlink color sitewide (2026-08-20, per Wulfy: "the color is way too close * to the rest of the text and it doesn't stand out. could you make it much higher contrast * please"). * * Root cause, confirmed live: Flatsome's own theme customizer outputs * --fs-experimental-link-color: #334862 as a CSS custom property, and its compiled stylesheet * has exactly one rule consuming it -- a{color:var(--fs-experimental-link-color)}. Body text * (--fs-color-base) is #4a4a4a. Converting both to HSL lightness: #334862 sits at ~29% and * #4a4a4a sits at ~29% too -- functionally identical darkness, just a different hue, which is * exactly why a link reads as barely distinguishable from the surrounding paragraph text around * it rather than visually popping. * * Fix targets the CSS VARIABLE itself, not a blanket `a { color }` rule -- buttons, nav items, * and anything else styled as an already set their own explicit color (e.g. white button * text) at higher specificity than the bare `a` selector, so overriding just the variable only * touches genuine plain-text links (blog content, product descriptions, footer text links, * breadcrumbs) and leaves every button/nav link completely alone -- a blanket `!important` on * `a` itself would have overridden those too, since !important beats specificity regardless. * * New color (#2e6cb8) is a brighter, more saturated version of the same blue family as the * theme's own --fs-color-primary (#446084) -- deliberately not a hue swap to something * unrelated (like the site's orange secondary accent, already carrying its own meaning * elsewhere as a warning/CTA color) -- just a real lightness/saturation jump within the * existing brand hue so it reads as "brand blue, but the confident version," not a mismatched * new color. Sits at ~45% HSL lightness vs body text's ~29%, and passes WCAG AA against a white * background (~5.4:1, above the 4.5:1 minimum for normal text). Hover color follows the same * hue, darkened, instead of jumping to Flatsome's original near-black hover (#111) which would * have undone the same problem this is fixing on interaction. * * !important on the custom property declaration itself (not on any element rule) guarantees * this wins regardless of whether this stylesheet loads before or after the theme's own inline * customizer