Rikki

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 🙂 

Both background and font color are available as theme settings - look for the "section title" settings on the Text tab (technically you can overwrite the CSS variables as shown above, but it isn't necessary and may be confusing later).

16 minutes ago, marklcfc said:

I've noticed the individual forum icons for mark as read don't appear to be ajax now?

That'll be fixed when we next update 👍

Our menu has more options than most since we've added our website nav, but regardless, that's intended - it's not frequently used and doesn't need to be prominent.

1 minute ago, The Old Man said:

Thanks for that @Rikki The free version would indeed be fine but couldn't we just utilise our own Pro Licence credentials if we have them or opt to buy Pro later?

You could, but then you can do that now too. We wouldn't be able to use any pro icons in the base software.

As a side note, I reached out to FA to find out if the Pro license would be an option for us. The bad news is it wouldn't, because anyone who edits/exports themes would be defined as a 'creator' and need a seat on the license. We could use the free version, but the benefits over FA4 are not particularly big, afaik.

1 minute ago, The Old Man said:

Plus you could probably remove the whole separate Icomoon web font library as I bet those few icons it provides are now included within FA4 or FA5 these days.

Actually that reminds me, I saw some Google warnings this week in Lighthouse about security vulnerabilities discovered in the jQuery version that IPS uses. That might need an update.

icomoon has been removed in 4.5 and jQuery has been upgraded to the 3.x series  🎉

The reason is essentially that it'd be a big undertaking for us to update to FA5 for relatively little benefit for most customers. Some people (like yourself) would obviously have more need for it, but on the whole the cost/benefit of upgrading is minimal. They do have a migration script but again I'm not convinced it's worthwhile to include that on every site.

4.5 introduces some changes to CSS, so I wanted to provide an overview of those and how they might affect you.

IE11

Firstly, we've completely dropped support for IE11. This means you'll start to see newer CSS methods being used that IE11 does not support. 

Atomic classnames

One thing you'll notice as you read on is we're moving towards using atomic classnames for utility styles. What does that mean? Basically, each classname is just a convenience helper for applying one particular style. You build how an element looks and behaves by applying multiple classnames. 

While this is slightly more verbose in the HTML, it's also much clearer and avoids having to create mutant selectors that exclude certain elements. If you see an element with ipsBorder_top, it's obvious what it does. Don't want a top border? Just remove that class.

Another benefit is that it allows more precise control over how styles are applied at different device sizes, because individual styles can be modified. Want a top border on desktop, but not phones? ipsBorder_top sm:ipsBorder:none will do the job - no crazy selectors or additional media queries necessary.

Class prefixes/modifiers

Wait, what's that sm: bit in the atomic classname example above? That's a new naming convention you'll see which controls at which breakpoints the style is applied.

• Unprefixed (e.g. ipsBorder_top). Applies to all devices, desktop and smaller.
• md: (e.g. md:ipsBorder_top). Applies to tablets and smaller.
• sm: (e.g. sm:ipsBorder_top). Applies to phones only.

sm and md prefixes take priority over the desktop classname. This means you provide the desktop classname but can override it for tablets and/or phones by also adding an md: or sm: classname. For example, ipsPadding_top:double sm:ipsPadding_top:half applies double top padding on desktop, but only half top padding on phones.

You'll also see modifiers on some classes (as in the example above), for example ipsPadding:half. ipsPadding is saying 'apply padding to all sides', and the ':half' modifier makes it a smaller amount.

BEM classnames for modules

While we're using atomic classes for global utility styles, we're moving towards BEM for module-specific classes. BEM is simply a naming convention, so it doesn't have too much impact on you - you'll just see a new structure for new classnames that should be easier to understand. 

Note: We haven't rewritten our CSS framework with the atomic classname, class prefix/modifier or BEM approaches. Don't worry - 90% of the classes you're used to will be the same. I just wanted to point out that going forward, new classes will follow these paradigms.

CSS Variables & calc

We're now making use of CSS variables (also known as CSS custom properties). Check out this MDN article if you aren't familiar with them. This enables us to define some values in one place but use them throughout the product - and it allows you to change the value in one place if you wish to do so for your theme. Most of our CSS variables are defined at the top of global.css in the CSS framework, but you'll also see some other local variables defined in other places. Variables are simply used by wrapping the name in the var() function, e.g. var(--positive-light). 

You'll see some variables named --sp-1 and so on. This is our new 4px spacing scale. In 4.5 and going forward, when we style elements we'll generally be using one of these values for widths, heights, borders, spacing etc. to keep everything consistent. You should do the same for elements you create.

We're also making use of calc(). This is another CSS function that allows math operations to be done. Instead of having to hardcode numbers for positions, sizes etc., we can now use calc() to do it for us based on some other values (often CSS variables).

CSS Variables for theme settings

We are deprecating the usage of the {theme} and {hextorgb} tags for color-type theme setting keys (but not for non-color settings or when you need to pass a specific hex code in).

Instead, color-type theme settings will automatically have a CSS variable created for them, named --theme-setting_key, where setting_key is the key of the setting as defined in the AdminCP. The variable will be a triplet representing the color, for example 255, 255, 255. Therefore, this value can be used with both the rgb and rgba CSS color functions.

Here's an example. If in the past you'd wanted to use the area_background theme setting in your CSS, you'd do background: {theme="area_background"}. Or if you want some opacity, you'd do background: {hextorgb="area_background" opacity="0.2"}.

In 4.5, the correct way of using these will be: background: rgb( var(--theme-area_background) ) and background: rgba( var(--theme-area_background), 0.2 ) respectively.

We're doing this now because it will open up some exciting functionality in future. To be clear, any existing usage of {theme} and {hextorgb} will continue to work fine in 4.5, but we encourage you to move over to the CSS variable approach.

Hardcoded hex values

In 4.5 we have largely removed all hardcoded hex colors from our CSS files, and adjusted styles to use theme setting values instead. This will make it much easier for admins to fully colorize their theme without hardcoded colors messing things up. I encourage you to update your app's CSS to follow this approach.

Font sizes

We've moved font sizes to a fixed scale. These have been implemented as theme settings so they are customizable. However, rather than use the theme setting value directly, you should make use of the new {fontsize} plugin. This plugin ensures the global scale is applied to any values passed in, allowing 'large print' versions of themes to be easily created. You should use the {fontsize} plugin for font sizes both when you use one of the theme settings and when you use specific pixel values (e.g. {fontsize="72"} - for 72px text)

When used with the {fontsize} plugin, the type scale keys are:

• x_small (12px)
• small (13px)
• medium (14px)
• base (16px)
• large (18px)
• x_large (20px)
• 2x_large (24px)
• 3x_large (30px)
• 4x_large (36px)

Flexbox

While we've used flexbox in some places in previous versions, 4.5 makes much wider use of it and also introduces a new family of classes. If you aren't familiar with flexbox, I highly recommend this CSSTricks article for a primer on it. Essentially, instead of positioning elements using floats/clears/etc., flexbox treats the container as a flexible box with properties for controlling how elements inside of it as laid out.

4.5 has a number of new classes that are essentially just convenience for the usual CSS rules.

• ipsFlex (sets element to display: flex)
• ipsFlex-ai:start, ipsFlex-ai:center, ipsFlex-ai:end, ipsFlex-ai:stretch (ai - values for align-items property)
• ipsFlex-as:start, ipsFlex-as:center, ipsFlex-as:end, ipsFlex-as:stretch (as - values for align-self property)
• ipsFlex-jc:start, ipsFlex-jc:center, ipsFlex-jc:end, ipsFlex-jc:around, ipsFlex-jc:between (jc - values for justify-content property)
• ipsFlex-fd:column, ipsFlex-fd:row, ipsFlex-fd:column-reverse, ipsFlex-fd:row-reverse (fd - values for flex-direction property)
• ipsFlex-fw:wrap, ipsFlex-fw:nowrap, ipsFlex-fw:wrap-reverse (fw - values for flex-wrap property)
• ipsFlex-flex:10 - sets flex-grow: 1 and flex-shrink: 0
• ipsFlex-flex:11 - sets flex-grow: 1 and flex-shrink: 1
• ipsFlex-flex:01 - sets flex-grow: 0 and flex-shrink: 1
• ipsFlex-flex:00 - sets flex-grow: 0 and flex-shrink: 0

All of these classes have md and sm prefixed versions too, and this opens up the possibility of having different layouts on different device sizes in a way that's much easier than the hoops you'd have to jump through before. For example, to create some elements that show as a row on desktop but collapse to a column on mobile, you'd just apply ipsFlex ipsFlex-fd:row sm:ipsFlex-fd:column. The sm:ipsFlex-fd:column class overrules the ipsFlex-fd:row class on mobile, adjusting the layout. (Note: flex-direction: row is the CSS default direction anyway, so you can actually leave out ipsFlex-fd:row - it's implicit. I included it in the example for clarity.)

