XF 2.3 A first look at XenForo 2.3

Well, here we are with our first Have you seen thread for XenForo 2.3.

It's been a long time coming, and for various reasons that we will go into later, it has changed quite a bit from what we had originally intended it to be, but it's finally ready to start showing you what's new.

tl;dr: there's a video at the end of this post.

Dark mode​

A lot of the new stuff in XenForo 2.3 is related to performance improvements that won't be immediately apparent on first glance, but there is one new feature in particular that is very obvious, and that is the new dark mode.

1694695492940.png


1694612354992.png


1694612120532.png


1694616451007.png


1694617171895.png


1694617408731.png


If the device with which you are browsing a XenForo site is configured to use its own dark mode, XenForo will switch itself to use the dark theme. Alternatively, you can request either the light, dark, or system-controlled theme using the gadget in the footer next to the style chooser. This will switch the mode instantly, without a page reload.

1694612251510.png


This is not XenForo 3.0​

This is not the big design overhaul that was originally targeted for 2.3, which included sweeping changes to the template system and introduced a range of new technologies to provide a significant improvement to many areas of XenForo.

When it became clear that the new design would introduce unresolvable backward-compatibility issues, the decision was made to back out the new design and reserve it for a version of XenForo we will call 3.0. Instead, we decided to ship the new functionality that we have built for 2.3 without the new design, so that existing users can gain access to all the new features without worrying about a major maintenance job to get it integrated.

Some of the new systems that we built to support the 3.0 design have been adapted to work with the 2.3 system, and support for dark mode is one of them.

Style variations​

The dark mode is built on top of a brand new style variations system. This system allows defining alternate sets of certain style properties, namely colors, to be switched dynamically without a page reload.

We currently expose two variations, which we dub 'default' and 'alternate'. In the default style, the default variation corresponds to the light theme and the alternate variation corresponds to the dark theme.

When both variations correspond to different style types (that is, light or dark), we expose them using the prefers-color-scheme media query. This automatically selects a variation based on the device's preferred color scheme when a user has not explicitly chosen a variation to use.

However, you could also set both variations as light or dark. In this case, the gadget in the footer will display the variation names instead, still allowing users to switch to a different color palette at whim.

Many sites running XenForo already run with a third-party dark style, but it's important to note that offering both light and dark styles to your visitors would previously have entailed providing completely separate styles, and while the dark style may have inherited most of its templates and style properties from a light parent, there would still have been a performance penalty tied to supporting both of these styles. With the style variations system in XenForo 2.3, this is no longer the case. Both variations of the style are handled within a single style. Those administrators who maintain multiple styles and have to handle inheritance between them will appreciate how much easier this will make style management.

1694602899783.png


Default and alternate​

Furthermore, while light styles can now be extended to support a dark variation, the same is true of existing dark styles, which can now define a light variation. At present, we refer to the Default and Alternate variations, where Default could be light or dark, and Alternate is (usually) the opposite.

1694602934013.png


Style properties​

From a style designer's perspective, style variations are handled as part of the style properties system. Style properties defined as a color value may be edited to enable variations, in which case they will accept values for each of the variations defined in the style.

1694602777696.png


With variations enabled, the user is free to define completely different versions of the color for each variation.

1694602968075.png


Note that the ability to support variations is limited to color value type style properties and does not extend to CSS-type properties. Of course, that does not mean that CSS-type properties are unable to benefit from the variations system, because the color values they reference may themselves be variants. That is to say, if your header CSS uses @xf-chromeBg, which in turn references @xf-paletteColor5, then it will automatically pick up the variant value of @xf-paletteColor5 when defined.

Future extension​

In a future version of XenForo, depending upon feedback, we may add support for defining additional variations, and extend the range of style properties which support variations beyond color properties. This could allow variations with different padding or typography choices, all within a single style.

UI improvements​

You will notice that we have significantly increased the size of the color preview chip next to these controls, and that the style property editor has become faster to operate, as style property changes are now saved without the need to reload the page.

Additionally, in style properties where palette colors are referenced, variations are automatically inherited when using either the default or alternate fields, and can be manipulated using the standard color editing functions provided by XenForo, such as darken and xf-intensify.

Naturally, the xf-intensify and xf-diminish functions now respect the light or dark mode within which they are operating, pushing colors either darker or lighter depending upon the way in which the current variation is flagged.

HSL color space​

