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

[ACL]

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:

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]

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]

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:

a&:hover,a:hover &
{
    background: xf-intensify(@xf-xbPrefixOrange--background-color, 10%);
    border-color: xf-intensify(@xf-xbPrefixOrange--background-color, 20%);
}