Padding/margin

We've added new spacing classes for padding and margin, to allow for atomic classnames, device prefixes and modifiers.

ipsPad, ipsPad_double, ipsPad_half, and all of the ipsSpacer_* classes are now deprecated. You'll still see them in our templates and they'll still work in yours, but don't use them in any new work - you should use the updated classes below.

The padding classes are now named ipsPadding:

• ipsPadding, ipsPadding:none, ipsPadding:half, ipsPadding:double - apply padding to all four sides
• ipsPadding_vertical, ipsPadding_vertical:none, ipsPadding_vertical:half, ipsPadding_vertical:double - apply padding to top and bottom
• ipsPadding_horizontal, ipsPadding_horizontal:none, ipsPadding_horizontal:half, ipsPadding_horizontal:double - apply padding to left and right
• ipsPadding_left, ipsPadding_left:none, ipsPadding_left:half, ipsPadding_left:double - apply padding to the left side (RTL aware)
• ipsPadding_right, ipsPadding_right:none, ipsPadding_right:half, ipsPadding_right:double - apply padding to the right side (RTL aware)
• ipsPadding_top, ipsPadding_top:none, ipsPadding_top:half, ipsPadding_top:double - apply padding to the top side
• ipsPadding_bottom, ipsPadding_bottom:none, ipsPadding_bottom:half, ipsPadding_bottom:double - apply padding to the bottom side

