/* Theme Name: LLF Block Theme Author: Haji Ismael Version: 1.0.0 Text Domain: figma-block-theme */ /* Target the auto-generated wp:template-part wrapper, not .llf-header itself: that wrapper only ever contains this one block, so it's exactly the same height as .llf-header - sticky positioning is bound by its own containing block, and a containing block with zero extra height gives it nowhere to "stick" as the page scrolls (it moves off with the rest of the page, indistinguishable from static). The wrapper's own containing block (.wp-site-blocks) is the full page height, which is what sticky actually needs. */ header.wp-block-template-part { position: sticky; top: 0; z-index: 100; } .llf-nav-active > a { color: var(--wp--preset--color--primary) !important; } /* Match the footer's link hover treatment (pale-blue -> sky blue), while the active page keeps its green highlight regardless of hover. The nav's textColor block support renders with !important, so the hover color needs !important too to actually take effect. */ .llf-header-nav .wp-block-navigation-item:not(.llf-nav-active) > a:hover { color: var(--wp--preset--color--secondary-light) !important; } /* GoDaddy Managed WordPress runs a host-level "contrast fallback" mu-plugin that force-colors any heading/paragraph/link inside a background-colored group block that isn't carrying WordPress's own has-text-color class, at high specificity with !important. Our nav and footer links get their color from these plain class rules rather than a block color attribute, so on that host they silently render white. These variants exceed that rule's specificity so the intended colors hold on every host, not only ones without that plugin. */ body .llf-header.has-contrast-background-color .wp-block-navigation.llf-header-nav .wp-block-navigation-item > a { color: var(--wp--preset--color--pale-blue) !important; } body .llf-header.has-contrast-background-color .wp-block-navigation.llf-header-nav .llf-nav-active > a { color: var(--wp--preset--color--primary) !important; } body .llf-header.has-contrast-background-color .wp-block-navigation.llf-header-nav .wp-block-navigation-item:not(.llf-nav-active) > a:hover { color: var(--wp--preset--color--secondary-light) !important; } body .llf-footer.has-contrast-background-color .llf-footer-row .llf-footer-links.wp-block-group a { color: var(--wp--preset--color--pale-blue) !important; } body .llf-footer.has-contrast-background-color .llf-footer-row .llf-footer-links.wp-block-group a:hover { color: var(--wp--preset--color--secondary-light) !important; } /* Same contrast-fallback plugin also force-colors any is-style-outline button's text AND border to a dark "contrast" fallback whenever it sits inside a background-colored group block, regardless of the button's own color/border classes - hits "Explore Our Portfolio" (.llf-cta has-secondary-background-color) and "Read Full Story" (.llf-featured-story has-base-background-color). Confirmed on the live host: both were rendering as rgb(18,48,62) text+border instead of their intended colors. The plugin's