Fixed XB thread prefixes: hover state ignores XB style property CSS

ACL

Customer
XenForo's default prefix styling applies a darkening effect to the background and border on hover. With XB thread prefixes enabled this still applies exactly as before. If prefix styling differs greatly between core_labels.less and XB style properties, this can lead to some interesting clashes of colour and text/background constrast issues. It'd be great if FA+ (and other styles) could recalculate this hover effect using the XB colours as a base :)

XenForo's hover state effect is applied from .m-labelVariation(@color; @bg; @border: false) in setup.less, which does the following:
CSS:
a&:hover,
    a:hover &
    {
        background: xf-intensify(@bg, 4%);
        border-color: xf-intensify(@bg, 14%);

        & when (iscolor(@border))
        {
            border-color: xf-intensify(@border, 4%);
        }
    }
 

Russ

Pixel Exit Staff
I've made a slight adjustment for this in our 2.1.1 release, it won't change colors but adds a small box-shadow (inset) effect, should help overall :)
 

ACL

Customer
With FlatAwesome 2.1.1, I still experience the core_labels.less colours sometimes being applied to the hover state, e.g. label--primary (also happens in the unedited parent style).

I've taken a different approach for now and added :hover CSS, similar to what .m-labelVariation() does, for each prefixes's style property in the Freeform CSS/LESS box. This seems to take priority over XenForo's hardcoded prefix colours. It is a bit messy and not that flexible (e.g. a transparent background leads to CSS errors). But otherwise, it seems to work for me :).

E.g. for orange:
CSS:
a&:hover,a:hover &
{
    background: xf-intensify(@xf-xbPrefixOrange--background-color, 10%);
    border-color: xf-intensify(@xf-xbPrefixOrange--background-color, 20%);
}
 

Pre-Sale Questions

If you have any questions or concerns you want to ask before you make a purchase don't hesitate to use one of our multiple support channels for your convenience.