These classes have md and sm prefixed versions too, allowing you to apply different padding depending on the device size.

One side note here: with the old padding classes, padding was simply halved on phones with no opt-out. That's not the case with the new family - if you want half-padding on mobile on an element, you should apply sm:ipsPadding:half in addition to the normal ipsPadding class, for example. This gives you much more control than you previously had.

Margins follow basically an identical pattern to padding, with the same variation of classes, except the name is ipsMargin.

Gaps

Another new family of classes is ipsGap. These classes are used when you want spacing between elements. In the past, you'd have to use :last-child or :first-child to exclude an element, or loop over the elements in the template to leave off a class. If elements wrapped to a new line, putting spacing between the lines was tricky too.

ipsGap solves this by applying even spacing between elements, then applying a negative margin on the whole container to bring it back to the starting position.

The classname is followed by a modifier, which is a number from our spacing scale, e.g. 1 is 4px spacing, 2 is 8px spacing and so on.

• ipsGap:1 (1-5 available) - applies both horizontal and vertical spacing around each element in the container
• ipsGap_row:1 (1-5 available, as well as 0 to remove) - applies vertical spacing on each element in the container

Notice ipsGap_row also supports the :0 modifier. This allows you to have horizontal-only spacing - simply apply ipsGap:1 ipsGap_row:0.

Be aware that using both ipsMargin (or custom styles that apply a margin) and ipsGap on the same element can cause issues. You may want add a wrapper element to handle your margin in this situation.

Borders

We've also added a class family to add light grey 1px borders to elements - used commonly as dividers between some parts of the page.

• ipsBorder - apply border to all sides
• ipsBorder:none - remove border from all sides
• ipsBorder_vertical - apply border to top and bottom
• ipsBorder_horizontal - apply border to left and right
• ipsBorder_top, ipsBorder_bottom, ipsBorder_left, ipsBorder_right - apply border to a particular side

These classes have md and sm prefixed versions too, to control borders shown on each device size. This is particularly useful if you apply a border to a flex child which is in a row on desktop but a column on desktop, for example - you will be able to easily control which side the border appears on once collapsed.

"Pull" class

To better display content areas on mobile, a class named ipsResponsive_pull has been added which 'pulls' a box on the left and right sides on small devices. It's intended to be used on boxes (normally with the ipsBox class) that you want to take up the whole screen width on mobile, allowing better usage of the available screen space.

Template changes

We've worked to keep template changes as minimal as possible, but in an update the size of 4.5 there are still quite a number of changes. Whether these impact you will depend on if you've modified the template (for theme designers) or rely on a particular selector for theme hooks (for developers).

One area that has received fairly big changes is the post/comment templates. We have redesigned the headers and footers of these templates and moved some elements into a separate parent element on mobile devices.

As usual, full template changes will be available once we've released betas.

I'm afraid I won't be able to dig up the example because it was a long time ago, but I'm pretty sure I remember someone building a timeline very similar to that using our Pages app and some custom templates. You'd just need a database with a date field and a content field, and then build some custom templates to display it as a timeline 🙂 If you have HTML/CSS skills it should be doable, or a third-party designer could do it without much trouble I expect.

Nice suggestions. I don't think the concept of replying directly to a post works so neatly on forums (well, Invision Community in particular) because our conversations aren't threaded. Instead you quote one or more posts - but your reply is still part of a linear conversation.

That said, you're definitely right that having to go to the bottom of the page is a bit old fashioned and cumbersome. I think it could be made easier - for example, one idea would be to have a floating reply button or even reply box, available on a topic page at all times, so you can start working on your reply wherever you happen to be in the topic.

Funny you should say that 🤭

I just wanted to note that we've improved the error message for this error in 4.5, so users at least won't see a mysterious "-200" message when it happens.

3 minutes ago, Bluto said:

