Not a bug Style variant LESS/CSS not working for "system"

[frm]

Affected version

2.3

I'm unsure whether this is a bug, or whether it can even be addressed.

However, with style variants, we can set different styles for different variants: light/dark.

    .m-colorScheme(light,
        {
...
        }
    );
    .m-colorScheme(dark,
        {
...
        }
    );

The problem comes into play when the style is system, the default. Until they select light or dark, they will get the XF default style settings served to them

If Sec-CH-Prefers-Color-Scheme is being used to determine light or dark mode, it seems like a cookie can be set for light or dark mode, and perhaps, the code above work. And, if they come back with a new request different from the set cookie, (i.e., first came as dark but now came as light), it could reset the cookie and serve the appropriate code. I don't know of a solution for that.

This is also a problem for current visitors who haven't saved a preference as style_variation as default, alternate, or empty/null (for system in xf_user.

Certainly, there has to be a way to grab the header and set a temporary cookie, or another method, before the page renders the CSS so that the appropriate style can be rendered with the modifications for light/dark.

 

[Chris D]

That is an experimental feature that does not have wide browser support. I’m frankly not sure why it even exists as an experiment or otherwise.

It’s just not something we’re supporting at this time.

 

[frm]

Makes sense.

It works when it does and isn't really that big of an issue when it doesn't.

I could see it becoming a bigger issue when forums adapt style variants more to change colors, etc., as the "system" (default) colors won't work either way, from a design perspective (darker text on dark mode/vice-versa).

 

[Kirby]

The problem comes into play when the style is system, the default. Until they select light or dark, they will get the XF default style settings served to them

Hmn, I don't understand this issue.

If you use

m-colorScheme(light, { ... } );

those rules will be applied when the rendered variant is light, it doesn't matter if light is rendered because the visitor explicitly selected this variant or because system is used and the visitor system prefers light.

 

[Jeremy P]

Yes, the server is essentially blind to what the system color scheme is, which is deliberate.

You would typically apply your rules globally for one color scheme (usually light) and then use the mixin to customize any colors on the other color scheme (usually dark) as necessary:

.p-body-main
{
    color: black;
    font-size: 2em;

    .m-colorScheme(dark, {
        color: white;
    });
}

The dark rules will be applied when the system color scheme is dark, or when a dark variation is explicitly selected. Otherwise the global rules will apply.

 

[frm]

Yes, the server is essentially blind to what the system color scheme is, which is deliberate.

I've figured after altering the db from default/alternate/"null" to test what a guest would see and have to do in order for it to happen.

The problem lies in some designs where no matter the main color used, it would look bad on one or the other (light or dark) as it's designed for one or the other, and can't possibly work for the opposite without having to squint eyes or narrow focus in.

So, if it can't be determined before the page renders (with headers, then a cookie, or some other method), in that case, it makes more sense to disable "system" and only have the two variants, making the detection on some styles useless and reverting to how it would be done on 2.2.

 

[Jeremy P]

The problem lies in some designs where no matter the main color used, it would look bad on one or the other (light or dark) as it's designed for one or the other, and can't possibly work for the opposite without having to squint eyes or narrow focus in.

I don't understand. The technique above will apply one color to the light color scheme and another to the dark color scheme regardless of whether the variation is explicitly selected or the system preferred color scheme.

 

[frm]

those rules will be applied when the rendered variant is light, it doesn't matter if light is rendered because the visitor explicitly selected this variant or because system is used and the visitor system prefers light.

I understand that now after altering the db to test it out.

The problem is that system won't ever work with some designs without prior detection because some colors won't ever look good on either/or and you are forced into using one.

If it can't be detected and forced, then it's going to be hard for style designers to make a style fitting for both light and dark mode with the same colors. Take banners into account, for instance, if you have a dark banner with white text, you would probably want to go with a light banner with dark text on the dark mode. Which one would system render if lighter or darker were the default? It simply would not work from a UI design perspective.

 

[Jeremy P]

I think there may be a misunderstanding of how the system variation works. When the system variation is selected, we provide both sets of rules to the browser and the browser chooses which to apply. You can absolutely still have different rules based on whether the system color scheme is light or dark without the server having any idea which is selected. It all happens client-side.

In other words, there is no system preference that is neither light nor dark. There is no third 'default' option. The system preference just lets the device decide rather than forcing it.

 

[frm]

The issue is also user name CSS doesn't accept this.

So, here's a good example:

Create a XenForo demo

ac6b98a483bc098f.demo-xenforo.com

The very first view of this will be blue (default XF color), but the second view will be a green, depending on system preferences a dark or light green. I think it's only occurring on the 1st full render...

 

[Jeremy P]

The first view is green, as intended. It will never be blue with the rules you've applied. That's true whether using the system variation or an explicit choice.

 

[frm]

The first view is green, as intended. It will never be blue with the rules you've applied. That's true whether using the system variation or an explicit choice.

You're correct. I can verify that it works here.

It did not on an install of XF until the user selected one or the other.

I don't have DB access to set "" and access the page again while logged out.

It appears to be a problem when style_variant is null for users.

 

[Jeremy P]

It is not possible for it to be null. It can either be an explicit variation/color scheme or an empty string, which is an implicit variation/color scheme.

You don't need database access to set '', that is the default and can also be manually chosen by selecting "System" from the chooser.

 

[frm]

It is not possible for it to be null. It can either be an explicit variation/color scheme or an empty string, which is an implicit variation/color scheme.

I mean xf_user style_variant. I'll create some new users and try accessing it with the demo to see if it shows up as blue.

 

[Jeremy P]

I mean xf_user style_variant.

So do I. The cookie is only to set the same value for guests since they don't have a user record. Otherwise it is functionally equivalent.

I'll create some new users and try accessing it with the demo to see if it shows up as blue.

It won't.

In other words, there is no system preference that is neither light nor dark. There is no third 'default' option. The system preference just lets the device decide rather than forcing it.

 

[frm]

I mean xf_user style_variant. I'll create some new users and try accessing it with the demo to see if it shows up as blue.

Ah, a critical issue I left out.

It was on iPhone/Apple devices. I could always see it on my end.

 

[Jeremy P]

I can't reproduce that and there's no reason that would happen barring a Safari/iOS bug. The device decides whether to apply the light or dark rules. In any case we're fairly confident there aren't any bugs with the way we handle this.

 

[frm]

I can't reproduce that and there's no reason that would happen barring a Safari/iOS bug. The device decides whether to apply the light or dark rules. In any case we're fairly confident there aren't any bugs with the way we handle this.

Once I get the specific device info, I'll be able to know for sure what is affected and update this thread again. It could be an older device and not something that needs to be worked in because there are so few out there (as, for the most part, you Apple nuts upgrade each time there's a new iPhone drop).

The only way that user could see the proper color was to specifically select which one they wanted to see as it wouldn't render on theirs until they selected it.