You may have spotted from the images shown so far that we are now making use of HSL color space. While colors in XenForo were largely defined in RGB format, either as RGB decimal or hexadecimal values, this system presents challenges to some users, as adjustment of red, green and blue values is required to achieve even simple changes like making a color darker. HSL (hue, saturation and lightness) brings a more human-friendly color system, where the tone (hue) of the color is defined with a single value, then the intensity (saturation) and brightness (lightness) can also be adjusted with a single value change.

The color picker has been updated to reflect this change.

1694603931568.png


CSS variables​

Furthermore, each component of the HSL colour is now represented as a CSS variable. In XenForo 2.3 this allows the switching between light and dark variations, but its full utility will become apparent with XenForo 3.

A fun thing to try when you get access to 2.3, use your browser's inspector to locate the HSL values for paletteNeutral3, defined as the CSS variables --xf-paletteNeutral3--h, --xf-paletteNeutral3--s, and --xf-paletteNeutral3--l and use your cursor keys to adjust the value up and down. You will see that all instances of that color in use on the page react immediately, regardless of any adjustments made to them in subsequently inherited colors. Here, we have adjusted xf-paletteNeutral3 from hsl(0, 0%, 8%) to hsl(200, 50%, 20%) using the inspector in Chrome, resulting in changes to various backgrounds and borders that are based on adjustments of the original color.

1694608756513.png


Of note here is that the operations being performed on the colors are done on the client side rather than with the server-side LESS processor, so it's much easier to prototype sweeping color adjustments.

Making it your own​

In order to prevent any unexpected behavior when you upgrade to XenForo 2.3, we will not make changes to any of your styles. This includes marking your styles as supporting variations.

To enable variations, edit each of your styles in turn and toggle the 'Enable variations' option. Next, jump into the style properties editor for that style and concentrate on the Color palette and Basic colors groups.

In the default style, we took each of the Palette and Accent colors and reduced their saturation and lightness a little for the dark variation so that they are a little more muted against a dark background. We did not adjust the Neutral colors at all.

Next, in the Basic colors group, we switched around references to the Neutral 3 (dark) and Neutral 1 (light) colors, and in some cases reversed the references to palette colors, so references to Palette 1 now point to Palette 5 etc., making further adjustments with the built-in color functions as necessary.

1694619513607.png


If you follow these guidelines with your own styles, you should be able to quickly build dark variations that are suitable for use on your site.

Video​


Here's a video showing everything in action:

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.
 
There should be an option to replace certain colors on the dark/white styles so the color option can be preserved to users but replacing them when it's the case.
If you leave it alone it should be there automatically.
Getting rid of colours and fonts makes you look like a dictator.

What i’m going to do is work out a perfect colour range for my forum when 2.3 comes out.
At the moment i use @Russ pixel exit theme called xenbase.
 
There should be an option to replace certain colors on the dark/white styles so the color option can be preserved to users but replacing them when it's the case.
It would require some sort of math to calculate the difference in contrast between the background color and the text--I don't know what exists out there that could fix it. I know it is detectable, but whether or not it can be fixed in real time (JavaScript perhaps?) is the question.

I'm keen to get rid of colored text entirely since, in all the forums I've run for nearly 30 years now, there has never been a valid use or need for colored text. It's always someone thinking they are being clever or silly, or in very rare instances, they color some text but try to "fix" it by changing it back to black by picking it manually.
 
this won't look nice on a white/light theme. yellow on white is quite unreadable. the whole problem is being created by light/dark theme option. and how xenforo editor is adding color codes in post editor in some cases during copy paste or some other action.
 
this won't look nice on a white/light theme. yellow on white is quite unreadable. the whole problem is being created by light/dark theme option. and how xenforo editor is adding color codes in post editor in some cases during copy paste or some other action.
In the example given above, that dark style is forced for those nodes.
 
Custom text colors are not needed for editors, nor are they smart to have in the modern web. If you need text color changes they should be handled by a css class for things like highlighting in your article or report. Having them enabled, you're just begging for your page to get google to complain about accessibility, not to mention users going from dark/light modes as mentioned.
 
Au contraire!
😁

Off-topic doesn't bother me so much. But part of it is PTSD from a member who was, shall we say, a little unbalanced. He was fine back in the mid to late 90s but by the late 2000s his posts rambled on and didn't make much sense...and hi also took to mashing all the text editor buttons and had all sorts of combinations of colors, bold/italic, etc., which made them nearly impossible to read. We even nicknamed him "Crayola ____."