Matt said that 5 months ago @Rikki 

Issue has been around for 2 years.

Not holding my breath for this change.

No need to hold your breath - it's already fixed and merged into the next release 👍

I've logged an issue for this and we'll look at getting it changed for 4.5 🙂 

Platforms that use reverse order do so to show feeds - individual items not related to each other. We do that for the topic listing and for streams.

I can’t think of any platforms that actually show conversations in reverse order. Twitter replies, iMessage, WhatsApp, Facebook and Instagram comments - they’re all in regular chronological order (aside from when ‘intelligent’ ordering is employed, such as Facebook showing 'relevant' messages or Reddit sorting by most-upvoted).

In fact, the only medium I can think of that uses reverse order is, ironically, good old-fashioned email (and even that depends on your client).

20 minutes ago, BankFodder said:

And to all you people - it's about keeping your customers happy.

Absolutely - and we did this with a compromise. Make a preview tool available for those few customers who have valid edge cases, without adding Yet Another Button in a prominent location for all our other customers. Every extra button or toggle we add to a page increases the complexity for users a little bit more, mostly unnecessarily. We try to consider all users and balance functionality with simplicity as much as we can.

Honest reason it's located where it is: we do not feel it has sufficient usefulness for most sites and most users to justify giving it a more prominent location next to the submit button. We made it a customizable toolbar button so that it's available for those few edge cases where you could argue it's useful, without it being a fundamental part of the editor UI.

5 hours ago, marina_ls said:

Yes, I was just looking at that. Thanks. Trying to target it now using:

 

  body[data-pageapp="forums"][data-pagemodule="forums"][data-pagecontroller="index"] .ipsApp_front .ipsBreadcrumb {
  display: none !important;
  }

But not having any effect... Am I doing something wrong?

Thanks!

.ipsApp_front is also a class on the body element, so you need to remove the space (I've also moved that class to the front of the selector for clarity):

body.ipsApp_front[data-pageapp="forums"][data-pagemodule="forums"][data-pagecontroller="index"] .ipsBreadcrumb {
	display: none !important;
}

An alternative way is using the data-pagelocation attribute in the same way you've used the others, since that tells you whether it's 'front' or 'admin':

body[data-pagelocation="front"][data-pageapp="forums"][data-pagemodule="forums"][data-pagecontroller="index"] .ipsBreadcrumb {
	display: none !important;
}

Either of those approaches should work 🙂 

37 minutes ago, SJ77 said:

I am not trying to stomp on your excitement @SammyS

It's just that I spend so much time dialing in behavior, performance and functionality, the right custom apps, payment gateways, daily work flow and process, plus server settings. It sounds like an actual nightmare to have to start over on this. I can't imagine why I would want to do that???

At the very least it would cause me to lose a significant amount of sales and frustrate my users. For what benefit? What new "must have" feature is so important that I want to go through that again?

I will never forget how hard it was going from 3 to 4 and if I never have to do that again in my entire life it will still be too soon.

Do you see where I am coming from here?

We certainly understand that 🙂I'm almost positive v4 will be maintained for a considerable period of time after v5 is available. That said, we of course need to continue to press forward and modernize the platform, especially in terms of UI and taking advantage of more modern approaches to development. We will of course do everything we can to make it as painless as possible when the time comes.

3 hours ago, LaCollision said:

Have you tried Vue.js?

Don't you think it could be easier to integrate with IPS than React?

I love Vue.js 🤩

Yeah, I do actually agree with you. But I still love React more.

2 hours ago, Adlago said:

This test I do on this site as a guest - as every online tool does a test. Such an estimate speed makes and Google when analyzing the sites in which it publishes advertisements. This reduces the price paid by site owners.

Of course, users who logged into a site do not have this issue. But when it comes to money - any delay in loading site is bad. And I see many sites that rely on this ...

It's cached for guests too after their first page load. You don't have to log in to get caching (in fact, our caching is even more aggressive for guests than members, since they all see the same thing).

Your tests are likely assuming an empty cache, which is a fair measurement of a first-time visit/stale cache, but subsequent page loads will be loading FA from cache, not the server.

33 minutes ago, Adlago said:

yes, but the added weight is incomparably less. Font awesome causes a download of 65kB file and this slows rendering.

Only for the first visit - whereas using data:image means it's being downloaded on every page view. For a single icon (like your menu bars example) I'd agree that's the best approach, and that's what I do on my personal projects normally, but when we're using dozens of different icons in hundreds of places, it doesn't make sense.

That said, web development is always moving forward, so when our next major update begins, we'll evaluate the best approach at that point.

On 12/14/2018 at 5:11 AM, Lukazuki ❤ said:

maybe in an alternate universe, IPS uses the AngularJS 🤔

React FTW