Rikki

If I remember correctly, this is the sort of thing I suggested: body { zoom: 0.9; }

4.4 used Roboto, 4.5 uses Inter.

Thanks for the feedback; it sounds like a couple of the issues you noted are bugs, so we'll be able to address those as such. We've been upfront that firstly the app is in its early stages but also that it won't necessarily be ideal for every community. If you have a lot of customization (be it plugins or lots of custom pages) it's probably not going to be the best solution for you. We may devise a solution to that in future but right now it'll be focused on core 'out of the box' functionality. I'll lock this since you have struck out your first post, but I just wanted to address your points too.

In 4.5 we've tried to keep headers consistent, so that buttons are where you expect them to be, there's space for additional buttons as each page/app might require, and so that each page/app can extend the data shown in the header without the whole thing breaking down. In 4.4, this was a problem - sure, on perfect example pages, the follow button worked well in the top right. But using a different app where more buttons need to be shown, or even just having a long topic title, suddenly it wasn't so pretty and usable. The new header is designed to be flexible and extensible according to requirements. It's pretty easy to take one particular page and find criticisms - but remember we are designing a suite where each page might have some shared functionality and some unique functionality. We have to design components that can work well in more than one perfect scenario.

We don't load (many) polyfills ourselves - they are included with libraries that we use. Those libraries will only execute them when needed, but the code is still sent to the browser since we bundle and minify javascript.

Hi Nicholas, what's the name of your site? I will see if I can figure out the error.

None of our own CSS selectors use the .sp prefix - that comes from a third-party library we use. But frankly, the possible overheard for the browser is so negligible that it isn't even worth worrying about,

Apologies again! Update your app to get the latest build and things should be good now. At the time of this post, the app was approved in the Play Store but still pending review in the iOS App Store, but should be available soon. Note that in both stores it's still in the beta process (Beta in the Play Store, TestFlight in the iOS App Store) so you won't see it unless you specifically opt in to the beta.

We have no problem with choices - that's why we have thousands of choices in the AdminCP. But every choice, no matter how small it may seem, has a cost in terms of development time, future maintenance, documentation, UI complexity and so on. And that's not even counting the problems with the feature that we've already outlined, specifically that they aren't the same for all users and therefore cannot be relied upon in the way you want them to be.

The date in every post provides a direct permalink to the post. Incorrect post numbers based on a user's individual permissions would certainly present more of a usability issue for both disabled and able-bodied users. It's absolutely fine that some people would like to have post numbers back - we understand people don't always like change - but please let's not try and justify it as being a legal requirement.

Those files aren't obsolete - they are the foundation of our framework. What your tool is finding is polyfills for old browsers that libraries we use (such as jQuery) include.

Just to note, we did list this change in the deprecation section for 4.5. We always recommend reviewing the release notes, especially for major releases.

Even Microsoft will not support IE11 (or legacy Edge) in any way from next year, including in its own products like Teams. Other major sites like Twitter are starting to drop any support too. It won't be long until you'll struggle to use the web on IE11. Technically we have not supported it for a long time, but because we held back on modern CSS features, it still mostly worked. For 4.5, we decided now was the time to press ahead with improvements and drop support ourselves. By dropping support, we've been able to use newer CSS features that benefit designers (and therefore site owners), simplify our theme (with more improvements to come), and we'll also be able to begin the process of modernizing our javascript. If your community has a significant percentage of IE11 users due to your audience, you may prefer to stay on 4.4 (though that, understandably, has drawbacks too). If you're just an individual IE11 user, I would strongly suggest using a newer browser - literally any of them would be a better choice.

Apologies for the problems. I was finally able to diagnose the cause of the login issues, but unfortunately they cannot be fixed until 4.5.2 (and new app builds). That should be available in the next few days. That will solve both the failed logins and the 'invalid redirection uri' error.

The default font changed in 4.5, so that may explain that difference. It was Roboto in 4.4, but 4.5 just uses the system default (Segoe on Windows, SF on Mac, etc.). You can edit your theme settings and switch back to Roboto if you prefer the previous style.

Are you seeing errors in any modern browser? The variables it is flagging up are valid CSS and don't affect performance.

Thanks for the feedback - it's definitely early stages. We'll be looking to improve performance as time goes on, as well as add functionality. There's only one codebase for both iOS/Android, but that is indeed (currently) separate from the main product. It's very much 'work in progress' right now 🙂

That's the pagination bar - though on the first page pagination doesn't show.

If you're working in templates there's also a {truncate} plugin that'll do it for you. Just do {truncate="$content" length="200"}.

I don't think that'd be feasible because the app stores aren't going to pass on referrer info to the app to know which community you tapped from. Maybe some way of quickly adding a community would be a compromise? A 4 digit code or a QR code maybe?

In 4.5 we have a 4px spacing scale and we use variables to apply it. They're named --sp-* where the * is the multiplier. That means the variable --sp-3 will be 12px. You can either change it to --sp-2 for 8px, or just replace var(--sp-3) with a hardcoded pixel value if you prefer.

It won't be any time soon, if ever - the {theme} tag is still used for non-color settings for example. It'd be preferred to use the CSS variable approach for consistency and potentially future compatibility with new features, but it isn't a huge deal right now. That said, converting them should be easy in most cases. We did our entire framework in a few steps using find/replace in a text editor.

Is there a reason you're creating text settings to hold rgb values? It'd probably make more sense to make them color fields (so users get a color picker), and then using the automatically-created CSS variable instead.

Bear in mind, you don't have to update styles in custom.css. But if you do want to use the new approach: All theme settings that are color fields will automatically be set up as CSS variables, so you don't need to do that yourself (the hex will automatically be converted to an rgb triplet too). So if your "mass_color_main" theme setting is a color field, the --theme-mass_color_main CSS variable will automatically exist. So in your first example, your updated code would be correct and you wouldn't need to do anything extra for that to work. For your second example, are you saying you'd have a theme setting that's just a plain text field? If so, that won't automatically be created as a CSS variable. You'd need to do that yourself, like so: :root { --your_custom_setting: {theme="your_custom_setting"}; } You can then use that variable however you wish. In this second example, nothing is automatic, so you can name your CSS variable whatever you want.

Any theme settings that are "color" fields will automatically be turned into CSS variables for you. If your theme setting has the key "test_color" (like in your screenshot), the CSS variable will be named --theme-test_color. No need to create the CSS variables yourself 🙂