I think the day he made a post in our "support" forum asking why some forum pages were loading slowly, or incorrectly, might possibly be an indication of how we dealt with him. We haven't seen him in several years.

There's a longer side story as well. He's a local. Way back in the 90s, we still used our real names in the forum and he found out where I worked...and showed up there three times. And regardless of time of year, he always wore a wool peacoat, just to put an image to it. Borderline stalking, if you asked me. What pissed me off more was that at our main office, he held up our customer counter and wasted their time about some silly project he made up in his head, while others were lined up behind him with machinery down that needed parts.

We had issues with a few other using colors but kind of dealt with it in other ways. But since removing the button a decade ago, it has been a non-issue for posts since then. We still have way too many old posts with colored text though, many unreadable due to dark colors (maroon, navy blue) on the black background.
 
Custom text colors are not needed for editors, nor are they smart to have in the modern web. If you need text color changes they should be handled by a css class for things like highlighting in your article or report. Having them enabled, you're just begging for your page to get google to complain about accessibility, not to mention users going from dark/light modes as mentioned.
👆 Nailed it!​
 
Custom text colors are not needed for editors, nor are they smart to have in the modern web. If you need text color changes they should be handled by a css class for things like highlighting in your article or report. Having them enabled, you're just begging for your page to get google to complain about accessibility, not to mention users going from dark/light modes as mentioned.
Haven’t had any issues tbh, and the colors are very useful at times for certain times information. Highlights could be effective tho as well, so I agree on that front.
 
Custom text colors are not needed for editors, nor are they smart to have in the modern web.

Right..

Some similar quotes:

1876: "The Americans have need of the telephone, but we do not. We have plenty of messenger boys." — William Preece, British Post Office.

1889: “Fooling around with alternating current (AC) is just a waste of time. Nobody will use it, ever.” — Thomas Edison

1946: "Television won't be able to hold on to any market it captures after the first six months. People will soon get tired of staring at a plywood box every night." — Darryl Zanuck, 20th Century Fox.

1966: "Remote shopping, while entirely feasible, will flop.” — Time Magazine.

1995: "I predict the Internet will soon go spectacularly supernova and in 1996 catastrophically collapse." — Robert Metcalfe, founder of 3Com.

2005: "There's just not that many videos I want to watch." — Steve Chen, CTO and co-founder of YouTube expressing concerns about his company’s long term viability.

2007: “There’s no chance that the iPhone is going to get any significant market share.” — Steve Ballmer, Microsoft CEO.
 
@Dad. so please elaborate why taking away features for the end user rather than creating a customization method/option in the ACP is the better idea? Tbh, your opinion seems more foolish in this regard if you want to go there. Just being real.
 
--Unknown author

I don't mean to cause upset or controversy with this.

I'd like to understand if this aligns with your perspective @Dad.:
  • Applying font colors on a website for emphasis or styling (example screenshot below) -> positive, acceptable

  • Allowing users to use font colors in their content for emphasis or styling -> negative or only suitable if we set the color options, assuming they might lack design skills or struggle with their operating systems' vision tools.



    2024-01-27_01-44.webp
 
I don't mean to cause upset or controversy with this.

I'd like to understand if this aligns with your perspective @Dad.:
  • Applying font colors on a website for emphasis or styling (example screenshot below) -> positive, acceptable

  • Allowing users to use font colors in their content for emphasis or styling -> negative or only suitable if we set the color options, assuming they might lack design skills or struggle with their operating systems' vision tools.



    View attachment 297225
These are not comparable examples, even remotely. One example is a controlled environment built in an organized fashion with Google in mind, and built by UI/UX designers with years of experience. The latter is end-users being in control of how other users read some content on a different environment.

Removing colors must be a controversial subject, take the advice or do not. If your community users like it, so be it, but you will need to live with either the need for a smart solution where you have to make sure every color is accessible, dark mode compatible. and accepted by google and cannot be abused (limiting colors, etc.) OR the easy solution: remove the colors and focus on something that might actually improve traffic and overall user engagement.

This is not a huge issue, just to me an easy victory for all to just disable and move on. I have no metrics on how bad google will hurt you or the percentage of users that will complain if you do not. It just logically follows
 
Top Bottom